Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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


Inactive hide details for Michel Hack ---04/22/2010 11:23:01 AM---Dan Zuras, Vincent LefÞvre, Dan Zuras: > > >  We do not know Michel Hack ---04/22/2010 11:23:01 AM---Dan Zuras, Vincent LefÞvre, Dan Zuras: > > > We do not know whether or not an actual pole was encou


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