[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: a question about formatOf operations
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.
And that is the first mistake :-( 40 years ago, Algol 68 demonstrated
the benefits of orthogonality on the compactness (and, much more
importantly) correctness of specifications. Fortran took that on board
30 years ago, and has a de-facto (perhaps de jure) policy of avoiding
non-orthogonal features. C++ always has had one. ISO C doesn't.
It is a cardinal mistake to introduce a major feature that is not
conceptually extensible, and will cause bitter opposition (for very good
reasons). The current draft (7.1) is written generically, which is
right. But why doesn't 7.4.1 have 'formatOf nextAfter', to mention just
one significant omission that I have had to code several times?
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)?
Actually:
addition-function(floattype1 arg1, floattype2 arg2, floattype3)
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.)
I am not the one who counts here - ask Malcolm!
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.
Yes, but I am NOT talking about the description! I am referring to the
basic CONCEPTS - get those incompatible, and mapping one to the other is
infeasible.
Why do you think that no language has included even all of the mandatory
parts of IEEE 754 in 24 years? And the few attempts to provide ANY
support have been along the lines of providing syntax for implementors
to define the semantics of if they wish. It is utterly impossible to
write EITHER portable or reliable IEEE 754 code in any language I know
of, let alone portable AND reliable code.
[ Please don't bring up C99 here - I know as much about that area as
anyone, and I can justify my statements in depth. ]
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.
That is true - at least in Fortran and, I believe, C++. C is beyond
redemption, but that's not IEEE 754R's fault.
However, do you know what the reaction of users would be to having to
write code along the style of Autocode, but with the verbosity of Cobol?
A = B+C*D
turns into:
CALL MULTIPLY(temp1, C, D)
CALL ADD(temp2, B, temp1)
CALL STORE(A, temp2)
No way, Jose!
[ Note that the apparent compromise of using functions doesn't work
in Fortran and C/C++, but for completely different reasons. The
former is due to the execution model, and the latter to the side
effect problem. ]
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
Impossibility the first. Fortran is based on incompatible concepts.
Its execution model would have to be gutted to do that.
2) implementations translate the source code accorindg to the literal meaning
Difficulty/Impossibility the second. None of Fortran, C++ or C have
the concept of a "literal meaning" in IEEE 754R terms. C's abstract
model could be changed to meet it readily enough, though it would be
unbelievably politically contentious, but I doubt that Fortran's or
C++'s could.
Note that changing C's abstract model would mean, inter alia, solving
the sequence point definition problem. Have you ANY idea of how much
effort has gone into that with no headway, and the bitterness of the
controversies?
3) languages define portable (part of the language) means for programmers
to license value-changing transformations and optimizations
Impossibility the third. Words fail me on how incompatible that is
with Fortran and C++. It doesn't make any difference whether such
means are static or dynamic, because neither are strictly block-scoped
languages. It would necessitate defining what that means when, for
example, a class compiled in one mode is used to define an object in
a second and the destructor is then called in a third.
Note that I am not talking about this as a technical impossibility, so
much as a political one. I don't believe that any of the standards
organisations would tackle a change of that magnitude or could handle
it successfully.
4) implementations refrain from performing value-changing transformations
and optimizations except when licensed by the programmer
Impossibility the fourth. See (1) and (4). Inter alia, it means
forbidding all the liberty for higher-level optimisation that Fortran
and C allow. I can guarantee that users will not tolerate that, no
matter what the standards say.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: nmm1@xxxxxxxxx
Tel.: +44 1223 334761 Fax: +44 1223 334679