Fortran Vs C, C++, C#
in [Fortran]
|
Prev: practice online trading. platinum online trading. online trading worldwide. online trading which is best
Next: variant data type
From: Richard Maine on 14 Jul 2010 18:33 dpb <none(a)non.net> wrote: > dpb wrote: > > Lynn McGuire wrote: > ... > > >> However, we got nailed recently by a 0 in a call to a sub with a > >> double argument. Replacing that with a 0.0 solved the crash. > ... > > BTW, that really should be 0.0D0 (as I'm sure you're aware) but just in > case one might consider going back to the offending point and making > sure rather than relying on a compiler switch to promote single/double. That's a case where I like to use a parameter ("parameter" as in "named constant" - not as in a sloppy synonym for "procedure argument"). I like to avoid real literal constants as actual arguments. I don't make it an absolute rule; there are cases where real literals seem the best choice (such as when you have about a zillion of them in close proximity). I am pretty finicky about using a kind parameter whenever I do use a real literal as an actual argument. The specific case of real zero is common and basic enough that I have a named constant (r_zero) for the real zero of my working precision (most often double, but I've made it easy to change - something about having wasted many, many hours/days/weeks of my youth working on changing precision while porting code). I'm not nearly as picky about literal constants for integers. The cost/benefit of sticking kind numbers on every integer literal just isn't there. The cost is high because there are a darned lot of integer literals in code, even code that is nominally about floatting point number crunching. The benefit is low because default integer is almost always a good choice (and sometimes the only choice). I did just say "almost" always. Exceptions exist, but those exceptions are where I use kind numbers rathar than doing it everywhere. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: dpb on 14 Jul 2010 20:15 Richard Maine wrote: > dpb <none(a)non.net> wrote: > >> dpb wrote: >>> Lynn McGuire wrote: >> ... >> >>>> However, we got nailed recently by a 0 in a call to a sub with a >>>> double argument. Replacing that with a 0.0 solved the crash. >> ... >> >> BTW, that really should be 0.0D0 (as I'm sure you're aware) but just in >> case one might consider going back to the offending point and making >> sure rather than relying on a compiler switch to promote single/double. > > That's a case where I like to use a parameter ("parameter" as in "named > constant" - not as in a sloppy synonym for "procedure argument"). I like > to avoid real literal constants as actual arguments. I don't make it an > absolute rule; there are cases where real literals seem the best choice > (such as when you have about a zillion of them in close proximity). I am > pretty finicky about using a kind parameter whenever I do use a real > literal as an actual argument. > > The specific case of real zero is common and basic enough that I have a > named constant (r_zero) for the real zero of my working precision (most > often double, but I've made it easy to change - something about having > wasted many, many hours/days/weeks of my youth working on changing > precision while porting code). .... Yes, I'd agree. I started to mention the KIND parameter but didn't owing to the limitation of F77. Then I didn't add the PARAMETERized named constant, either. --
From: Richard Maine on 14 Jul 2010 21:36 dpb <none(a)non.net> wrote: > Richard Maine wrote: > > I am > > pretty finicky about using a kind parameter whenever I do use a real > > literal as an actual argument. > Yes, I'd agree. I started to mention the KIND parameter but didn't > owing to the limitation of F77. Then I didn't add the PARAMETERized > named constant, either. Yeah. F77 was quite a PITA to make reasonably portable for things like that. In the f77 days I did a lot of moving code between machines where you really needed to change between single and double precision as part of the move. In the later f77 days I started using some awkward hacks to somewhat facilitate the process; made me greatly appreciate f90 kinds. One hack I used with some regularity was to have a named constant with the value 1.0 (or 1.0d0). It was usually named something innovative like ONE. Then if I wanted to use a literal constant, say 1.2, for an actual argument, I'd write it as 1.2*ONE. That was a bit awkward, but not as awkward as defining a separate named constant for each such value. It did get the effect I wanted of making the actual argument have the right kind with only changing a single line of source code in the program. (Yes, I used INCLUDE, which was nonstandard f77, but this was late enough in f77 that pretty much all compilers of interest to be supported it. If needed, I could hack an include preprocessor together pretty easily in Fortran myself as a last resort.) Of course this didn't get a value of 1.2 accurate to double precision, but that was not typically important for the kinds of contexts where I'd do this. The value needed to be double precision only for argument agreement. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 15 Jul 2010 03:11 Richard Maine <nospam(a)see.signature> wrote: (snip) > Fortran does not go in for mandatory enforcement of programming style by > the language spec. It is much more about providing the programmer with > options. Many of those style options can be verified/enforced if that is > one's inclination. Maybe, but it does seem that some rules, or rule changes, were meant to discourage some uses. One example is the removal of the use of REAL varaibles in DO loops, added in Fortran 77, then removed in Fortran 90. Yes there can be problems in doing it, but, as you say the language shouldn't enforce the style. I could probably think of some others, but that one comes to mind first. -- glen
From: nmm1 on 15 Jul 2010 03:14
In article <i1mca4$426$1(a)speranza.aioe.org>, glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: >Richard Maine <nospam(a)see.signature> wrote: > >> Fortran does not go in for mandatory enforcement of programming style by >> the language spec. It is much more about providing the programmer with >> options. Many of those style options can be verified/enforced if that is >> one's inclination. > >Maybe, but it does seem that some rules, or rule changes, were >meant to discourage some uses. One example is the removal of the >use of REAL varaibles in DO loops, added in Fortran 77, then removed >in Fortran 90. Yes there can be problems in doing it, but, as >you say the language shouldn't enforce the style. I could probably >think of some others, but that one comes to mind first. That's nothing - C99 has introduced complex time :-) Regards, Nick Maclaren. |