Re: "Built upon 754"
On Tue, 2 Feb 2016 16:43:23 -0500, Ian McIntosh wrote:
> I was the one who suggested several years ago that not just 1788 but
> also 754 needs two "values" +Overflow and -Overflow, with the property
> that multiplying either by zero gives zero. The bit patterns I would
> use would be those of the current maximum finite values.
We had a discussion of these issues in January 2012, when I submitted
my IFP MEMO (ifp.pdf is, I think, on the 1788 Website):
| Date: Thu, 22 Mar 2012 14:52:02 -0400
| To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
| From: Michel Hack <mhack@xxxxxxx>
| Subject: An exploration of Inexact FP Arithmetic
This was in fact in response to a post by Lee Winter (no surprise).
> I would leave two representations of zero defined to be
> semantically equivalent, ...
Watch out! You left the two "true" infinities, so you need to define
their reciprocals! Of course, you could go all the way back to 1984
and define an unsigned projective Infinity instead.
> While I was at it, I would define NaNs to use the uppermost non-hidden
> significand bit to distinguish Signaling from Quiet NaNs (I think all
> existing implementations do that) but the opposite of most - a 1 would
> mean Signaling and a 0 would mean Quiet.
Well, that's what HP-RISC did if I remember correctly -- and it complicates
the "NaN Quieting" -- you now need two bits to encode the two flavours of
NaN. Besides, NaNs are heavily overloaded too, so spend a bit more time
on this and propose a useful standard categorization of NaNs. While you're
at it, redefine the NaN payload to be a RIGHT-aligned integer, and redefine
NaN propagation so this integer survives narrowing (if it's not too big)
and widening, as well as radix conversions. Then we wouldn't have to play
the bit-reversal game that IBM uses with BFP to preserve NaN payloads across
such conversions.
> I am still waiting patiently for the time machine I ordered years ago
> to be delivered!
Oh but it WAS delivered! You just need a time machine to retrieve it.
Michel.
---Sent: 2016-02-02 22:09:11 UTC