Re: Level 2 query, number 2
On Sep 4, 2011, at 8:10 PM, Ralph Baker Kearfott wrote:
> Michel et al,
>
> Isn't this question the same as decimal-to-binary and
> binary-to-decimal conversion, something that has been well studied?
>
> Michel, your analysis appears to be correct. The question then
> is related to "do we really want an inward rounding in decimal to binary
> conversion (or visa versa)?" To me, that seems a bit dangerous. (I'm guessing
> most of us would want outward, but perhaps tight, rounding in each
> direction, when the operations are considered separately.)
That's what I WOULD have said, until I read Michel's message. If I read it correctly, he encourages us to consider desired effects, not necessarily literally what the text file says. If I read him correctly, he asks for accurate communication, although the communication medium may be flawed. I see an analogy (loose) with secure transmission over an insecure network.
What we WANT is to
have an interval stored in a computer (the source)
transmit that interval via a text file to another computer (the target) supporting the same internal format
reconstruct in the target computer the same interval as we had in the source computer.
What matters is that we are able to reconstruct in the target computer the same interval as we had in the source computer. It does not otherwise matter what the text file says.
Gross over-simplification:
On the source machine, suppose we determine for the interval [a, b] that a and b are adjacent numbers in the supported number screen. Then we choose ANY convenient decimal number x in [a, b], and we write to the text file something equivalent to
"interval("x");
probably with some indicator of the intended supported number screen.
If we interpret that command correctly on a target machine with the same implementation of the supported number screen, we get the same internal interval.
Yes, if we interpret that command in a different implementation, we might get different results. For example, if the source is single and the target is double, we lose containment, but we were careless.
Michel, am I reading you correctly?
Yes, there are dangers, but I REALLY like accurate communication. Otherwise, just telling the story inflates it, rather like stories I tell in my lectures :-)
So it appears that the inward rounding might be done on the SOURCE side, rather than on the TARGET side, as Michel had suggested? Either could work, as long as the standard specifies. I think I could make a case for either.
George
>
> One solution would be, as you say, use of
> octal or hex, leading to two external representations of intervals
> (the comprehensible but lossy decimal representation and the loss-free
> octal or hex representation). However, I am trying to recall or prove that
> there is a mantissa length M in decimal representations that assures that
> every binary number, say, in 754 double, is uniquely represented with
> M digits. If so, then we can use such a decimal representation, although
> we would then need two conversion routines: one with outward rounding
> and one with "lossless" rounding. My own preference would be to stick
> with outward rounding, and use hex representation for lossless conversion;
> it seems simpler to me.
>
> Baker
>
> On 9/4/2011 5:37 PM, Michel Hack wrote:
>>> 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
>>
>
>
> --
>
> ---------------------------------------------------------------
> Ralph Baker Kearfott, rbk@xxxxxxxxxxxxx (337) 482-5346 (fax)
> (337) 482-5270 (work) (337) 993-1827 (home)
> URL: http://interval.louisiana.edu/kearfott.html
> Department of Mathematics, University of Louisiana at Lafayette
> (Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
> Box 4-1010, Lafayette, LA 70504-1010, USA
> ---------------------------------------------------------------
George Corliss
George.Corliss@xxxxxxxxxxxxx