Re: dependent and independent intervals, proposal to toss out
Richard Fateman replied to me:
> > The IEEE754 standard defines TWO possible results for "0.1",
> > depending on the current rounding direction.
>
> I am not familiar with the -2008 version, but I expect there
> would be more possible results:
> 1. In decimal radix, 0.1 would be the same value as 1/10
> 2. In binary radix, 0.1 could be rounded in each precision:
> ...
I meant "for any given target format". Also, the two values may
coincide, which will happen when the conversion is exact. (Note
that IEEE 754 also provides an exactness indicator, if the program
clears the Inexact sticky flag before doing the conversion.)
> > In text2interval() the context is known, so (as John Pryce already
> > mentioned in his reply), one part of the string will be converted
> > with round-toward-minus, the other part with round-towards-plus,
> > for an inf-sup type.
>
> Is this really necessary? If I create an exact rational interval
> [1/10,1/3] I do not expect any rounding whatsoever. If I create a
> decimal_text2interval(" [0.1, 0.2]") I do not expect any rounding
> either. Perhaps I am mistaken though?
Perhaps you did not realise that "rounding" does not mean "diddling
with the low-order bits". Rounding (in any direction) never changes
an exact result!
> That is, if someone produces a hexadecimally formatted number and
> reads it in as an endpoint, why should we diddle it up or down?
See above!
> ... There is nothing especially wrong
> with 0.1d0 as a specification for a number, as long as you
> realize it is not 1/10. If someone computes a machine number
> and tells us to use it as an endpoint of an interval via
> nums2interval, we believe it, so far as I can tell.
I don't think anybody will disagree with that. The problem arises
when a careless user does not stop to think what 0.1d0 really means
in the floating-point format being used.
> It is cheap because you can just blast away and _if _you are entitled
> to assume the scalar results for lower and upper bounds are within 1 ULP,
> then bumping them up and down by 1 ULP gives a valid enclosure. It is
> crude because it may widen the interval too much. But you know all this.
Correct. As I said, you can trade tightness for enclosure. In many cases,
especially when input values denote physical measurements, this may be just
fine. But when dealing with mathematical values it would be very annoying
if nums2interval(1.0, 2.0) returned [1-eps,2+eps]. And how would you diddle
an endpoint of zero (which may well come from a non-zero underflow, or worse,
from an incomplete cancellation (possible if the two operands of a difference
have different precisions)?
> have we defined text2interval("[1/10,1/3]")?
Who is "we"? The standard will not require exact rationals, but I see no
reason to forbid it (subject to documented rules for the hull operation
that provide a precision cutoff to make it well-defined). SO if an
implementation supports exact rationals, and has literals for them, then
that's what text2interval() should accept.
There is also the concept of "interchange format" -- to be used when
exchanging information with other environments. This imposes some
global conventions, and the corresponding syntax my be a subset of
what is supported within an implementation. If a case were to be
made to include an interchange format for exact rationals, we would
need a motion to that effect.
> >> If you put in too many digits does IEEE754-2008 round?
> > Of course it rounds, and the rounding is specified rather precisely.
>
> But it ignores the number of digits actually provided in favor of the
> number of digits supported. Mathematica, for example, increases the
> precision for numbers with more digits presented (if there are more
> than about 19.)
IEEE does not allow "ignoring the number of digits actually provided".
At a minimum it requires that all digits be scanned to check whether
they are all zero or not, to derive a "sticky digit" that can be used
to perform correct rounding according to my points (3) and (4). Don't
forget rule (4) which is new in 754-2008. (Also new in 754-2008 is
that correct rounding has to be performed across the entire exponent
range; 754-1985 only required this for middling exponents.)
> So there no limit to the number of digits it will consider? This is
> probably not so hard, since you just need to compute the guard digit,
> and the actual precision is fixed... OK
If this guard digit is what I called a "sticky digit" above, you are right.
But that only applies to the initial (decimal) rounding of rule (4). When
you do the decimal-to-binary conversion with 39 decimal digits (the minimum
if Binary128 is supported; if only 64-bit formats are supported the minimum
would be 20 digits; if 80-bit formats are supported it would be 24 digits)
you have to use sufficient intermediary precision (e.g. up to 256 bits) to
guarantee correct rounding.
Michel.
---Sent: 2013-03-04 00:23:28 UTC