[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: a question about formatOf operations
The big picture is that most parts of most programs of most programmers don't
care
very much how the floating point arithmetic is compiled. Anything reasonable
works well enough. Many unreasonable things can be made to work with enough
programmer skill.
BUT every serious programmer writing serious computational
programs will encounter situations where performance is most important, or
accuracy is most important, or reproducibility across platforms is most
important,
or predictability of numerical and exception results is most important.
So in my view the most important issue around floating-point expression
evaluation
is that the programmer have a way of saying what's important, when and where it
matters.
Having said that, reproducibility across platforms is a separate issue
addressed in
clause 11 of recent 754R drafts. That kind of reproducibility is important
for acceptance tests of various sorts, often conducted by people with little
training
in error analysis. Indeed, nowadays an average CS degree may entail a
one-hour lecture
on floating-point arithmetic. It's not realistic to expect that all those
folks
will learn any more about error analysis. Even "random" number generators
need to be
predictable, at least during debugging.
Languages supporting 754R should cater to
the average CS degree by adopting the recommendations of clause 11,
while not slighting the needs of error analysts.
***
However, my posting yesterday was about something unrelated to 754R's
RECOMMENDED
reproducibility across platforms (clause 11).
My concern is a more limited one:
the impact on language definitions and implementations of 754R's REQUIRED
formatOf
operations (clause 5). 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?
Obviously the answer depends on what "provide" means here.
To "provide" named and referenceable functions implemented in a library is one
thing;
to "provide" explicit or implicit
defined or documented macros for sequences of simpler operations is something
else.
I was hoping to find out what interpretations, if any, have been made of the
existing text in clause 5.4.1, which hasn't changed since before September 2006.
(But clause numbers were different then.)
Lucky people who only work with languages with only one floating-point type
don't have to consider any of this.
***
Other comments:
The first thing is that, for the past 40 years, almost all languages
have had a single type system, with built-in types not being special,
and the same conversion rules applying to all of them. Fortran and
C are notorious exceptions, but they aren't as different (nowadays)
as many people think.
The second is that most languages have an extensible type system,
with the application being able to define derived types that behave
almost exactly like built-in types. C is an exception, and does not
support operations on its user-defined types, but Fortran and C++
are not. In particular, the rules need to cater for at least the
following derived type forms:
quaternion(<real type>)
polar(<radial real type>, <angular real type>)
The third is that almost all modern languages have context independence
in their type system (as is regarded as good practice), where the type
of a result is determined SOLELY by the operation and the type of its
operands. Therefore, "binary64 = binary32 + binary80" decomposes into
the context-independent actions "binary32 + binary80" followed by
"binary64 = [[[binary32 + binary80]]]".
... C99 supports only three, fixed, floating-point types, and
does not support operations on user-defined types.
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.
... 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).
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 was simpler to design LHC@home for bit-exact computations, actually
all they needed was a Fortran compiler that can be coerced to do the
same optimisations on Linux and Windows (they used Lahey), and a
correctly rounded libm (they used our CRLibm).
This is a question that arises from time to time, e.g. how can one get the same
numerical results on x86 and non-x86 hardware, other things being equal?
An answer that is satisfactory for many purposes is to use the Pentium IV
SSE2/3/4
registers and a correctly rounded libm. Of course the next question will be
how one can retain that reproducibility and get better performance? Or what
can
be done on a Pentium III laptop that lacks the SSE2 registers? And the answer
is that it is not possible for everybody to get everything they want all the
time.
The main point is that the programmer needs to be able to say what is
important, and get it, when he cares. That does impact language design
and implementation and coding idioms, and hardware design when performance is
also important, as it often is.
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.