Re: Compiling in 32 vs 64 platform problem

Klaus Wacker <wacker@xxxxxxxxxxxxxxxxxxxxxx> wrote:

Patrick Begou <Patrick.Begou@xxxxxxxxxxx> wrote:

I've discovered that floating point constants in ifort seems to be REAL
and lead to a loss of precision when initializing a DOUBLE PRECISION
variable.
DOUBLE PRECISION t=2.33D0
is not the same than
DOUBLE PRECISION t=2.33


This has nothing to do with ifort or any other particular compiler.
The Fortran standard (at least since F90) implies that 2.33 is a real
(i.e. single precision) constant.

It more than implies it. It says that in black and white, and has since
f66.

Some compilers have taken it on themselves to "help" users by trying to
figure out what the user meant, as opposed to what the user said. There
is a school of interpretation that says compiler were allowed to do this
prior to f90, but no longer are allowed to do so as of f90. That is, the
debate is about whether compilers are allowed to do this as an extension
to the standard or whether a compiler that does this violates the
standard. THat is a subtle debate, but in any case...

There has *NEVER* been any question as to what the user code means
according to the standard. It means a single precision literal. The only
point of any debate at all has been whether compiler are allowed to
"fix" what it and do what they think the user meant. This is a debate
for the compiler writers - not for the users. There is not even a hint
of justification in any version of the standard to suggest that users
are allowed to assume the compiler will "fix" this; users who assume
that are counting on behavior not specified by the standard - either an
extension or a violation, depending on your interpretation of the fine
points.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
.

Relevant Pages

  • strange implementation of quad precision in Absoft
    ... The Absoft quadruple precision extension of their Fortran 95 compiler is ... They use two "standard" double ... precision numbers, say D1 and D2 with D1 having the most significant digits. ... The reason IS that D1 contains the first 16 decimal digits of the ...
    (comp.lang.fortran)
  • Re: Weird problem on Lahey lf95 v6.2b
    ... > I've encountered using the Lahey F95 compiler for Linux. ... > Here, ais a double precision array, and ba default real array; ... > print statement, but in the second and third has been truncated down to ... I think this is non standard conforming and ...
    (comp.lang.fortran)
  • Re: Is C99 the final C? (some suggestions)
    ... > that someone will try compile their stuff on an old compiler. ... > because the ANSI standard obsoleted them, and everyone picked up the ANSI ... fixed by using another language. ... >>are multiplying two expressions of the widest type supported by your ...
    (comp.lang.c)
  • Re: Fadal 104/D(eceased)
    ... >> CNC controls. ... >> runtime program toggle from single precision to double precision ... >> My question is that we have standard NEMA motors, ... Why not standard controllers and g/n ...
    (alt.machines.cnc)
  • Re: Fadal 104/D(eceased)
    ... > CNC controls. ... > runtime program toggle from single precision to double precision ... > power why can't a standard ... Why not standard controllers and g/n ...
    (alt.machines.cnc)