Level 2 query, number 2
> 1. Every (bare) interval type T must have a loss-free way to write
> any datum (i.e. interval) in T as text, and to read that text
> back to recover the original datum exactly.
Assuming we're going back to the same representation (e.g. on the same
platform). Even then it needs the concept of recovery conversion, unless
the text representation was exact (e.g. %a hex representation of BFP, or
decimal representation of DFP). Otherwise you could get two successive
outward roundings.
I seem to recall that this was discussed previously. If the text is not
exact, conversion to text could be outward-rounding, and recovery conversion
would then be inward rounding. Alternatively, both could use to-nearest,
but then the text would have to be flagged as being a representation of an
internal interval type. In either case we need to distinguish between
import/export conversion and conversion of one interval type (internal) to
another (text, possibly external). The advantage of the notion of recovery
conversion is that only one internal-to-text method is needed, though we
still need two text-to-internal methods.
Michel.
---Sent: 2011-09-04 22:53:47 UTC