Re: Edge case conversions, exceptions to IEEE FPA
R. Baker Kearfott schrieb:
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.
Well, any finite number is closer to realmax than to infinity.
(The 754 standard is a bit inconsistent in its interpretation
of ''round to nearest''.)
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.
I don't think that the floating-point number 2 is derived from a set of
real numbers near 2.
Won't there be a problem of loss of rigor if
we map inf back to realmax?
If we consider inf to represent all numbers > realmax
(actually according to 754, it should represent only numbers
>realmax(1+eps/2) or so)
the we should consider realmax to represent all numbers
beteen realmax-1ulp/2 and realmax+1ulp/2 and 2 to repesent all numbers
between 2-1ulp/2 and 2+1ulp/2.
This seems to me consistent but not practical, for two reasons:
1. Everyone wants to convert 2 to [2,2].
2. Once several operations were done to obtain a float, the bounds
may already be too narrow.
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?
Often, but perhaps more often not, once additional operations are
being performed.
1.001*x-x is still represented by inf if x=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.
Yes. This is in my proposal.
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?)
The question here is which stand you take as a Member when in place
of 0.1 you have 1e308 or 1e309. These are converted into a finite
float f and an infinite float, respectively. In the first case,
your argument extends to return [f,f]; in the second, to return
[inf,inf]=Empty. This is my proposal, at least.
Arnold Neumaier