Re: Motion P1788/M0013.04 - Comparisons - Overflow / Infinity
Ian, P1788
On 22 Sep 2010, at 01:03, Ian McIntosh wrote:
> IM>> If Interval Arithmetic was based on IEEE 754 with Overflow added, some of the operations would be simplified because they would not have to handle special cases.
>
> RBK> As it stands now, we wouldn't base things STRICTLY on 754, since motion 3 passed, and since 754 treats
> RBK> Infinity as a number. Since motion 3 states that we are only dealing with reals, we would be interpreting
> RBK> the symbol Infinity the same as overflow, n'est pas?
>
> Of course you're right about the standard and the decisions that have been made.
>
>
> I look at things like this from the implementer's point of view,
...
> If you've either read this far or skipped to the end, please remember that I'm not pushing 1788 to adopt Overflow, or saying that it doesn't introduce new issues, just saying that hypothetically in my dream universe if 754 already had it then some things would have been simpler to implement and would have run much faster without new hardware. Other projects have shown that neither simplicity nor speed is essential to a standard.
Now you put it like that... I've read through and I think I agree with every word you say. Well, there's parts of which I'm not competent to judge, and I'll show my ignorance by asking:
In your "Or you can use software...", do today's branch prediction features not help on scalar code? And, for long vectors, if you are doing an elementwise multiply w = u .* v (Matlab notation), can you not amortise the overhead by doing a straight 754 multiply first, and a second pass through w to fix the NaNs?
John
P.S. BTW I find it interesting that in Lebesgue integration theory one makes the convention 0 * oo = 0, just because it simplifies the statement of many facts involving "almost everywhere".