Re: dependent and independent intervals, proposal to toss out
Richard Fateman wrote:
> Your explanation then says that a string s, say s = "0.1" which is
> acceptable as input to the IEEE754 string-to-float conversion is also
> acceptable to the text2inteval program. However it seems it does not
> necessarily denote the same numeric value in text2interval as in the
> IEEE754 standard. In text2interval("[0.1 ...]"), the number is 1/10.
The IEEE754 standard defines TWO possible results for "0.1", depending
on the current rounding direction.
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. For a mid-rad type the appropriate roundings
would again be chosen to satisfy containment.
If you convert the different parts of the string to floats separately,
using default rounding mode to nearest for both, and THEN package them
as an interval, you have lost the proper rounding context, and you
will not be able to guarantee both containment and tightness (you could
get one at the expense of the other).
> So perhaps the sentence "Its value is the exact real number it represents."
> would be clearer if it said something more like this..
In a private discussion I had suggested that "it represents" could be made
unambiguous by saying "the text string represents", and John accepted it,
even though he thought there was no ambiguity.
> One could write it then, in pseudo-code as
> text2interval(s):=
> look for [A,B];
> return (nums2int(read_from_string(A), read_from_string(B))
> ...(other forms omitted)
No, it would be:
look for [A,B];
return (nums2int(read_from_string_rounding_down(A),
read_from_string_rounding_up(B))
> I would simply use the equivalent of nums2interval(1/10,1/3).
That's perfectly ok in a system that supports exact rationals.
In general however, nums2interval(x, y) requires the programmer
to be aware of the provenance of the scalars x and y. It is
expected to be used when parts of a computation are carried out
on scalars with explicit directed rounding, as that sometimes
allows tighter enclosures to be returned by competently-written
library routines.
The following is an unrelated question:
> Also I'm not sure how arbitrary precision works into this.
> If you put in too many digits does IEEE754-2008 round?
Of course it rounds, and the rounding is specified rather precisely.
(1) It shall observe the current rounding direction.
(2) When no radix conversion is implied (e.g. decimal->DFP,
or hex->BFP), any given number of input digits shall be
converted with correct rounding.
(3) When converting from decimal to binary, it shall support an
input precision of at least three more decimal digits than
would be needed for a value-restoring round-trip conversion
to the widest supported binary format (and it should support
unbounded input precision).
(4) When converting from decimal to binary with bounded precision,
and more input digits are given, a first correct rounding (in
the current rounding mode) shall be made in decimal to the
stated precision bound, and then this intermediate result shall
be converted as per (3).
Michel.
---Sent: 2013-03-03 19:12:43 UTC