Re: Numeric literals

From: Paul Van Delst (paul.vandelst_at_noaa.gov)
Date: 09/03/04 

Date: Fri, 03 Sep 2004 10:58:45 -0400

Herman D. Knoble wrote:
> J.E. Atkin gives a Math_Constants module which would mean
> you don't even need to write the actual constant. See:
> http://www.owlnet.rice.edu/~mech517/Books/oop2.pdf.
>
> Actual DP code for this may be found at:
> http://ftp.cac.psu.edu/pub/ger/fortran/hdk/MathConstants.f95

Gasp! A Fortran source file with a .f95 suffix! :o)

Shouldn't pi_Log10 be Log10_of_pi ?

Thanks for the links

cheers,

paulv

>
> Skip Knoble
>
> On Thu, 02 Sep 2004 22:51:10 GMT, "James Giles" <jamesgiles@worldnet.att.net> wrote:
>
> -|'Tis still the season for recommendations for new language
> -|features. There's a minor syntactic ability that I always liked
> -|about fixed-form source that free-form doesn't permit: the
> -|ability to have spaces within numeric literals. It's much
> -|easier to read and verify the correctness of a long literal
> -|if you are permitted to space the digits out in some manner.
> -|All conventional human activities that involve long digit
> -|strings permit (even sometimes enforce) certain spacing
> -|conventions. Telephone numbers: (505)123-4567; Social
> -|Security numbers: 123-45-6789; money: $12,345.67; and
> -|so on.
> -|
> -|The "natural" choice within an programming language is
> -|the kind of thing that Ada allows: you permit the programmer
> -|to put an underscore (just one) between any two digits of
> -|a literal, nowhere else. But, Fortran already uses the underscore
> -|for a KIND introducer. Without getting into a discussion of
> -|the wisdom of that choice, we need to choose some other
> -|character (or do without the feature).
> -|
> -|One possibility is to reintroduce the possibility of spaces within
> -|literals. This is not syntactically ambiguous. The rule would still
> -|remain that spaces are significant, just that within literals their
> -|significance is different than elsewhere. (This requires some
> -|extral look-ahead in the lexical scanner of a kind that Fortran
> -|already requires for other reasons in other contexts, So the
> -|implementation effort should not be too great.) The rule would
> -|be similar to Ada's: only allow spaces between digits, and only
> -|one. Hence you could write:
> -|
> -| PI = 3.14159 26535 89793 23846_mykind
> -|
> -|But not:
> -|
> -| PI = 3. 14159 26535 89793 23846 _mykind
> -|
> -|since the first space is between the period and a digit and not two
> -|digits and there are two spaces in each of the remaining locations
> -|rather than just one, and finally no space is allowed before a KIND
> -|specifier. The rule could also be applied to BOZ constants (without
> -|any syntactic complexity in that case since they are delimited).
> -|
> -|Aside from spaces, the other possible choices are few. I would
> -|assume that non-ASCII characters are not likely to be popular
> -|choices (though anyone with a standard compliant news/mail
> -|browser can handle ISO Latin-1). The ASCII characters not
> -|presently used in Fortran in possibly conflicting ways are:
> -|
> -| " # $ % ' ? @ \ ^ ` { } | ~ (or letters other than E, D, and H)
> -|
> -|Not a very appetizing choice. Many don't effectively increase the
> -|legibility of the literals. Of these, my favorite would be grave
> -|accent (`). The legibility is good and, because of context, it isn't
> -|easily mistaken for any other meaning even in fonts where it's
> -|difficult to distinguish from apostrophes. The same rule (only
> -|one, and only between digits) gives:
> -|
> -| PI = 3.14159`26535`89793`23846_mykind
> -|
> -|So, what does everyone think? I'm going to propose *something*,
> -|but I'd like feedback first. If you really think that *no* such feature
> -|is required, I'll not argue with you (that's for the committee to decide
> -|after the feature is recommended). But I'd like to know if anyone
> -|has preferences between the available choices.
>
>
> Herman D. (Skip) Knoble, Research Associate
> (a computing professional for 38 years)
> Email: SkipKnobleLESS at SPAMpsu dot edu
> Web: http://www.personal.psu.edu/hdk
> Penn State Information Technology Services
> Academic Services and Emerging Technologies
> Graduate Education and Research Services
> Penn State University
> 214C Computer Building
> University Park, PA 16802-21013
> Phone:+1 814 865-0818 Fax:+1 814 863-7049

Relevant Pages

  • Re: Integer representation
    ... Herman D. Knoble writes: ... > Herman D. Knoble, ... > Penn State Information Technology Services ... > Penn State University ...
    (comp.lang.fortran)
  • Re: Is this legal Fortran 77?
    ... Penn State University Center for Academic Computing ... > Herman D. Knoble, ...
    (comp.lang.fortran)
  • Re: ALLOCATABLE arrays
    ... In article, Herman D. ... >Lawson: Apologies if I misunderstand you post here. ... >Skip Knoble, Penn State ... >-|that the shape of an automatic array must rely on an argument to the ...
    (comp.lang.fortran)
  • Re: Select case restrictions
    ... "Herman D. Knoble" wrote in message ... the program was helpless to trap invalid input at run-time, ...
    (comp.lang.fortran)
  • Re: Lowercase
    ... Herman D. Knoble wrote: ... Back in December 2001 Richard Maine posted a standard Fortran 90 code that ... Given that this was written by RM, I'd be surprised if that's' a correct reading! ...
    (comp.lang.fortran)
Loading