[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: [Stds-754] motion for Aug: Change "It Shall Be Possible" to "Shall"
Item 26. - Dan
Subject: [Stds-754] motion for Aug: Change "It Shall Be Possible" to "Shall"
From: Ronald Smith <rmsmith1@xxxxxxxxxx>
Date: Thu, 3 Aug 2006 22:22:49 -0400
Dan, I'd like to make the following motion at the August meeting.
Regards, Ron Smith
(The page numbers and text used in this motion are from
DRAFT Standard for Floating-Point Arithmetic P754 Draft 1.1.2,
dated July 28, 2006)
--------------------------------------------------
Motion: Change "It Shall Be Possible" to "Shall"
Page 36, section 7.9,
"Details of conversions from floating-point to integer formats"
Current text:
It shall be possible to convert from all supported non-storage
floating-point formats to all supported signed and unsigned integer
formats.
Change to:
Implementations shall provide conversion operations from all supported
non-storage floating-point formats to all supported signed and unsigned
integer formats.
Rationale.
As discussed below, the phrase "it shall be possible" is, at best,
misleading and should be corrected for this particular operation.
The phrase "it shall be possible" appears in the current draft three
times (in each instance, it is the first sentence):
1. Page 30: "formatOf-convert(int)"
2. Page 36, section 7.9, "Details of conversions from floating-point to
integer formats"
3. Page 38, section 7.12, "Details of comparison predicates"
In Std 754-1985 and Std 854-1987 this phrase appears four times:
5.3 Floating-Point Format Conversions
5.4 Conversion Between Floating-Point and Integer Formats
5.5 Round Floating-Point Number to Integer Value
5.7 Comparison
Our interpretation of the phrase "it shall be possible" is that it is
acceptable to require the user to perform more than one operation to
obtain the result. This is perhaps the correct interpretation for
comparison, for example, as it is not unreasonable to require the user
to convert one format to a wider format and then perform the comparison
on operands of the same format. For other cases, it is not so simple.
For example, to obtain conversion of an 8-bit unsigned integer to
binary32, the user might have to take two steps:
Step 1. Convert the 8-bit unsigned integer to a 32-bit signed integer.
Step 2. Convert the 32-bit signed integer to binary32.
While this case does not make much difference, this is not true in the
other direction. Consider conversion from binary32 to an 8-bit unsigned
integer as two steps:
Step 1. Convert the binary32 to a 32-bit signed integer.
Step 2. Convert the 32-bit signed integer to an 8-bit unsigned integer.
Note, for example, when performed as a single step, small negative
values would be expected to report invalid operation; but when performed
as two steps this will not be the case.
Many implementations pretend to implement this as if it were one step
but actually perform two steps in-line and produce the two-step
semantics. That is, invalid operation is not signaled as mentioned in
the example above. Even if the in-line code is modified to set invalid
operation, unless even more code is added, it is quite possible that
both invalid operation and inexact are set. For this reason, we are
proposing to limit the number of integer formats that must conform and
we are also proposing to relax the definition to permit other exceptions
to be indicated with invalid operation.