Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!samsung!munnari.oz.au!ditmela!yarra!monu6!minyos!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.std.c
Subject: Re: Questions about NCEG
Message-ID: <3094@goanna.cs.rmit.oz.au>
Date: 28 May 90 11:18:21 GMT
References: <15519@bfmny0.UU.NET> <73.UUL1.3#5109@pantor.UUCP>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 44

In article <73.UUL1.3#5109@pantor.UUCP>, richard@pantor.UUCP (Richard Sargent) writes:
> Maybe Rex J. can tell us why have hex constants for float.

I'm not Rex J., but I can point out several reasons.

(1) If you stick to the letter of the IEEE 754 and IEEE 854 standards,
    conversion of numeric literals from decimal to binary (or possibly,
    in the case of 854, to internal decimal) is a *run* *time* operation,
    and is supposed to be sensitive to the rounding mode in effect at the
    time.  That is, if I do
	set_rounding_mode(IEEE_CEILING_ROUNDING_MODE);
	x = 1.324567891234567812367489;
	set_rounding_mode(IEEE_FLOOR_ROUNDING_MODE);
	y = 1.324567891234567812367489;
    x and y ought to be different (well, it depends on the exact constant).
    However, the IEEE 754 and 854 standards say nothing about conversion
    to or from hex.  

(2) There was an algorithm published in ACM TOMS last year for computing
    exp() with *amazingly* good accuracy (about half an ULP!) in IEEE
    arithmetic.  If I remember correctly, the magic numbers were expressed
    in hex.  The point was to be absolutely specific about precisely what
    bit pattern was wanted.

(3) There are special numbers (+ and - infinity, -0, NaNs, Vax reserved
    operands, &c) which have no standard syntax.

(4) If a float is written in hex, it is a clear signal that the number
    depends on the details of floating-point arithmetic.  It would be a
    common _notation_ for non-portable numbers, without going through
    unions and such.

(5) I would _much_ rather trust a compiler to convert a hex constant
    accurately to the last bit than trust it to get the decimal conversion
    right.  (I've read the comments in <math.h>.)

All in all, it's not a feature that many C users will want, but it's
something that people writing special functions and other parts of math
libraries would like a lot.  (Besides, it's a common extension to Fortran.
How can we let Fortran stay one up? (:-))

-- 
"A 7th class of programs, correct in every way, is believed to exist by a
few computer scientists.  However, no example could be found to include here."