[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: missing tabled motions
OK, I have taken what was motion 49a & b for June & made it into
motion #20 for July. Also, what was motion #50 for June is now
motion #21 for July. David tells me that I have already changed
former motion 51 into new motion #16. I must confess that I am
unsure of exactly what was intended here so, Roger, if I have
misinterpreted your intention please let me know & I will fix it. - Dan
Subject: missing tabled motions
<a name=T49>
<hr>
<b>Agenda item #T49?</b>
Motion: clarify conversion to unsigned integer format - plan A - After
rounding
Rationale: On June 21 we discussed various approaches to this problem.
The one certain thing is that the draft is unclear.
This motion removes one aspect of that uncertainty.
The text parallels that of case 8.
Text:
In section 7.1, add an item to the list of invalid operations:
11. Conversion of an internal floating-point number, which would
convert to a negative signed integer under the prevailing
rounding mode,
to an unsigned integer format and this cannot otherwise be indicated.
Commentary:
An alternative formulation
11. Conversion of an internal floating-point number, strictly less than
zero, to an unsigned integer format and this cannot otherwise be
indicated.
is based on the proposition that you shouldn't be converting a negative
number to an unsigned format.
However this is unlike the case of conversion to a signed integer, which
is invariably treated as "after rounding."
An even more alternative formulation, when going to twos complement unsigned,
is to have no exceptions for finite arguments, and deliver (at potentially
extravagant cost) the correct result, modulo 2^n.
<a name=T50>
<hr>
<b>Agenda item #T50?</b>
Date: Wed, 21 Jun 2006 22:25:01 -0700
From: "Golliver, Roger A" <roger.a.golliver@xxxxxxxxx>
Subject: [Stds-754] motion: clarify conversion to signed or unsigned integer
format
Motion: clarify conversion to signed or unsigned integer format
Rationale: On June 21 we discussed various approaches to this problem.
The one certain thing is that the draft is unclear.
I believe that Case 8 in 7.1 already captures the raising of invalid and
no change is needed in that section. I believe that the ambiguity is in
the specification of the conversion operation. The intent of the
following text change is to make it clear that the conversion
operation's rounding is to an infinitely precise integral floating point
value, and it is that integral floating point value that converted to an
integer representation, if it will fit. This will take -0.25 to 0 in
round to nearest mode for both signed and unsigned integer formats.
Converting -0.75 to unsigned integer format in round to nearest mode
will be invalid.
Text:
In section 5.4.2:
Change:
When a conversion operation's result differs from its non-integral
operand value, yet is representable in the destination format, the
inexact exception might be signaled in certain circumstanced. Inexact
... mixed types.
In contrast, invalid exceptions due to overflow of the destination
format are always signaled.
To:
When the rounded to integral floating point value of the conversion
operation's operand is not representable in the destination format
because of overflow, the invalid exception shall be signaled.
When the rounded to integral floating point value of the conversion
operation's operand differs from its operand value, yet is representable
in the destination format, the inexact exception might be signaled in
certain circumstanced. Inexact ... mixed types.