Fw: Overflow and Inf
I also have the problem of having other things to do besides 1788, so I sympathize. I expect all of us are busy. I will reply to some other emails containing misinformation soon. In the meantime:
As I wrote in a recent email, the IEEE 754 format of Infinity for binary floating point has no room for decorations. It also has no room for flags saying that it's an alternate variant, Directed or otherwise. What it has is:
- a one bit sign
The sign distinguishes -Infinity from +Infinity.
- an exponent, with the size depending on which format (binary64, etc)
The exponent that indicates Infinity is shared with the one that indicates NaN (both Quiet NaN and Signaling NaN).
- a fraction, with the size depending on which format
The fraction must be ALL ZEROS. Any other value makes it a NaN, and the value of the fraction distinguishes Quiet from Signaling NaNs.
When you have time you can verify this. Others like Michel who also works with floating point can confirm it.
It means that you cannot have a value representing Directed Infinity which is just a variation on Infinity.
That doesn't mean you can't have a Directed Infinity.
- One way would be to have different hardware instructions that treat all Infinities as Directed Infinities.
There are of course significant costs to that.
- A second way would be to have a hardware mode that told all floating point instructions that all Infinities should be treated as Directed Infinities.
The costs are lower, but since switching modes tends to be slow the performance of programs that use or might use both non-interval floating point and intervals would be affected at least a little.
- A third way is to do that using software, checking every operation's inputs or outputs for Directed Infinities.
Obviously that's multiples slower. Not all operations need checking though.
- A fourth way is to implement Directed Infinities as a special form of NaNs. That arguably violates 754, so you'd likely need a mode flag,
but it would likely be acceptable to most interval arithmetic users to run both interval operations and non-interval floating point in that mode, and if so the performance cost would be limited to setting the mode at startup.
There are two approaches to that:
- You could use hardware to do it.
There are costs to that.
- You could use software, either prechecking every value before every operation or detecting and handling exceptions after operations involving Directed Infinity.
You can do that post-operation checking by comparing values, or by comparing exception status flags, or by letting the hardware and operating system call a trap handler. Each has different costs, and the key question is whether you expect operations on Directed Infinities to be rare or common.
Adding Directed Infinity to 754 involves all the same considerations as adding Overflow, and in fact they are closely related. In each, you create a new bit pattern representing "almost infinity". An overflowing operation would produce it, and in most situations it would be treated the same as infinity, but in some situations it would act differently (the most obvious being that when multiplied by zero it gives zero not NaN). The semantics are different (each with some advantages over the other), but they are similar, including that they are both new variants of 754. Each would need new hardware developed to give top performance.
With 754 Decimal Floating Point, the details are different but most of the same issues apply.
- Ian McIntosh IBM Canada Lab Compiler Back End Support and Development
----- Forwarded by Ian McIntosh/Toronto/IBM on 09/29/2010 12:23 PM -----
From: |
Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx> |
To: |
Ian McIntosh/Toronto/IBM@IBMCA |
Date: |
09/29/2010 12:15 PM |
Subject: |
Re: Overflow and Inf |
Nate Hayes wrote:
>
> Please note in your message below: "apparently", "I haven't yet had the
> time to read through the 754 documentation...", "if it is...", "if it is
> not..." etc. There is NOTHING that sounds certain about any of that.
This is only because I rely on information that Ian McIntosh and you
regard as certain, but that I haven't checked yet. I have many other
things to do besides carrying on these time-consuming 1788 discussions.
But I wouldn't recommend putting any of this into the standard
(or help presenting a motion on it) unless all these doubts are
completely eliminated.
Arnold Neumaier
In reply to
P1788, Arnold,
Please note in your message below: "apparently", "I haven't yet had the time
to read through the 754 documentation...", "if it is...", "if it is not..."
etc. There is NOTHING that sounds certain about any of that.
It also doesn't inspire confidence in me that you have studied how such
changes would impact the design of existing and/or future hardware circuits
and semiconductors. Where is your detailed anaylsys of that? I also have
much skepticism DirectedInf will work when it comes to interval comparisons,
since it appears the comparisons will require some decoration, anyways, in
order that they should give the correct results. So there is much uknown,
and even plenty to doubt. Therefore it is a research project as well.
Stepping back to take a broader view of things, I'd point out that as it
pertains to P1788 I don't agree with Arnolds recent comments. For example,
by the standards of:
>>>> And it is unwise to account for things that still need research
>>>> to find out how to do it well. The right placce to consider these is
>>>> when a standard is upgraded and the relevant information is then
>>>> available.
many of the P1788 motions which have already been investigated and accepted
should never have even been put forth on the table or considered. This is
particularly true (and continues to be so) about all motions regarding
decorations, and arguably even Motion 5, which requires a controversial
hardware operation Infinity*0=0 which currently has no precedent in the
world of floating-point semiconductor design.
I believe that the scientific process is to study all the variables relevant
to the question at hand, so that conclusive and informed decisions can be
made about what is the best solution or decision to make going forward. For
P1788, this means taking time to consider the impact of including Overflow
in the standard.
I wouldn't object to looking at DirectedInf, either, so long as it is also
decided to study Overflow such that a comparision between the two can be
made.
To not do so, in my view, would be ad-hoc and subjective at best, if not
simply a totally hasty rush to an uninformed judgement. I don't see that
would be a very scientific way to build a standard, nor that it would be
beneficial to P1788.
Nate
----- Original Message -----
From: "Arnold Neumaier" <Arnold.Neumaier@xxxxxxxxxxxx>
To: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
Cc: <rbk@xxxxxxxxxxxxx>; "1788" <stds-1788@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, September 29, 2010 10:02 AM
Subject: Re: Overflow and Inf
> Nate Hayes wrote:
>> I suppose that also eliminates any consideration that P1788 should
>> include or investigate further the "DirectedInf" mechanism in the Vienna
>> Proposal.
>
> I don't understand. DirectedInf is simply the inf with the interpretation
> as in the last section of the Vienna proposal,
> fully settled there.
> The only new thing emanating from the recent discussion is
> that it apparently can be implemented as a nonstandard Inf
> without violating 754 rules.
>
> I haven't yet had the time to read through the 754 documentation
> to find out whether this is indeed so.
>
> If it is, nothing else needs to be researched about it.
> If it is not, then we cannot make use of DirectedInf in a 754 context.
> (Neither can one use Overflow, which propagates the same way as
> DirectedInfbut has a more complex semantics that conflicts with
> Motion 3.)
>
>
>>> On 9/29/2010 08:56, Arnold Neumaier wrote:
>>>> Ralph Baker Kearfott wrote:
>>>>> On 9/26/2010 12:25, Arnold Neumaier wrote:
>>>>>> A standard should be as restrictive as possible, given the constraint
>>>>>> that it does not exclude something that has been useful in the past.
>>>>>>
>>>>>
>>>>> Again, are we taking care not to stifle innovation? What about things
>>>>> that will be useful but we haven't discovered yet? In any case, is the
>>>>> above statement standing on its own relevant to us?
>>>>
>>>> It is impossible to account for things not ywet discovered.
>>>>
>>>> And it is unwise to account for things that still need research
>>>> to find out how to do it well. The right placce to consider these is
>>>> when a standard is upgraded and the relevant information is then
>>>> available.
>