text2interval again, was Another thought Re:..

[Michel Hack <mhack@xxxxxxx>]

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()!

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).

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).  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).

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.  This context is lost if the literal is
first converted to a number, and then used later to construct an
interval.

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.
Ouch.  That's why the interchange format needs to use exact representations
(decimal or hex, as appropriate), or define a recovery conversion (which
is different from plain text2interval()) that uses inward rounding in one
direction and outward rounding in the other.  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.

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