C vs. Fortran (half OT questions)
in [Fortran]
|
Prev: gcc4.4: f951: warning: command line option "-MM" is valid for C/C++/Java/ObjC/ObjC++ but not for Fortran
Next: Bad dependency relation for "gfortran"
From: Paul van Delst on 10 Aug 2010 19:55 gmail-unlp wrote: > On Aug 10, 7:18 pm, Giorgio Pastore <past...(a)units.it> wrote: >> Vincenzo Mercuri wrote: >> In my professional experience (academic research in condensed matter >> computational physics) I have used more than 10 different programming >> languages (without taking into account versions/dialects). I am >> Fortran/C bilingual but for many years I have used only Fortran for >> serious numerical work and C for more system oriented work. In the last >> 10 years I have become more and more interested in OO paradigm, so, even >> if I am not proficient in C++ as I am in Fortran/C, now, for a new >> project, my first question is about the alternative C++/Fortran not >> C/Fortran. > > Why OO in Fortran is not an alternative? The fact that f2003 compilers are still (!) not widely available? Apart from cray and xlf fortran, I haven't heard of any other f2003 compliant fortran compiler. It's quite sad really. I can see potential benefit in using Fortran2003 OO stuff in some of my day to day work but I would be an island. I've given up asking vendors when fully compliant f2003 compilers will be available since I always get the same response: "Please let us know what features you would like implemented". Crikey... all of 'em! cheers, paulv
From: Tim Prince on 10 Aug 2010 20:07 On 8/10/2010 2:32 PM, Ron Shepard wrote: > In article<Rd2dndSu6ZUm4PzRnZ2dnUVZ7v4AAAAA(a)giganews.com>, > Vincenzo Mercuri<comp(a)lang.c> wrote: > >> I've been always told of the C language as the best choice >> to accomplish any kind of task in numerical algorithms implementation. > > Maybe newer versions of C are better, but the older versions of C were > particularly bad when it came to numerical algorithms. For example, in > traditional K&R C, parentheses could not be used to force operations to > occur in a particular order, something that is very important when > writing numerical code. This was corrected in the original (c89) standard. Unfortunately, you must explicitly disable certain optimizations of certain vendors in order to comply with the standard. Even with the Fortrans of such vendors, you must study the options to find out how to comply with standards and still get optimizations. >Also, float arguments were promoted to double > in all function calls, another troublesome feature when trying to write > careful numerical code. This is a dead issue, as long as you observe standards which have been in effect for 2 decades. >And, of course, all arrays in C must be > zero-based, which seldom matches the numerical problem at hand. > Multidimensional arrays are also a problem in C, especially the ones > with dimensions determined at runtime rather than with constants at > compile time. The floating point declarations sometimes are a pain in > C. For example, something declared as float on one machine might have > the same precision as something declared as double or as long double on > some other machine. The solutions to this problem were instituted a decade ago. It's true, they haven't been widely taken advantage of. >And finally, perhaps the biggest problem with > numerical code in C, is that the value of some simple expressions such > as "i/j" in which either one or both of the integer values are negative > were not defined in C (they could round either up or down); this means > that to write truly portable C code you need to test for negative values > and evaluate the expressions using positive values only. Yes, it's hopeless to maintain backwards compatibility to compilers of 3 decades ago. Why would you attempt it, in either C or Fortran? How would you test your solutions? Currently maintained Fortran compilers support the iso_c_binding. The adoption of this standard recognizes the practical requirement for combining C and Fortran applications, so a question which considers C and Fortran as mutually exclusive is outdated. -- Tim Prince
From: Gary L. Scott on 10 Aug 2010 20:31 On 8/10/2010 6:55 PM, Paul van Delst wrote: > > > gmail-unlp wrote: >> On Aug 10, 7:18 pm, Giorgio Pastore<past...(a)units.it> wrote: >>> Vincenzo Mercuri wrote: > >>> In my professional experience (academic research in condensed matter >>> computational physics) I have used more than 10 different programming >>> languages (without taking into account versions/dialects). I am >>> Fortran/C bilingual but for many years I have used only Fortran for >>> serious numerical work and C for more system oriented work. In the last >>> 10 years I have become more and more interested in OO paradigm, so, even >>> if I am not proficient in C++ as I am in Fortran/C, now, for a new >>> project, my first question is about the alternative C++/Fortran not >>> C/Fortran. >> >> Why OO in Fortran is not an alternative? > > The fact that f2003 compilers are still (!) not widely available? > > Apart from cray and xlf fortran, I haven't heard of any other f2003 compliant fortran compiler. It's quite sad really. I > can see potential benefit in using Fortran2003 OO stuff in some of my day to day work but I would be an island. I've > given up asking vendors when fully compliant f2003 compilers will be available since I always get the same response: > "Please let us know what features you would like implemented". Crikey... all of 'em! But they're asking which ones you want FIRST. They are asking for priorities. They can't do them all at once. > > cheers, > > paulv > >
From: gmail-unlp on 10 Aug 2010 20:48 On Aug 10, 8:55 pm, Paul van Delst <paul.vande...(a)noaa.gov> wrote: > gmail-unlp wrote: > > On Aug 10, 7:18 pm, Giorgio Pastore <past...(a)units.it> wrote: > >> Vincenzo Mercuri wrote: > >> In my professional experience (academic research in condensed matter > >> computational physics) I have used more than 10 different programming > >> languages (without taking into account versions/dialects). I am > >> Fortran/C bilingual but for many years I have used only Fortran for > >> serious numerical work and C for more system oriented work. In the last > >> 10 years I have become more and more interested in OO paradigm, so, even > >> if I am not proficient in C++ as I am in Fortran/C, now, for a new > >> project, my first question is about the alternative C++/Fortran not > >> C/Fortran. > > > Why OO in Fortran is not an alternative? > > The fact that f2003 compilers are still (!) not widely available? > > Apart from cray and xlf fortran, I haven't heard of any other f2003 compliant fortran compiler. It's quite sad really. I > can see potential benefit in using Fortran2003 OO stuff in some of my day to day work but I would be an island. I've > given up asking vendors when fully compliant f2003 compilers will be available since I always get the same response: > "Please let us know what features you would like implemented". Crikey... all of 'em! > > cheers, > > paulv Waw! Thank you very much, I've read in the F2003 standard " (2) Object oriented programming support: enhanced data abstraction (allows one type to extend the definition of another type), polymorphism (allows the type of a variable to vary at runtime), dynamic type allocation, SELECT TYPE construct (allows a choice of execution flow depending upon the type a polymorphic object currently has), and type-bound procedures. " and taken into account the gfortran option -std=f2003 without any warnings on incomplete support, added to my lack of expertise, I assumed that at least most of the 2003 standard was already supported after... 7 years... Again, thank you very much. If possible, I would like to know the most important OO features not yet implemented (in gfortran or the compiler you are using) that you consider necessary for the " ....potential benefit in using Fortran2003 OO stuff in some of my day to day work... " Thanks in advance, Fernando.
From: glen herrmannsfeldt on 10 Aug 2010 21:28
Ron Shepard <ron-shepard(a)nospam.comcast.net> wrote: > In article <Rd2dndSu6ZUm4PzRnZ2dnUVZ7v4AAAAA(a)giganews.com>, > Vincenzo Mercuri <comp(a)lang.c> wrote: >> I've been always told of the C language as the best choice >> to accomplish any kind of task in numerical algorithms implementation. > Maybe newer versions of C are better, but the older versions of C were > particularly bad when it came to numerical algorithms. For example, in > traditional K&R C, parentheses could not be used to force operations to > occur in a particular order, something that is very important when > writing numerical code. You can split the expression across statements with temporary variables. I am not sure that Fortran is really that much better, though. The interesting effects that come from some intermediates being stored as temporary real (80 bit) where others are not doesn't help much in many of those algorithms that depend on expression ordering. > Also, float arguments were promoted to double > in all function calls, another troublesome feature when trying to write > careful numerical code. I believe gone in C89 when a prototype is in scope, except for varargs functions. In C89, all the math functions (sin, sqrt, etc.) are only available in double precision, and are used with the appropriate conversion. With systems that keep intermediate results in extended precision it makes more sense that way. C99 adds single precision (float) versions of all the functions (with a trailing f), and also complex variables and functions. > And, of course, all arrays in C must be > zero-based, which seldom matches the numerical problem at hand. > Multidimensional arrays are also a problem in C, especially the ones > with dimensions determined at runtime rather than with constants at > compile time. The usual array of pointers to arrays works pretty well in C, but doesn't work so will with mixed C/Fortran code. > The floating point declarations sometimes are a pain in C. > For example, something declared as float on one machine might have > the same precision as something declared as double or as long double on > some other machine. Ask CDC and Cray Fortran programmers about that. CDC has 60 bit single precision, Cray uses 64 bits. Both C and Fortran pretty much give you what the hardware gives. > And finally, perhaps the biggest problem with > numerical code in C, is that the value of some simple expressions such > as "i/j" in which either one or both of the integer values are negative > were not defined in C (they could round either up or down); this means > that to write truly portable C code you need to test for negative values > and evaluate the expressions using positive values only. I suppose, but C gives you what the hardware gives. A large fraction of algorithms use only non-negative division, anyway. But since hardware makers have to support Fortran integer divide they pretty much always do it the Fortran way, anyway. > All these things are much better in fortran. Fortran has always > respected parentheses in expressions, and fortran has never silently > promoted arguments in subroutine calls. Fortran does allow mixed-mode > and mixed-precision expressions, which are sort of like promotion, but > the programmer has control over this in fortran by the way the > expressions are written. In K&R, and in C89 without a prototype, the value would convert back to float when needed. On most machines float --> double --> float should give back the same value. If not, the machine is broken and not C. On most current machines (x87 and the 68881 at least) all arithmetic is done in double (or more) anyway. > Arrays in fortran can have any base at all, > whatever best fits the problem at hand. Multidimensional arrays in > fortran are no problem, they are as easy to declare, use, allocate, or > deallocate as 1D arrays. I believe fixed in C99, though I haven't used this yet. > Newer versions of fortran (since 1990) have a > nice way of parameterizing floating point precision that avoids many of > the portability problems in ancient fortrans (f77 and earlier); C has > not yet caught up in this respect. Now that IEEE floating point standardizes the available precisions, Fortran supplies a complicated way to access those. For real problems, it is very rare to know the exact precision needed in a complicated calculation. Mostly that means using the KIND system to choose between single and double precision. > And, "i/j" has always had a > well-defined value in fortran for any combination of negative or > positive integers (well, j cannot be zero, but that is a different > issue). Also, fortran has a nice array syntax which allows complicated > expressions to be expressed in a simple way, very much like the > mathematical expression you would write on paper; being able to write > clear, simple, code is important in numerical work. > I would say that it is difficult to even think of a numerical problem > that can be done better in C than in fortran. If that were really true, then there wouldn't be any C programs in Spec-FP. There are enough problems that are combinations of numerical and non-numerical to make C useful. Looking at the SPECfp page on wikipedia: Fortran benchmarks: bwaves: Fluid dynamics gamess: Quantum Chemistry zeusmp: CFD leslie3D: CFD GemsFDTD: electromagnetics tonto: Quantum chemistry C benchmarks: milc: Quantum Chromodynamics lbm: Fluid dynamics sphinx3: speech recognition C++ benchmarks: namd: biology/molecular dynamics deall: finite element analysis soplex: linear programming/optimization povray: image ray tracing wrf: weather forecasting C/Fortran benchmarks: gromacs: biochemistry cactusADM: general relativity calculix: structural mechanics > Of course, you can write > bad or inefficient fortran code, but you can fix it within fortran, you > don't have to switch languages to rewrite the bad code. On the other > hand, if you want to write low-level code to communicate with some > external device, then this is the sort of thing that is usually easier > in C than in fortran -- but that is not numerical code, which is the > topic in this thread. Also, C has always had associated with it a > well-defined preprocessor, something that fortran has *always* needed > but has really (practically speaking) never had; most modern fortran > compilers can use the C preprocessor, but there are some problems with > this approach that the programmer must avoid. -- glen |