Hexidecimal floating-point constants

[queueing-rmail]

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.

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.

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