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

Re: text2interval again, was Another thought Re:..

I am curious about your note because I agree with your final paragraph, but
dosagree with much of the earlier material!


On 3/6/2013 10:16 AM, Michel Hack wrote:

Richard Fateman wrote:

If you can serialize numbers, you can serialize intervals.
(arguably therefore you don't need text2interval)

On the contrary -- it means that you don't need nums2interval()!

Hardly the case, since nums2interval() would be need whenever the endpoints
are computed  as scalars rather than read in as literal constants.



The serialized format of numbers and intervals is a text string,
and this is addressed by the notion of interchange formats.

Remember that deserialization must be capable of restoring a
semantically-equivalent copy of the original datum.  In the
context of the literal "0.1" going through a binary format,
the rounding that was applied to derive the binary value must
be recorded with the object (exact, rounded up, or rounded down),
otherwise the representation would not be semantically equivalent.

Instead of "0.1" consider the two strings "0.099999999999999998"
and "0.099999999999999999" (which round to different BFP64 values).
I don't know why any of these forms should be used by a serialization protocol. 
There are many ways of encoding binary numbers as characters such that there
is no ambiguity whatsoever as to the internal form being encoded.

It  seems to me to be quite
irrelevant how that internal form was created in the first place, and whether it 
was the result of rounding up or down.

 The value I expect for 0.1 is  in hex, 3DCCCCCD for 32 bits
and in 64 bits,
3FB999999999999A
for 0.09...9 it is also
 3FB999999999999A

for 0.09...8 it is
  3FB9999999999999

For exchange between different computer implementations of  IEEE754, or
transmission one byte at a time, there may be a need to reverse byte order.
The 'endian' consideration is not solely a floating-point issue.
If we tweeze apart the sign, exponent, and fraction part of the first 64-bit number 
above, we get (in decimal equivalent for the binary fraction):

 1.60000000000000008881784197001....  which we can multiply
by the 2^(-4), which is the exponent there, and we get a decimal number which 
is of course pretty close to  0.1d0, but is in fact slightly larger.

The other number ending in 9998  is like
1.59999999999999964472863211... times 2^(-4) and so is slightly smaller than 1/10. 

To play with such things, visit http://babbage.cs.qc.cuny.edu/IEEE-754/






To stay with simple numbers, somehow one needs to record the fact that the
binary representation of 0.1 was rounded up, but the binary representation
of 0.3 was rounded down (whereas that of 0.5 would be exact).
I don't see why, at all. The binary representation of 0.1 is entirely determined by the decimal-to-binary conversion routine which is obligated to find the closest representable 
number....
3FB999999999999A  in 64-bit float.
  If you somehow choose to round it down to
3FB9999999999999 I suppose you can do that, too. but please stop referring to it, 
in either case as "0.1".
If you mean by "simple numbers" some set of "short numbers" than are easy-to-look-at for humans, then one can always do a crude job of rounding, and as is traditional, 
advise people of the dangers of simplification.


  Each of those character strings 0.1 or 0.3  represents exactly the same
binary float each time it is read in, assuming the decimal-to-binary algorithm is 
deterministic.

   By the
time the binary value is used we don't know whether it was derived from
0.29999999999999997 (rounded up) or 0.30000000000000001 (rounded down).

It doesn't matter.  0.3d0 is 3FD3333333333333




As mentioned many times already, interval bounds have to be derived
using appropriate rounding directions, so when a literal is used to
derive an interval endpoint, the literal has to be interpreted in
the appropriate context.

OK, I think this is where I disagree.  The result of OPERATIONS like + and *
require attention to rounding directions. When a literal is used to initialize 
a value, and that value is used as an endpoint, why not use that value?

The context I have in mind is this:  the programming language is perfectly
well able to produce any finite floating point number. It could be the largest 
number less than or equal to 1/10 in double-float.
 Or the smallest number greater than or equal to 1/10
in double float.

Then we can use those as input to nums2int.  Perhaps we can name these
functions  double_maxfloor()  and double_minceil().  Now there is an issue
here because I have used a higher precision (here, exact) number, and asked
for a double-float. It doesn't make sense to call double_maxfloor on a double-float number x, because it could always just return x, since x<=x and is a double float. 

Another set of programs which I call bumpUp and bumpDown take an already
valid (say, double float), and find the next larger and smaller numbers. This will 
produce a wider interval  than floor and ceil.
For languages that allow exact rationals, nums2int(1/10,1/10) is, it seems to me, not suitable for widening. What infinitesimal could you add or subtract from 1/10 
that would be "tight"?



  This context is lost if the literal is
first converted to a number, and then used later to construct an
interval.

The context for the literal is "This number has previousl been computed or
 read in by the normal input routine
for the programming language". It ceases to have meaning as 0.1 or 0.3 and now 
only has meaning  3FB999999999999A  or 3FD3333333333333 and is devoid of
history or rounding mode.
And 0.5 is exactly 0.5. If it was your intention to represent something slightly different and enclose it, you have the option of bumping 0.5 up and down (assuming the computed 
0.5 was not quite correct but was within 1/2 ULP.)
Or of using maxfloor etc but then you must have a higher precision number in mind. 
Or using some computation, e.g.  see below..
If it was your intention to take a certain hex number and bump it up or down, it is easy 
to do so.


If you decide to resolve this by always widening the interval at each
endpoint (which would preserve enclosure), then any round-trip conversion
from interval to endpoints and back would widen the interval even more.
No, because in my view the nums2int() program does no widening. There is no need to expand the interval because the assumption is that the endpoints are valid floor and ceiling, 
as given.

the endpoints are converted once by double_maxfloor().  nums2int does
not call double_maxfloor.
There is a question then as to how to produce the tightest double-float interval around 1/10. (or 0.5)
Here's one way: create exactly the interval [1,1] by nums2int(1.0d0,1.0d0) {no widening!!!} and divide it by 10.0d0. you would be obligated to divide 1 by 10 rounding down, and divide 1 by 10 rounding up. There are obviously lots of equivalent arithmetic developments, if you start with intervals 
delimited by exactly the numbers given to nums2int().

Ouch.  That's why the interchange format needs to use exact representations
(decimal or hex, as appropriate),
unless the floating-point arithmetic being supported is decimal, it seems to me it does not make sense 
for the interchange format to be decimal.

  or define a recovery conversion (which
is different from plain text2interval()) that uses inward rounding in one
direction and outward rounding in the other.

I see no reason to round hexadecimal numbers on input or output.

  We discussed such a recovery
format in the past (it needs to be bound to a particular number format),
but decided that it was perhaps too controversial, and IEEE 754-2008 at
least provides the hexadecimal alternative.
So the hexadecimal alternative should simply be specified as a preferred exact 
interchange.  Why round?

RJF




Michel.
---Sent: 2013-03-06 18:55:05 UTC