[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Zeroes and infinities
Peter Henderson <petercbh@xxxxxxxxxxx> wrote:
If the sign of zero bothers you, ignore it. It will only cause you
problems ...
.
No, that is wrong. The problem is that you CAN'T ignore it, because
IEEE 754, the way that it is interpreted, Java, C99 and so on make
the sign of zero cause wrong answers in all sorts of ways.
An example would help me to understand what you are getting at.
Try 1/((x+y)^2-x^2) < 0. That can't happen in mathematics, but
can in IEEE 754 - without ANY loss of precision, either! There are
lots of other such examples, and many have been posted recently.
Because copysign is defined for zero, language sign functions no
longer give an error - so you don't get told when you make a mistake.
This is a matter of poor compiler or library implementation. The sign
type function, and its close cousins the copysign functions come with
various definitions. Differnet languages define different versions.
I will withdraw this one! While Fortran HAS changed, it did so in
1977, and so IEEE 754 was NOT the reason. There are few other
languages that predate IEEE 754 and are still active. I stand by my
remark about its undesirability, but not about its impact.
The FORTRAN version, for example, returns 1 for zero.
Er, no. Look it up. But, as I said, I withdraw that one.
Because IEEE 754 forbids stopping on serious exceptions
This is definitely not true. IEEE 754 states an implementation "should"
provide the ability to define alternative exception handling
procedures. ...
That is misleading to the point of being false. Not merely is the
ONLY mandatory mode non-stopping, it is required to be the default,
and the only other, generally implementable, mode is not one of the
ones described in Annex E. All of those in E.2 are called
non-resumable, but actually resume execution at another level.
It actually says precisely that!
If I recall, IEEE 754 itself doesn't even MENTION the possibility
of alternate exception handling, and thus states non-stopping is
mandatory.
One might quibble that it also suggests these should behave
like functions that return a value, but it certainly does not forbid
stopping and I don't think the original committee ever intended such a
thing.
Oh, really? Can you provide any evidence of that? E.2 in fact SAYS
that non-resumable handling means that execution is resumed elsewhere.
, and languages generally can't support its flags (and that DOES
include C99), you have to rely on the values. And dividing by a
zero turns it into a signed infinity :-(
This is hardly IEEE 754's fault. Many languages have the facility to
specify a function as a trap handler, but that is all that is generally
available. Few, if any, languages support sophisticated responses.
Actually, many do. MANY languages have exception mechanisms - indeed,
one could say that almost all modern ones do.
As I posted a while back, the reason that they don't include IEEE 754
exceptions in their exception handling model is because of the
intrinsic architectural incompatibilities. I also said that this
is a SOLUBLE problem, but needed BOTH sides to make compromises;
and I can see little willingness to do that, on either side :-(
Except for Fortran. I think that you COULD get somewhere there, but
you would HAVE to make changes.
Similarly, the type of traps, i.e. an alternative execution path,
envisaged by the IEEE 754 standard cause real complications for modern
processors with deep pipelines and the possibility of out-of-order
instruction execution. Flags cause similar problems. It is generally
faster and easier to check the return values.
That is, again, seriously misleading.
There are well-known mechanisms that do NOT cause the same amount of
trouble, and they were well-known by 1980. There is an unavoidable
conflict between optimisability and the reliability of such detection,
but the IEEE 754 is at one extreme. As I said, the ONE form that is
not a problem (LIA-1, 6.1.3 Termination with message) is not included
in Annex E, despite being requested by several people.
Numerous people have observed that language standards committees seem to
consider floating point support as an unfortunate necessity and the
annexes of the draft IEEE 754R contains a number of what can only be
described as pleas for better support.
That is not true for Fortran, and is not true for some of the numeric
experts highly influential in many other languages.
The reason that Fortran (and they!) have not provided support for
IEEE 754 is that IEEE 754's model is intrinsically incompatible with
being embedded in a conventional high-level language. I have reason
to believe that was pointed out when IEEE 754 was being developed, and
know that it was frequently pointed out during the revision.
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