Xref: utzoo comp.lang.fortran:4284 comp.lang.c:34514 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!samsung!uunet!mcsun!hp4nl!charon!dik From: dik@cwi.nl (Dik T. Winter) Newsgroups: comp.lang.fortran,comp.lang.c Subject: Re: Fortran vs. C for numerical work (SUMMARY) Message-ID: <2642@charon.cwi.nl> Date: 5 Dec 90 01:32:33 GMT References: <1990Dec4.011220.9302@ccu.umanitoba.ca> <26434:Dec404:42:4990@kramden.acf.nyu.edu> <1990Dec4.190148.4026@ariel.unm.edu> Sender: news@cwi.nl Followup-To: comp.lang.fortran Organization: CWI, Amsterdam Lines: 37 In article <1990Dec4.190148.4026@ariel.unm.edu> john@ghostwheel.unm.edu (John Prentice) writes: > However, from what I have seen and heard of > these libraries, they are not easily transported to new systems and > unfortunately in science, new systems are always happening. Perhaps > someone involved with SLATEC, IMSL, NAG, etc... could comment on all this. I am not involved with those, but I have some experience porting stuff. My stuff consists of two layers. Both layers are in Fortran and in C. I ported (part of) it to some 30 platforms. Everything goes through the C preprocessor because of machine pecularities (as some parts are written in assembler this is necessary). However, the C preprocessor is also used to avoid compiler bugs. There were 19 platforms that had a Fortran compiler when I used the system. I needed in 6 cases conditionals because of bugs. I am now porting the highest level in C. I did port that to two platforms, and on one of those I needed to avoid a compier bug. So much about porting an (in principle) perfectly portable package. And this package contains only a fraction of the code that is in the libraries mentioned above. So what is involved: 1. Many compilers have bugs that you may encounter; especially if the code is large. (My favourite is the 68000 compiler that generates VAX assembler for some legal constructs. But I have also seen compilers generate non-existing, apparently legal, instructions.) 2. Do not rely on properties that seem to be intuitive. See the ongoing debate on pointers in C (especially NULL). But also do not expect that the construct 'sqrt(1-sin(x))' is valid, because it will trap on some machines, etc. (To quash any arguments; within your precision constraints it is perfectly possible that sin(x) >1.) 3. Especially if you have a large body of code, be prepared to customize it to every platform you may encounter. Allow the use of preprocessors to do this (C preprocessor, m4, your own special built macro processor, etc.). I know that NAG uses 3 (and the last count I heard was over 80 platforms). They use generic sources and a preprocessor that customizes to the platform required. -- dik t. winter, cwi, amsterdam, nederland dik@cwi.nl Brought to you by Super Global Mega Corp .com