Re: Motion P1788/M0017.02:IO
(Thanks, George C., for setting me straight on version numbers.)
I agree that replacing the text of M0017.01 (JDP_IO_ProposalV2.pdf)
during the voting period with JDP_IO_ProposalV3.pdf is not a good
idea; after all, discussion of that text had been confined to John
and myself!
Procedural question: will a revised M0017.02 be allowed if M0017.01
actually passes? I assume so, because otherwise what would be the
point of encouraging NO voters to propose fixes, if those can be dealt
with only if the motion fails. But then I'm not a parlamentarian...
On John's specific question:
> Michel, please check. In particular note "binary" on the first
> line of 3.4.3. I think you wanted it removed but I remain totally
> sceptical of that.
Well, as originally written 3.4.3 effectively disallowed decimal interval
formats, because it required that a binary ti-format that represents
intervals exactly be provided "for each supported interval format"!
This was fixed in the version John just distributed: it now applies only
to binary interval formats.
However, my point to John had been that, just as binary intervals can be
recovered exactly from decimal text via recovery conversion, it is possible
to recover decimal intervals exactly from hexadecimal text, even though
the actual hexadecimal representation is not exact. (It must of course
have sufficient precision, which means that the current definition of
the C format specifier %a, which implies a fixed precision, is inadequate.
See the P.S. for more on that.)
Given the (new) requirement for recovery conversion (3.4.2), the need for
exact hexadecimal conversion of 3.4.3 actually goes away. It can still be
useful, especially for binary formats, but should it be required?
On nice thing about P1788 compared to 754 is that radix is much less of
an issue, because of containment rules, and even more so because of the
possibility of recovery conversion. That's why I would prefer to leave
out things addressed to a specific radix.
There is one caveat however: One has to know which format to recover.
Recovery conversion works if the recovered ormat is the same one as
the one originally converted to text -- in both radix and precision.
This suggests that there ougth to be a way to tag the ti-format in
some way to record the original format -- but that adds a whole new
concept to the story.
Michel.
P.S. Hexadecimal recovery conversion for decimal formats.
This function might be subsumed by regular convertToTextInterval()
in languages/environments that support a "recoverableHex" conversion
specifier. The C %a format does not permit a precision specifier, so
it must always pick the appropriate one, namely %.13a for binary64
and %.28a for binary128. C does not have a definition for %a when
appplied to DFP input, as it is defined strictly from the binary
representation (it must start with '0x1.' for normal and '0x0.' for
subnormal numbers). It could however be applied to DFP input, in
which case the recovery constraint requires 55 bits for Decimal64
and 114 bits for Decimal128. That could be arranged by keeping the
same implied formats of %.13a and %.28a (if those were legal) but
allowing the first hexit (before the radix point) to be other than
0 or 1, as 14 resp 29 hex digits correspond to 56 resp. 116 bits.
This use of %a for representing DFP is not completely silly. It would
permit interfacing DFP with MPFI for example, where precisions of 55
or 114 bits make sense, and could be used efficiently to record DFP
values recoverably, where regular binary64 and binary128 could not.
---Sent: 2010-06-27 20:32:37 UTC