Proposed comments and changes to P754 draft

[Bob Davis <bob@xxxxxxxx>]

P754 list.

I have several comments that I will be filing with the P754 vote.  I would
like to propose them here and seek response for the group.

1. An addition to Clause 5.12.3 External hexadecimal character sequences
representing finite numbers a hexadecimal sequence that is truly
Hexadecimal, with both the significand and exponent represented in
hexadecimal notation.  This would be in addition to the mixed C99
representation.  The addition would be a true hexadecimalExponentIndicator
of [Qq] to allow the exponent to be represented in hexadecimal notation.
Add to this section: 
HexadecimalExponentIndicator [Qq]
HexadecimalExponent {hexadecimalExponentIndicator} {sign}? {HexDigit}+

It would also be proper to adjust the current hexExponent to be a
decExponent as only decimal numbers are permitted.

2. This is an attempt to clean up the draft particularly with respect to
Clause 3 Formats.

What the standard is addressing in primarily Interchange Formats. The
remainder of the standard is to produce standardized results for
interchange. 
The inclusion of storage formats was to have shorter format available for
usage but to discourage math being done in those formats for fear of quickly
going beyond the capabilities of the format. All formats have this problem
and it is still the responsibility of the programmer. The math can always
and should be encouraged to take place in a more precise, larger, format.

Changes:

a. Remove the specific discussion of storage formats but retain the lengths
as interchange formats.  The ability to do stupid thing is the short format
exists in the longer format also and the need to to point out the general
rule for any format the it may be necessary to do the math in a larger
format to avoid errors and then present the result in the smaller format.
As these, previous, storage formats are well defined in 3.4 and 3.5, they
are no different from the other defined interchange formats.
   
b. Remove the separate definition of basic formats and have only interchange
and non-interchange formats. The interchange formats are well defined and
the non-interchange formats are up to the user's digression, and discretion,
under all conditions.
   
c. In Clause 3.4 - Add a column to Table 3 labeled ">128 Bits" and insert
the formulas from Table 8 and add the appropriated Table 9 below table 3.

d. In Clause 3.5 - Add a column to Table 4 labeled ">32 Digits" and insert
the formulas from Table 8 and add the appropriate Table 9 entries below
table 4.
   
e. Remove Clause 3.7 as it is now fully contained in clause 3.4 and 3.5.
   
f. Remove "storage" and "basic" from table 2.
----
Clause 3.1 proposal 

3.1 Overview: formats and conformance 3.1
This clause defines standard floating-point formats, in two radices, 2 and
10. All the formats specified by this standard are fixed-width. The
precision and range of a fixed-width format are determinable from the
program text, and the corresponding encoding is usually defined so that all
members have the same size in storage.

Formats defined by this standard are interchange or non-interchange:
-- interchange formats are formats with encodings defined in this standard.
They are widely available for arithmetic, storage, and for data interchange
among platforms. The format names used in this standard are not usually
those used in programming environments. Interchange formats, available for
arithmetic defined by this standard are: 1) binary interchange formats as
defined in Clause 3.4 of this draft and; 2) decimal interchange formats as
defined in Clause 3.5 of this draft.

-- non-interchange formats are extended and extendable precision formats
whose encodings are not defined in this standard but which are available for
arithmetic. None are required by this standard. Where required, interchange
of data in these non-interchange formats should be done using a suitably
large interchange format or external character sequences that meet the
requirements of 5.12.

A programming environment conforms to this standard, in a particular radix,
by implementing one or more of the interchange formats of that radix. The
choice of which of this standard's formats to support is language defined
or, if the relevant language standard is silent or defers to the
implementation, implementation-defined.

A conforming implementation of any format shall:
        -- provide means to initialize and store that format
        -- provide conversions between that format and all other supported
formats.

A conforming implementation of a format available for arithmetic shall:
        -- provide all the operations of this standard, as defined in clause
5, for that format.

-----
This will require cleaning up wording in other places making the text flow
much smoother. This may also remove some definitions that are no longer
needed.

Comment are welcome.


Bob Davis
bob@xxxxxxxx
408-857-1273 Cell