[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: [Stds-754] motion for Aug: Require at Least One Integer Format
This is item 24. - Dan
Subject: [Stds-754] motion for Aug: Require at Least One Integer Format
From: Ronald Smith <rmsmith1@xxxxxxxxxx>
Date: Thu, 3 Aug 2006 22:12:36 -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: Require at Least One Integer Format
Page 26, section 7, "Operations", 7.1, "Overview"
Current text on the top of page 27:
In the operation descriptions that follow, languages define which of
their types correspond to operands and results called int, intFormatOf,
characterSequence, or conversionSpecification. Languages with both
signed and unsigned integer types should support both signed and
unsigned int and intFormatOf operands and results.
Replace the last sentence with the following:
Languages shall support at least one signed integer format and should
support at least one unsigned integer format.
Also, on page 16, section 5,
"Formats", 5.1, "Overview: formats and conformance"
Add the following section:
Integer Formats
An implementation conforming to this standard shall support at least one
signed-integer format and should support at least one unsigned-integer
format.
Rationale
The paragraph in Operations 7.1, "Overview," creates a loophole in the
standard. It uses the word "should" thus permitting an implementation
to conform to the standard by not "supporting" any integer formats.
Our understanding of the original intent of 754 was to provide a limited
set of conversions between binary floating-point values and integers.
We assume the most likely use of the integers would be as index values
to address arrays. We have chosen to require signed integers, rather
than unsigned, as this is the most common; the fact that problems
associated with unsigned integers have only recently surfaced indicates
that the most of the previous thinking was only in terms of signed
integers.
Requiring the language to "support" all "implemented" integer formats is
ridiculous. To conform to the implied exception handling for these
formats (especially 8-bit and 16-bit) would slow these operations down
by an order of magnitude and would provide no useful gain to most users.
Performance of floating-point to 8-bit and 16-bit fixed-point conversion
may be performance critical. This could be the case for graphics and
multimedia applications. Such conversions may often appear in
vectorizable portions of the application. There is no justification to
require these operations to conform to any exception requirements.