Re: Motion P1788.1/M004.01
On 2016-05-14 13:19:06 -0400, Lee Winter wrote:
> On Sat, May 14, 2016 at 12:25 PM, Michel Hack <mhack@xxxxxxx> wrote:
> > On Sat, 14 May 2016 12:18:20 -0400, Lee Winter wrote, replying to John Pryce:
> >> > The 1788 standard *is* based on the mathematical real numbers, ...
> >>
> >> That will always be a point of ongoing debate. For example, can you
> >> present a finite sequence of numerical operations that produces a true
> >> mathematical infinity?
> >
> > Obviously not, since there are no infinite Real numbers. What's the point?
>
> The point is to refute the claim the '1788 represents unbounded sets.
No, in 1788, intervals do not represent real numbers only. They can
also represent ranges in order to do range computations. And even if
the inputs are bounded sets, the output can be truly unbounded, e.g.
1 / (0,1] gives [1,+inf). So, [1,+inf) necessarily represents an
unbounded interval, not just some unknown bounded interval whose
upper bound is unknown. And in any case, the best way to represent
an unknown bounded interval whose upper bound is unknown is to use
an unbounded interval. Doing otherwise would be unnecessary complex.
> So with '754 calling overflow infinity does not create a value that
> represents a mathematical infinity.
With a usual computation on real numbers, I agree. However, the
infinity as a member of the floating-point format can also be re-used
as a bound like in inf-sup. I would prefer to distinguish both, but
that's not possible in IEEE 754 (anyway this may not be very useful
as truly exact infinities cannot be produced in a correct math
expression on real numbers).
> > Unfortunately 754 has no easy way to track the distinction
>
> So, in reality: '754 only has values that follow certain propagation
> rules. Those rules perfectly model underflow and overflow. They do
> not model exact zeros and infinities of any kind.
If I write "x = 0", this 0 is assumed to be an exact zero.
When writing "1 / x", if x is 0, the 0 could have been either produced
by an underflow or a true mathematical zero. Unfortunately, it is not
possible to know in general. So, a divideByZero exception is generated
so that the user can decide what to do.
> See also the "three zeros" proposal (positive, unsigned [mathematical
> zero], and negative), which was rejected by the '754 committee (a
> horrible mistake IMHO).
It should have been 4 zeros: mathematical zero and 3 potentially
"inexact" zeros: >= 0, <= 0, and with unknown sign. The system would
also be more complex.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)