[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: a question about formatOf operations
formatOf operations COULD be provided by providing a (potentially long
if many supported formats) list of functions - not pretty or convenient
but not requiring fundamental language rework, with the typical
homogeneous generic operators +-*/ implemented by compiling specific
formatOf operations (typically machine operations rather than
invocations of the explicit functions).
No, they couldn't, not in a language that provides a generic floating-
point facility (as Fortran does). The facility has to be generic.
Now, I will accept that Fortran could easily enough provide functions
for all its standard operators with a KIND parameter for the result
type - that is what it does for CMPLX, after all. I will let Malcolm
argue whether that is anathema.
The 754R operations in question are six: - +-*/, sqrt, FMA.
I don't know of any languages that have operators
that map directly into sqrt and FMA.
To make sure that I
understand, are you saying that having generic operations in some form like
floattype3-addition( floattype1, floattype2)
is relatively feasible to fit into Fortran, for each fixed floattype3, if
floattype1 and floattype2 are the same (homogeneous operands)
but is not relatively feasible if if floattype1 and floattype2 are not
the same (heterogeneous operands)?
But that is a Fortran-specific hack, for Fortran's built-in types only.
(I don't mean to imply an opinion
on your part as to whether "relatively feasible" is feasible enough to
justify adding the homogeneous operand cases to Fortran.)
***
IEEE 754R is supposed to be a generic specification, for arbitrary
languages.
Part of the expository problem of what is a meta-standard for language
standards is expressing the requirements and recommendations in a
sufficiently general way to be broadly applicable to languages but
sufficiently concrete way to be broadly understandable by readers of the
standard from a variety of backgrounds.
nobody responded to even my PREVIOUS request to produce even
minimal draft wording of how bitwise reproducibility could be inserted
into Fortran or C++.
It might also be an impossible job
None of this is impossible;
it could all be implemented in an enormous subroutine
library with no cooperation from the language at all.
I understand your assertion to be that a major rewrite of parts of
the Fortran standard would be required to obtain reproducibility even
in the limited sense of 754R clause 11 (reproducibility).
I don't think that's the principal issue.
In my view, the principal issue is that clause 10 (expression evaluation)
recommends that:
1) languages define the "literal meaning" of arithmetic statements by
translating them into 754R operations
2) implementations translate the source code accorindg to the literal meaning
3) languages define portable (part of the language) means for programmers
to license value-changing transformations and optimizations
4) implementations refrain from performing value-changing transformations
and optimizations except when licensed by the programmer
As an example,
according to these principles, Fortran should define the semantics of
w = x + y + z
whether from left to right or right to left, and if the types differ,
where widening of operands occurs. Implementations should compile
according to that definition. But Fortran should also define
portable directive/attributes with meanings like "allow all value-changing
optimizations" or "allow re-association of unparenthesized expressions"
or "allow re-association of parenthesized expressions that are mathmetically
reassociable", and implementations should respond to those directives
by optimizing the computation. Then the "reproducible mode" of
Fortran would just be the unoptimized "literal meaning" one.
In 754R, "language defined" has a
special implied meaning that, though not preferable, languages could
choose to define certain behaviors by letting implementations define them.
Hasn't this has been the traditional posture of Fortran with respect to
expression evaluation? If that were to continue, then the
"reproducible mode" of Fortran would be much like the unoptimized
literal meaning above, but perhaps described in a different place in the
Fortran standard.