Re: More on trits & tetrits... (long)
It seems the distinguishing implication for IEEE 1788 would be:
-- Level 1 intervals are elements of IR, or empty
-- Level 2 intervals are elements of IF#, or empty
where F# := F \union {-overflow,+overflow} and IF# is the subset of IR with
bounds of F#.
Nate
BTW, I just noticed that Motion 13 says:
"the subset of all bounded or unbounded intervals of overline-IR with
bounds of F is denoted by overline-IF"
I think maybe it meant to say "with bounds of F*".
----- Original Message -----
From: "Ian McIntosh" <ianm@xxxxxxxxxx>
To: <stds-1788@xxxxxxxxxxxxxxxxx>
Sent: Thursday, April 22, 2010 3:14 PM
Subject: Re: More on trits & tetrits... (long)
It should be possible to always compute correct results without using
decorations. This situation is the sort of issue that led me to conclude
that 754 should have distinguished, and ideally 1788 should distinguish,
between Infinity versus Overflow. Overflow would mean that the result was
finite but too large to represent more exactly with the existing precision
- what you called Inf-as-Overflow. Infinity would mean a real infinity,
what you called Inf-as-Pole. The arithmetic rules should be different:
Infinity - Overflow = Infinity Infinity - Infinity = NaN
(Unknown) Overflow - Overflow = NaN (Unknown)
Infinity / Overflow = Infinity Infinity / Infinity = NaN
(Unknown) Overflow / Overflow = NaN (Unknown) Overflow /
Infinity = infinitesimally larger or smaller than 0
Infinity * Overflow = Infinity Infinity * infinity =
Infinity Overflow * Overflow = Overflow
0 * Infinity = NaN (Unknown) 0 *
Overflow = 0
Infinity, Overflow and NaN are "floating point values" each representing
infinite sets of Real* values. In these examples I mostly ignore signs.
From a representation point of view, IEE 754 binary Infinity, Quiet NaN and
Signaling NaN all share the same exponent and are distinguished by the
fraction bits. Overflow could too.
- Ian McIntosh IBM Canada Lab Compiler Back End Support
and Development
|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Michel Hack <hack@xxxxxxxxxxxxxx>
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Ian McIntosh/Toronto/IBM@IBMCA
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|04/22/2010 11:23 AM
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Re: More on trits & tetrits... (long)
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Dan Zuras, Vincent Lefèvre, Dan Zuras:
> > We do not know whether or not an actual pole was encountered.
> That's the problem.
In essence, your definition is adding one bit to the range
just as decorating this problem with 'exact' or 'inexact'
would add one bit to the precision.
Actually, "Exact" adds infinitely many bits of precision. The
Exact vs Inexact distinction also applies to Inf-as-Pole (Exact)
and Inf-as-Overflow (Inexact).
The question then becomes whether this distinction can be carried
over from 754 to 1788 by means of decorations. This is a tall order,
because even in 754 the distinction is not carried forward by the
normal rules of arithmetic. For example, Inf(exact) - Inf(overflow)
or Inf(exact)/Inf(overflow) should be Inf(exact) and not NaN -- but
the only way to do that is to attach the Inexact flag to the datum,
i.e. to use decorated floats -- a topic that was never addressed.
The float result of an operation would however depend on both the
input floats and the input decorations.
So the question becomes whether the deliberate separation of
bare interval results and decorations is good or bad.
Michel.
---Sent: 2010-04-22 15:19:30 UTC