Mail bounce from ncegacray.com mailing list.

[queueing-rmail]

Could one or both of you look into this problem.

Thanks.

// rfg

------- Forwarded Message

Date:    Mon, 21 Dec 92 20:56:05 +0000
From:    Mail Delivery Subsystem <lupine!uunet!num-alg-grp.co.uk!MAILER-DAEMON>
To:      MAILER-DAEMONanum-alg-grp.co.uk,
	 rfg <segfault!rfg>
Subject: Returned mail: Deferred

   ----- Transcript of session follows -----
554 mailer mail died with signal 13

   ----- Unsent message follows -----
T
Via: 
          id <sg.25251-0aben.uknet.ac.uk>; Mon, 21 Dec 1992 20:52:29 +0000
          Mon, 21 Dec 92 14:52:22 CST
          Mon, 21 Dec 92 14:50:43 CST
          4.1/CRI-5.5; Mon, 21 Dec 92 14:50:42 CST
          Mon, 21 Dec 92 14:50:40 CST
          Mon, 21 Dec 92 15:50:37 -0500
          id 154914.17094; Mon, 21 Dec 1992 15:49:14 EST
          Mon, 21 Dec 92 12:45:24 PST
From: uunet.UU.NET!lupine!segfault!rfg
          Mon, 21 Dec 92 11:20:25 PST
To: ncegacom.cray
Subject: Hexidecimal floating-point constants
Reply-To: uunet.UU.NET!lupine!segfault!rfg
Date: Mon, 21 Dec 92 11:20:25 PST


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

------- End of Forwarded Message