Re: Motion P1788/M0002.01_ProcessStructure YES
On 2009-03-23 23:20:38 -0700, Dan Zuras Intervals wrote:
> > > The only reason the emax >= 1000*p constraint is in there
> >
> > This constraint can be a real problem in practice. For instance,
> > how would you compute sin(2^emax)?
>
> Badly. But then again sin() is not required to conform
> to 754.
You missed the point that if someone wants to implement sin() (on
the whole domain provided by the floating-point system), it will
be quite difficult to achieve on such a system.
> > So, the constraint on emax is used only when the user doesn't specify
> > an emax.
>
> Yep, exactly. If they want to call out p = 10^6 & emax = 4
> we won't stop them. The responsibility is then theirs.
OK, that's fine.
> > Now, I'd say that the main problem is that the format should have a
> > fixed width, and the standard seems to disallow complex structures
> > (for which the concept of width does not make sense).
> This last is true. Prof Kahan insisted on fixed widths
> on the grounds that arrays weren't easily addressed
> without it. Arguments that arrays of pointers were
> easily addressed did not sway him.
All these kinds of things are language specific.
> And with no MPFR people in the room the rest of us didn't
> really form an interest group against it.
In fact, I'm not sure that MPFR does not comply to the fixed-width
requirement, which is a bit theoretical IMHO. Indeed the mapping of
the bits into memory is implementation-defined; and once p and emax
have been fixed, one can say that the bit-string representation has
a fixed width. BTW, even with the standard formats, I suppose that
some implementations may need padding bits (e.g. in C, if CHAR_BIT
is not a power of 2 -- CHAR_BIT = 9 has already been seen, though
I don't know if the implementation has had IEEE 754 support).
Now, MPFR doesn't comply on other things, and I think that if
arbitrary precision were to be standardized, some requirements
should be relaxed, because they may be less important, at least in
high precisions. And I hope that standardized interval arithmetic
will allow less requirement on the underlying arithmetic (BTW, not
necessarily floating point). This includes subnormals support, the
relation between emax and emin, and the signness of zero (and of
the infinity).
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)