11-260r1
To: J3
Subject: Interpretation request F03/0121
From: Van Snyder/Stan Whitlock
Date: 13 October 2011
Reference: N1875
Ballot comments
---------------
Corbett comment
Fortran programmers need the functionality proposed in the request for
interpretation. The mechanism proposed corresponds to what many Fortran
programmers already assume to be the case. The committee should either
adopt the proposed mechanism or provide an alternative mechanism.
Long comment
My reading of the original question included a desire to say that the
result value for REAL(X, KIND=wp), for a particular value of X, is the
SAME result value independent of the context in which the function
reference appears. After all, it would not really be a "function" in
the normal sense if that were not the case. The subsequent discussion
in the ANSWER section could cast doubt on whether this basic requirement
is actually true. It would be better to explicitly state that REAL for a
particular set of arguments always returns the same result value
independent of the context.
Snyder NO vote
An ugly unsatisfying answer that appears to have been crafted by a
politician trying to evade the real issue, perhaps because of a
deficit of knowledge of issues important in numerical analysis.
I don't understand the necessity for REAL not to do what it
says it does. The answer simply confirms a contradiction. My
answer would be yes if the answer were that REAL(,KIND=k)
returns a value that is the same value that a REAL variable of
kind k would have, if were to have been assigned to that
variable. After all, REAL is a function, and therefore has a
result variable to which its result value is assigned.
Revised interpretation
----------------------
NUMBER: F03/0121
TITLE: Precise FP semantics of the REAL intrinsic
KEYWORDS: REAL intrinsic
DEFECT TYPE: Clarification
STATUS: Passed by J3 letter ballot
QUESTION:
Must the intrinsic function REAL with KIND parameter wp return a value
that is a REAL (KIND=wp) floating point number?
RATIONALE FOR THE QUESTION:
Computer hardware may use a wider floating-point format for registers
than for memory; e.g., 80 bits for registers and 64 bits for memory
for the case of standard double precision floating point numbers.
Some algorithms require a high level of control over floating point
semantics. If the intrinsic function REAL with KIND parameter wp is
guaranteed to return a REAL (KIND=wp) result then a programmer can use
this to force intermediate results into main memory format, never mind
that the optimizing compiler may have placed the intermediate in a
register.
I am interested in a J3 interpretation of this matter, especially a
loud and clear affirmative interpretation, because it appears that
some present Fortran compilers optimize away my explicit use of the
REAL intrinsic. The context is code for compensated summation (Kahan
summation). I appreciate that parentheses are inviolable courtesy of
the Fortran standard, but in order to have code that cannot be broken
by an optimizing compiler I seem to need also a language mechanism to
force intermediate results into main memory format.
Bas Braams
Chemistry Department and
Emerson Center for Scientific Computation
Emory University
Atlanta, GA
ANSWER:
Yes, for purposes of determining the type and kind of the result, for
use in subclause 7.1.9.3, the result of the intrinsic function REAL with
KIND argument wp returns a value that is of type REAL(KIND=wp).
However, if it is used within an expression involving intrinsic
operations,
"the processor may evaluate any mathematically equivalent
expression, provided that the integrity of parentheses is not
violated."
and
"mathematically equivalent expressions of numeric type may produce
different computational results",
which means that it is unlikely to serve your purpose.
Intermediate results can be rounded to storage format by assignment to a
VOLATILE variable.
EDITS to 10-007r1:
None.
HISTORY: 08-208r1 m185 F03/0121 submitted
10-240 m193 Draft answer for F2008 - Passed by J3 meeting
11-129 m194 Passed by J3 letter ballot #22 10-254
11-260 m196 Revised answer
11-260r1 m196 Revised answer