[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Comments on clause 9. Recommended operations in draft 1.6.0
Michel Hack a écrit :
I am at a loss to figure out what to do this late in the game. I've
been picking at some details, not wanting to upset the applecart at
this point, but the following argument from Christoph Lauter is very
compelling -- especially the last sentence:
If it is too late in the standardization process for important changes
on sound mathematical grounds, subclauses 9.1.1 and 9.1.2 should be
removed from the draft and the special cases of the functions figuring
in Table 9.1 should be added. The standard should then state clearly
that only functions in Table 9.1 are to be considered conforming.
This is clearly not the solution we were intending but would prevent
further generations of people involved in revisions of the standard
from having to deal with "legacy" implementations based in this (at
the moment inconsistent) revision.
I'm not that desperate. The most controversial math (9.1.1, first item,
after the "except") can be simply replaced with "except if explicitely
stated otherwise in 9.2.1."
Particularly troublesome are the recommendations about Inexact signalling,
which are just the opposite of each other:
Draft 1.6.0 permits OVERindication of Inexact.
The experts suggest permitting UNDERindication,
and argue that this should not apply to directed rounding
because in that case correct Inexact indication follows
from correct rounding.
Yes, as soon as you are able to ensure directed-mode correct rounding,
inexact comes for free.
Here our motivation was one of runtime performance: For algebraic
functions such as pow, deciding inexact is very costly, and we felt the
rare usage of the inexact flag did not justify this cost.
However we didn't intend to introduce an inconsistency with other parts
of the standard, e.g. 7.6.
So I think overindication of inexact is OK, too. What would have a huge
performance cost is to raise inexact if and only if the result is inexact.
And yes, it won't be that costly for transcendental.
Christoph, please correct me on all this.
Otherwise I'm sure that you can find valid use cases where
overindication is better than underindication, and valid uses cases for
the opposite.
My own impression is that, for transcendental functions, the
second approach is the right one, but for algebraic functions
like pown(), rootn(), hypot() I think that the first one may
be more appropriate: the result could be exact even though
some intermediate results were not. For algebraic functions
like trigPi the results may be algebraic, but are in most cases
provably irrational, so they behave like the transcendental ones.
This leaves two possibilities (for correctly-rounding implementations,
otherwise the issue may be moot, with Inexact essentially undefined):
(a) Leave Inexact completely undefined, or
(b) Require correct Inexact indication for transcendental functions,
and permit overindication for the simple algebraic functions.
Not sure what (a) means: it applies only to 9, right? We keep 7.6? Then
I'm OK.
(b) is better, but it needs to list explicitely those which have a shall
and those which have a should.
I also have some comments on
http://perso.ens-lyon.fr/christoph.lauter/revisionIEEE754.txt
First, I am utterly grateful that this is a plain-text document!
I wonder whether something more should be said about Inexact for the
algebraic functions.
On conformance (D.3) -- this actually applies to the current draft 1.6.0
(and earlier ones) as well: Should we say something about conformance
not just in a particular radix, but also in a particular format?
There may for example be a correctly-rounding binary64 implementation,
but also a binary128 implementation that can only guarantee some error
bounds, in the same language.
Seconded.
In the list of domains (D.4), I would add a comment that the FP domain
of tan x does not have holes (because the mathematical holes are not
representable input values).
It depends what you mean by hole. In some (pathological?) formats, the
tan of some values could overflow, and be defined (unambiguously) as
+infty or -infty. I'm sure it doesn't happen for binary64, but it needs
to be checked for other formats as well.
Michel.
Sent: 2008-02-01 16:59:14 UTC