Re: Edge case conversions, exceptions to IEEE FPA
Arnold et al,
Arnold Neumaier wrote:
.
.
.
realmax is converted to itself, and inf to realmax, the closest finite
floating-point number.
That somehow bothers me. It seems analogous to always rounding
down, if inf represents some real number greater than real max.
In Siegfried's sproposal, realmax is converted to itself, and inf to
[realmax,inf] = {x|x>=+realmax}.
Although, as acting chair, I'm supposed to be impartial, this seems
a bit more logical to me. (Everyone: just take this statement of
mine to be an opinion from a member, not direction from the acting chair.)
Official comment from the acting chair:
This is an issue that should be resolved by itself with a formal vote,
once the P&P is ratified. Then, it should be proposed, seconded, and
voted upon.
Therein, intval(+realmax) -> [+realmax,+realmax], so there is no
difference between +realmax and +inf, and we might as well use +inf.
There are many real numbers between realmax and inf. The symbol "inf"
is used, is it not, to represent all such real numbers, just as each other
floating point number is derived from a set of real numbers near that
floating point number. Won't there be a problem of loss of rigor if
we map inf back to realmax?
If P1788 is based upon P754 we still have the problem that [a,+realmax]
+ [b,+realmax] -> [a+b,+inf] with overflow signaled.
This is not a problem since inf as endpoint is completely
uncontroversial. The conflict is about what to do with a floating-point
inf that arose from a floating-point computation or conversion from text
done for the sake of itself rather than as part of an interval computation.
Doesn't floating point inf often mean that the exact answer was actually greater
than realmax? Thus, wouldn't it be correct to say that the exact answer
is in [realmax,\infty) ? Of course, this isn't true for things like 1/0.
Should the IA
implementation trap the overflow signal and convert the interval to [a
+b,+realmax]? How is this different from leaving the result as [a+b,
+inf]?
No.
This would remove the above strangeness.
I think it just moves the strangeness somewhere else.
inf is needed as a bound, and this is uncontroversial.
Yes, that's my perception. Everyone, is that true?
.
.
.
So you suggest to use inflation 2ulp wide for conversion of floats?
What then about intval(0.5) or intval(0.5e1)?
intval('0.1') should become something sharper than intval(0.1).
1ulp wide?
Acting chair statement:
In intval(0.1), the underlying operation 1788 would be defining is
conversion from a float to an interval. In intval('0.1'), the
underlying operation is conversion from an external character representation
to an interval. In the latter case, there is the potential to convert it
into the smallest floating point interval that contains the exact result.
Member opinion statement:
In the former case, I don't see how we can know what it should be
other than the singleton interval both of whose end points are the corresponding
floating point number. In this regard, I am sympathetic with Siegfried's
statement that the only thing that can be done is user education. (Siegfried,
am I "quoting" you accurately?)
.
.
.
Best regards,
Baker
--
---------------------------------------------------------------
R. Baker Kearfott, rbk@xxxxxxxxxxxxx (337) 482-5346 (fax)
(337) 482-5270 (work) (337) 993-1827 (home)
URL: http://interval.louisiana.edu/kearfott.html
Department of Mathematics, University of Louisiana at Lafayette
(Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
Box 4-1010, Lafayette, LA 70504-1010, USA
---------------------------------------------------------------