Re: Motion P1788/M0017.02:IO
Michel and all,
On Jun 27, 2010, at 2:43 PM, Michel Hack wrote:
> 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...
I'm not either, but I play the role of one in this forum.
Yes, IMO (rarely H). Parliamentary bodies often vote to reverse themselves or to reconsider variants of decisions made previously. In general, (almost) any (civil, within scope) motion should be accepted for discussion and voting. If someone attempts essentially Denial of Service be repeated submission of essentially the same motion, the Chair can rule it as out of order. No big deal.
George
>
> 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
Dr. George F. Corliss
Electrical and Computer Engineering
Marquette University
P.O. Box 1881
1515 W. Wisconsin Ave
Milwaukee WI 53201-1881 USA
414-288-6599; GasDay: 288-4400; Fax 288-5579
George.Corliss@xxxxxxxxxxxxx
www.eng.mu.edu/corlissg