[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Comments on clause 9. Recommended operations in draft 1.6.0
Hello,
Florent de Dinechin wrote on 01.02.2008 19:17:
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."
I am completely okay with this solution. Further generations may still
add functions with different names and behavior. Anyway all these
cornercases we are talking about are more defined by convenience and
faith than mathematical uniqueness.
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.
Okay
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.
I am sorry for contradicting my supervisor on this point. Vincent
Lefevre and myself could show that inexact testing for pow is not more
difficult than correct rounding itself, even simpler... The journal is
accepted for publication but not published yet. See
http://prunel.ccsd.cnrs.fr/ensl-00169409/
for a preprint.
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.
For most functions such as exp, it's no problem at all to do the iff-
raising. For pow see my point above. For functions like erf it might be
impossible (mathematical arguments are lacking)
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.
I don't really see why you think that trigPi might be algebraic and
irrational in the same time.... Being algebraic means being the root of
an integer polynomial.
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.
I think that in any case inexact shall be raised when the result is
inexact and should not be raised when the result is exact. It will be
difficult to state which functions are difficult and with are not.
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.
Seconded in the moment, too. Nobody knows what we will be able to do
until the next revision for the worst-case searches.
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.
I do not see the point in speaking about holes on a discrete set that
are the floating-point numbers. I understand all domain indications in
the draft implicitely intersected with the respective set of
floating-point numbers.
Michel.
Sent: 2008-02-01 16:59:14 UTC
Christoph