IDE for ifort on Linux
in [Fortran]
|
From: dpb on 11 Jul 2010 19:33 Louis Krupp wrote: .... >> character(len=10), parameter ::& >> & fmt_f = '(ES14.6)'& ! 7 digits >> & fmt_d = '(ES22.13)' ! 14 digits. .... > Stupid question: > > Can you remove the '(len=10)'? ... Yes... LEN=* (I'm not sure if later than F90/95 syntax allows for even that to go away or not...) --
From: David W Noon on 11 Jul 2010 20:47 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 11 Jul 2010 15:29:48 -0700 (PDT), steve wrote about Re: IDE for ifort on Linux: >On Jul 11, 2:39 pm, David W Noon <dwn...(a)spamtrap.ntlworld.com> wrote: [snip] >> Aha. So what does this buy me? > >See Dan Nagle's reply. > >module formats > implicit none > character(len=10), parameter :: & > & fmt_f = '(ES14.6)' & ! 7 digits > & fmt_d = '(ES22.13)' ! 14 digits. >end module formats > >Now, use this module everywhere in your project. If >you find out that double precision actually has 15 digits >of precision, then you only need to change one line of >code for the entire project. This might seem the wrong way around, but I first decide how much display precision I need and then declare variables of suitable type to supply that display. If I need to print from multiple locations, I code a print subroutine with the appropriate format(s) and call that from wherever I need. I have been doing things that way for over 35 years and it has worked well so far. The upshot is that I am so myopic that I still don't see what the above buys me. [I.e., this is undoubtedly change, but I'm not convinced that it is progress.] - -- Regards, Dave [RLU #314465] ======================================================================= dwnoon(a)spamtrap.ntlworld.com (David W Noon) Remove spam trap to reply by e-mail. ======================================================================= -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAkw6ZiAACgkQ9MqaUJQw2MmyCwCaAxGMzlUbAfrq/O6tVAp7xxTn uUQAn01PnoAJS/NuHIKLWv7nGTvHMlE0 =CCQD -----END PGP SIGNATURE-----
From: Ian Harvey on 11 Jul 2010 21:19 On 12/07/2010 2:09 AM, Dan Nagle wrote: > On 2010-07-11 09:40:45 -0400, dpb <none(a)non.net> said: > >> David W Noon wrote: >> ... >>> On Sat, 10 Jul 2010 14:40:22 -0700 (PDT), mariano mendez wrote about >>> Re: IDE for ifort on Linux: >>> >> ... >> >>>> - Standarizing Iinput / Output : remove all format statement and >>>> replacing it with character(len),parameter FmtString replacing all >>>> format labels with format string. >>> >>> That is counter-productive. >>> >>> Quite often a format is used in many places, so referring to a label is >>> very convenient, because any change to the format can be applied in a >>> single place and all references pick it up automatically. If you put >>> character string formats all over the place, any changes need to be >>> applied all over the place too. >> ... >> >> In addition to which it's not likely that the compiler would find >> duplicate strings this way and will thus store every copy in the >> executable instead of referring to one. >> >> Agree this doesn't seem like _a_good_thing_ (tm) in general practice. > > I don't see how this follows. > There may be some confusion between named constants > and literal constants. > > Note that the OP wrote "character(len),parameter FmtString" > > I put formats in named character constants, > and put the named character constants in a module, > and I can make a change in one place (the module) > and have it used everywhere. In the absence of a redesign of the whole IO system, it is a pity that alphanumerically labelled format statements, that perhaps can be host or use associated, are not part of the modern language forms. Character constants seem like a reasonable option given the limitations of the language in this area. Even character variables, which then offer the possibility of run-time configuration of language (though ordering is still an issue), but with the downside of loss of compile time checking that you haven't done something stupid. Numeric statement labels bite. We have alphanumeric labels for the various program flow control constructs, why not other statements?
From: jfh on 12 Jul 2010 17:40 On Jul 12, 12:47 pm, David W Noon <dwn...(a)spamtrap.ntlworld.com> wrote: > This might seem the wrong way around, but I first decide how much > display precision I need and then declare variables of suitable type to > supply that display. ... I have been doing things that way for over 35 > years and it has worked well so far. If so, you have never had a numerical problem like the volcanological one I had a few months ago, where double precision (15 significant digits) was not good enough to give 3 correct significant digits in the answers, but extended precision (18 digits) was good enough for 5, as shown by quadruple precision (33 digits) giving the same results. (Fortunately, g95 on some platforms allows all those real kinds, and in one of the rare exceptions to Murphy's law I needed none of the quad precision features that g95 hasn't implemented yet.) The reason was the usual one: if x and y are much nearer each other than either is to zero, then the relative error in x-y can be (and by Murphy's law, usually is) much larger than that in x or y. -- John Harper
From: David W Noon on 12 Jul 2010 20:12
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 12 Jul 2010 14:40:49 -0700 (PDT), jfh wrote about Re: IDE for ifort on Linux: >On Jul 12, 12:47 pm, David W Noon <dwn...(a)spamtrap.ntlworld.com> >wrote: > > >> This might seem the wrong way around, but I first decide how much >> display precision I need and then declare variables of suitable type >> to supply that display. ... I have been doing things that way for >> over 35 years and it has worked well so far. > >If so, you have never had a numerical problem like the volcanological >one I had a few months ago, where double precision (15 significant >digits) was not good enough to give 3 correct significant digits in >the answers, but extended precision (18 digits) was good enough for 5, >as shown by quadruple precision (33 digits) giving the same results. >(Fortunately, g95 on some platforms allows all those real kinds, and >in one of the rare exceptions to Murphy's law I needed none of the >quad precision features that g95 hasn't implemented yet.) The reason >was the usual one: if x and y are much nearer each other than either >is to zero, then the relative error in x-y can be (and by Murphy's >law, usually is) much larger than that in x or y. I have never worked in volcanology, but in the 1970s and early 1980s I worked in a chemical laboratory. I was occasionally confronted with problems involving chemical reactions and their associated thermodynamics that posed the same issues of loss of significance and other symptoms of ill-conditioning. I was always lucky enough to spot these issues before coding, so I have never had to rework the code to address them. Of course, one factor was whether or not the chemist or chemical engineer who "owned" the problem could capture data accurately enough to say that the input numbers were worthy of double precision, extended precision, etc. But that is not a problem any programming language can address. - -- Regards, Dave [RLU #314465] ======================================================================= dwnoon(a)spamtrap.ntlworld.com (David W Noon) Remove spam trap to reply by e-mail. ======================================================================= -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAkw7r1oACgkQ9MqaUJQw2MnWYQCdEq47vAPSieHYYbG7zpzNRPCu nXQAoIJZxHH5FqKEX3x1TfqspZasO+wz =A5gJ -----END PGP SIGNATURE----- |