[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: P754 Ballot Response message from valid local sender)
Michel,
I removed "widely" from the submitted comment.
The main reason previously offered for keeping the storage class was to
prevent the unskilled user from getting into trouble with overflow, etc,
that can and probably will occur. This also happens in every format
proposed as interchange, or non-interchange, in this draft as you get to
the end of the ranges. The requirement to do the math correctly and
return the correct answer remains. How that correctness is accomplished
is not the province of this draft, although suggestions are made with
the widento modes.
The changes are mostly limited to Clause 3 and a few definitions as a
text search will show. The requirements to do math in the interchange
formats are already present and just made explicit. Every interchange
format from 16 up is already covered in 3.4 and 3.7 along with decimal
in 3.5 and 3.7. Any possible in-between is covered in 3.6.
The non-interchange formats, described in Clause 3.6 describe the
interchange formats at specific dimentions except for binary16 and
decimal32, and basically cover anything in between that any implementer
might conceive as useful. Note that binary32 can be expanded to
binary3249538293 if you wish and be considered part of the standard as
long as p digits is greater than 32 and emax is greater than 1023. The
same generalization is true for the decimal family. They is effectively
no constraints in this section other than you can not name it decimal128
if it has less than 43 p digits. As far as I can detect, clause 3.6
basically say you can do the math in the form most convenient to the
hardware or software and you can do it differently each time. The only
constraint is bringing it back to the interchange format correctly
rounded and flagged.
I also just realized that the emin row should be deleted from Table 7 as
it is not needed per line 18 above it.
Respectfully,
Bob.
Michel Hack (1-914-784-7648) wrote:
I really hope we can close this one out -- and I hope that the low
completion rate is simply because the remaining ballot members are
carefully working out their responses to be submitted near the end
of the balloting period.
What I avoided this time was suggestions that would force a rewrite
of large sections of the document, because the document really is in
pretty good shape. In that light, my main objection to a rewrite of
chapter 3, and sorting out the consequences throughout the document,
is precisely that. It took a lot of work to get it into shape, and
now is not the time to tinker with it. For example, I was tempted to
object to the inclusion of "extendable" formats, and more specifically
to the lack of clarity in the distinction between "extended" and
"extendable" formats, but I let it go as the section was reasonably
well written, and I did not want to mess with it.
Upon rereading Bob Davis' suggested replacement for clause 3.1 I see
that one reading of it suggests requiring the interface formats
mentioned in 3.4 and 3.5 support arithmetic (if supported at all),
which really makes me wonder what was meant by "widely available".
The justification for this is rather weak however, as Bob also thinks
that arithmetic should be carried out in wider formats anyway (but
presumably explicitly, by casting operands to wider formats, or by
relying on a language's widenTo rules.) Given this, I think we should
leave the section alone.
Michel.
Sent: 2007-11-08 13:43:59 UTC