Hexidecimal floating-point constants

Michael Meissner uunet!osf.org!meissner
Tue Dec 29 10:08:09 PST 1992


| 
| Awhile ago, Jim Thomas a Taligent sent me a copy of the "Floating Point C
| Extensions" document being developed by x3j11.1.
| 
| I think I ought to say right up front that I think this is a very admirable
| document, and that in general I find it very well concieved and well thought
| out.
| 
| I do have one nit to pick however.
| 
| I am concerned about the apparent lack of generality in the proposed new
| lexical grammar for "hexidecimal" floating-point literals.  In particular,
| the lack of direct support for Infinities and NaNs appears to be to be a
| very serious shortcoming of this approach to providing a more flexible
| mechanism for writing floating-point literals.
| 
| Having said this, I am also obliged to say that this is perhaps an unfair
| criticism.  It would certainly be unfair to criticize some proposed solution
| for some particular problem simply because the proposed solution does not
| also solve some *different* problem which, although related, is *not* the
| problem that the solution in question was intended to address.

Given that there are still systems out there which are not IEEE
754/854 complaint, how would you propose an alternative format which
handles all of the different formats of NaNs, the two infinities
(+/-), and subnormal numbers?  If you mean to encode the floating
point number directly as bits, then this isn't very portable.  One
such way of getting an Infinity, albeit at runtime is:

	extern double strtod ();
	double d = strtod ("INF", (char **)0);

| In fact, I'm not 100% sure what problem the proposed hexidecimal floating-
| point literal notation was really intended to solve.  One sentence in
| section 3.1.2.1 of the "Floating Point C Extensions" document provides a
| clue by saying "Hexidecimal more clearly expresses the significance of
| floating constants."
| 
| If the only goal of this proposed extension to ANSI C was to enable people
| to "more clearly" write floating-point literals (which they can already
| write using other notations) then I would have to say that the proposed
| approach does indeed achieve that limited goal.

The goal, as I understand it, it to allow people to EXACTLY express a
floating point number with any roundoff errors in converting from
decimal.

| I guess that my *real* complaint is that x3j11.1 did not choose to tackle
| the broader goal of providing a new and *generalized* notation which would
| enable me (as a programmer) to write floating point literals which I am
| currently unable to write in ANSI standard C.
| 
| I feel quite certain that if this broader goal had been embraced by x3j11.1,
| a different (and more generalized) notation could have been devised which
| would have permitted floating-point Infinity and NaN values to be encoded
| as floating-point literals.  (If anyone doubts that a more generalized
| notation is possible, I stand ready to refute that view with a concrete
| proposal.)
| 
| It may be far too late in the process for me to raise this issue of the
| goals for the new floating-point literal notation, but I'm doing so anyway.
| If the goal of the new "hexidecimal" floating-point literal notation was
| in fact only to make floating-point literals more readable, then I am
| inclined to say that x3j11.1's goals were too modest in this area.  If,
| as I suspect, the goals *were* too modest, then I would encourage x3j11.1
| to revisit the question of what the goals should be, and to expand those
| goals to include the development of some notation by which a programmer
| could encode *all possible* floating-point values which might ever be
| useful.
| 
| 
| // Ron ("Loose Cannon") Guilmette    uucp: ...uunet!lupine!segfault!rfg
| //
| // 	"On the one hand I knew that programs could have a compelling
| // 	 and deep logical beauty, on the other hand I was forced to
| // 	 admit that most programs are presented in a way fit for
| // 	 mechanical execution, but even if of any beauty at all,
| // 	 totally unfit for human appreciation."
| // 						-- Edsger W. Dijkstra
| 



More information about the Numeric-interest mailing list