Re: YES P1788/M0029.02:Level3-InterfaceOnly, *BUT*
Lee, Michel, P1788
On 30 Dec 2011, at 14:35, Lee Winter wrote:
> On Thu, Dec 29, 2011 at 6:00 PM, Michel Hack <hack@xxxxxxxxxxxxxx> wrote:
>> Lee Winter wrote:
>
>>> Exemplar: Given M = F.max for some 754 format F, then given lo=0.8*M
>>> and hi=0.9*M the interval I_one=[lo hi] is a valid value. But the
>>> interval I_two = 2 * I_one is not a valid interchange value.
>>
>> No problem:
>> I_two would simply be [F.max, +Inf] -- overflow has to observe containment.
>
> That happens to be the IEEE-754 result of outward rounding. But it is
> not the tightest expressible containing interval. The tightest
> expressible containing interval is {+ovr +ovr].
>
> Note that overflow is not a point on the number line. For inputs that
> are all normal numeric values an overflow result represents "the rest"
> of the number line from above the maximum representable numeric value
> toward, but not to, infinity; tus values of arbitrarily large, but not
> infinite, magnitude. N.B., the term "infinity" in the IEEE-754
> standard is in no way related to mathematical infinity. As I
> understand it the term was selected to make overflow a feature rather
> than an error so that the standard would be accepted by (thus be
> salable to) uninformed people to whom errors are anathema.
I cannot vouch for the motivation of people on the IEEE 754-R working group, or their view of the meaning of various 754 terms. But the standard resulting from their work *says*, in Clause 3.2, just below Table 3.1:
> The mathematical structure underpinning the arithmetic in this standard is the extended reals, that is, the set of real numbers together with positive and negative infinity.
This is unambiguous, and contradicts Lee's view.
I think Siegfried Rump's recent paper is a great piece of work, whose implications I am still absorbing. It could well lead to a practical interval arithmetic that handles overflow and underflow better than we currently can. But P1788 chose a different, simpler model early on. For many reasons we cannot switch models now. A compelling reason, to me, is that Siegfried's system is unfamiliar to the whole interval community (not just us); it has not been worked out in detail or implemented; experience with an implementation might uncover practical flaws such as those that Arnold and Nate found with my own favourite, namely cset interval arithmetic. So its time has not yet come.
Meantime, P1788 is unambiguously based on a system in which
- A floating point format is basically a subset of the extended reals.
There is no concept of under- or over-flow. There is just one zero,
not -0 and +0. Infinity is an exact value.
- An interval is a mathematical interval, that is, a closed connected
subset of the reals. There is no concept of an interval "being" an
under- or over-flow range, nor of its endpoints "being" such a thing.
Thus for instance Lee's {+ovr +ovr] (BTW what's the curly bracket on the left, Lee?) simply doesn't exist in the P1788 system.
Yes, this model has its defects, of which many of us are aware. But that's what we voted for, and we know it is consistent, if ordinary mathematics is so. Several attempts to bring in an overflow concept, including an earlier one by Siegfried, brought inconsistencies in with them.
Regards
John Pryce