[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: a question about formatOf operations
My concern is a more limited one: the impact on language definitions and
implementations of 754R's REQUIRED formatOf operations (clause 5).
Let's stick with this one. As I posted, we shall never agree on whether
reproducibility is desirable.
Given that languages will in any case have to "provide" narrowing
arithmetic operations with HOMOGENEOUS operand formats get single
roundings when required, how much more impact is going to be due to the
additional requirement to "provide" narrowing arithmetic operations of
HETEROGENEOUS operand formats?
Considerable, for the reasons I gave.
No language would want to build in all the numerical types that are
useful in all important applications. So having a way that user-defined
types can be as easy to use as built-in types is an essential feature
for a modern language, I think. But I get the impression that C++ has
given operator overloading and perhaps polymorphism a bad name. 754R
doesn't specify HOW operations are to be "provided" since languages vary
so much, so a lot of uncertainty can be bound up in the interpretation
of "provide," which is why I asked about it.
Indeed. And I was pointing out that it is unclear whether ANY
reasonable interpretation is feasible in many currently important
languages.
... Even if "formatOf" had tackled the problem
properly, fitting it into any existing language would be a brass-bound
nightmare.
... let's see a draft proposal of how "formatOf" could
be specified in Fortran or C++ without forcing radical changes to the
existing language designs
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.
But that is a Fortran-specific hack, for Fortran's built-in types only.
IEEE 754R is supposed to be a generic specification, for arbitrary
languages.
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 be a pretty big job, of course, that nobody wants to pay for
until the 754R draft is finalized. Over the last six months, the clause
11 reproducibility spec has been made much more achievable by giving up
on reproducibility with respect to underflow and inexact exception
signals. I consider that a positive step.
It might also be an impossible job, and specifying an impossible task is
Not Clever. After all, I stated that I believe that it is, and that isp
precisely why I say that YOU need to provide evidence that it isn't.
If I were intending to walk from Cambridge to Houston, heading east-
south-east would be a positive first step. I might have some minor
difficulty when I got to Cornwall, of course.
Did you know that there are potential differences on Intel platforms
due to the alignment of aligned operands?
That sounds like a bug at some level.
Why should it be? Why shouldn't it be a feature?
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