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: Vincenzo Mercuri on 11 Aug 2010 05:06 Vincenzo Mercuri wrote: > Hi all, > I've been always told of the C language as the best choice > to accomplish any kind of task in numerical algorithms implementation. > I'd like to do some serious programming in numerical analysis and > I'd like to read some opinion about whether C has too many limitations > or it is far a better choice than Fortran is. I have some questions > that may seem trivial and not topical to this group (I've already > posted the same questions in comp.lang.c). Here they are: > > 1 -- is there any reason not to learn Fortran (a new language for me) > and focus on C (and C numerical libraries) potentialities? > > 2 -- is Fortran considered the best choice in this field only because > of its construct and syntax that makes easier to handle > mathematical entities? > > 3 -- what about the Standard IEEE 754 (IEC 60559:1989) conformance? > is that intrinsecal to the language or the implementation? > which language can offer a full support to the IEEE Standard, > C or Fortran? > > 4 -- what about performance? would you bet on C or Fortran? :-) > THANK YOU ALL for your answers, now I think I have a clearer idea of what to do. thanks. -- Vincenzo Mercuri
From: Vincenzo Mercuri on 11 Aug 2010 05:27 Giorgio Pastore wrote: > Vincenzo Mercuri wrote: > ... >> I've been always told of the C language as the best choice >> to accomplish any kind of task in numerical algorithms implementation. > > Amazing. I was told the same, but with C replaced by Fortran :-) Well...yes, it usually works like this :-) >> I'd like to do some serious programming in numerical analysis and >> I'd like to read some opinion about whether C has too many limitations >> or it is far a better choice than Fortran is. > > You are not mentioning what kind of external constraints you may have. > For example, I would guess from your message that you do not know > Fortran. But do you know C ? Are you planning to do some serious > numerical programming just for fun or do you have a (tight) tie schedule > ? Is the choice of the language completely to you or you have to > convince someone else ? Exactly, Fortran is an unexplored land to me. I know some C, I have been programming for (nearly) 1 year in C. Not for fun, I am trying to do some serious numerical programming after some experience in MATLAB...my fields of interest however are numerical analysis, cellular automata and percolation, in a computational physics context. (I am doing this for myself, no tight schedules :-) ) >> that may seem trivial and not topical to this group (I've already >> posted the same questions in comp.lang.c). Here they are: >> >> 1 -- is there any reason not to learn Fortran (a new language for me) >> and focus on C (and C numerical libraries) potentialities? > > Difficult question to answer without additional information. By the way, > I would be curious to know if by C you mean pure C or C++. I know a lot > of people thinking that they are the same language :-( Yes I know...I am aware of the differences between C and C++, but as you told me, comparing Fortran to C++ makes far more sense actually. >> 2 -- is Fortran considered the best choice in this field only because >> of its construct and syntax that makes easier to handle >> mathematical entities? > > Well, it depends what one is focusing on. Certainly the expressivity of > a language is not a minor point in the choice, since most of the costs > of sw are related to its maintenance and evolution. In this respect, I > would not consider the choice between Fortran and C but instead between > Fortran and C++. what about a good book (and a good reference) on Fortran? (of the latest Standard of 2003). Any suggestion? .. >> 4 -- what about performance? would you bet on C or Fortran? :-) > > In average, judging on the basis of the available studies, there is no > strong reason in favor of C or Fortran or C++. You may always find/write > program difficult to optimize in whatever language you chose (actually > slighty easier with C++). But, without knowing exactly what you plan to > do, and in particular which kind of programming paradigm you like to > use, it is difficult to say more. > > 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. Actually I must admit that performance is a matter of the right algorithm (and compilers...) rather than of the language itself. Thank you. -- Vincenzo Mercuri
From: Vincenzo Mercuri on 11 Aug 2010 05:38 Ron Shepard wrote: > 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. Also, float arguments were promoted to double > in all function calls, another troublesome feature when trying to write > careful numerical code. 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. 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. > > 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. 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. 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. 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. 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. > >> 1 -- is there any reason not to learn Fortran (a new language for me) >> and focus on C (and C numerical libraries) potentialities? > > I don't really know how to answer this. I doubt that anyone who reads > comp.lang.fortran is going to tell you not to learn fortran. > >> 2 -- is Fortran considered the best choice in this field only because >> of its construct and syntax that makes easier to handle >> mathematical entities? > > No, that is one of the reasons, but not the only reason. > >> >> 3 -- what about the Standard IEEE 754 (IEC 60559:1989) conformance? >> is that intrinsecal to the language or the implementation? >> which language can offer a full support to the IEEE Standard, >> C or Fortran? > > I don't know the full answer to this. There is IEEE support in standard > fortran (since 2003), but I don't know how full or complete it is. > >> 4 -- what about performance? would you bet on C or Fortran? :-) > > The main problem with C performance is that the syntax has wild > pointers. You can't avoid those -- even if you use array notation > rather than pointers, that is defined to be equivalent, so you are stuck > back with wild pointers which inhibit various compiler optimizations > (such as storing a value in a register and using it multiple times). I > think most of the other language features (in C and fortran) end up > being a wash as far as efficiency. But those wild pointers are the > elephant in the room. The C language is about 40 years old, and if that > problem could be fixed, I would think it would have been by now. Thanks for your full answer. -- Vincenzo Mercuri
From: robin on 11 Aug 2010 06:53 "Ron Shepard" <ron-shepard(a)NOSPAM.comcast.net> wrote in message news:ron-shepard-9FD13E.16323410082010(a)news60.forteinc.com... | 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. Also, float arguments were promoted to double | in all function calls, That may or may not be a problem, as in the PC, float arithmetic is performed in extended precision. | another troublesome feature when trying to write | careful numerical code. 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. That can happen in Fortran too. | 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. | 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. Arrays in fortran can have any base at all, | whatever best fits the problem at hand. Good point, but FORTRAN used to have 1 as the base. | Multidimensional arrays in | fortran are no problem, they are as easy to declare, use, allocate, or | deallocate as 1D arrays. 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. 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. 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.
From: Nick Maclaren on 11 Aug 2010 07:25
In article <i3tmc1$m29$1(a)gosset.csi.cam.ac.uk>, Nick Maclaren <nmm(a)gosset.csi.cam.ac.uk> wrote: >In article <i3sucp$jp0$1(a)speranza.aioe.org>, >glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > >>> 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. > >Nope. Little change. Nor in C++0X, nor in C1X. Variably modified >arrays bring C99 up to about the level of Egtran (i.e. Fortran II >with automatic arrays), but WG14 are considering whether to make >both them and complex numbers optional in C1X. If anyone cares. Yup. Adopted. There are now ten __STD_... feature-check macros, some of which permit incompatibility with C99, and more are proposed. In addition to a good many (dozens?) of other macros that may be defined to indicate that a particular language feature is supported. For portability, stick to Fortran, followed by C++ and C89/C90. Regards, Nick Maclaren. |