🚀 go-pugleaf

In article <KINGDON.90May30012449@pogo.ai.mit.edu>,
 kingdon@pogo.ai.mit.edu (Jim Kingdon) writes:
> In comp.std.c, O'Keefe writes:
>     (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,

Jim Kingdon then gives a clear explanation of why he thinks this doesn't
follow.  I am obliged to confess that I was taking this "on authority"
from an article in Software Practice & Experience a couple of years ago.

There are some subtleties in 754-1985.  For example, a C compiler which
implements "long double" as IEEE extended double runs into "1.3 This
standard does not specify (3) binary<->decimal conversions to and from
extended formats", so long double literals are governed only by the C
standard.

One important question is whether a compiler counts as a "user",
within the meaning of the standard.  The definition is
	"user.  Any person, hardware, or program not itself specified
	by this standard, having access to and controlling those
	operations of the programming environment specified in this
	standard."
Now the most natural interpretation of this _to me_ is that a compiler
counts as a "user" with respect to its _own_ use of floating point,
but that with respect to the floating point operations expressed in my
program, it counts as part of the implementation.  This does get rather
blurred when you have an interpreter or incremental compiler.

If we regard the compiler as a "user" then it might have selected
_any_ of the four rounding modes, and we have no right to expect
say, round to nearest.  So we have two cases:
(a) A compiler is part of the implementation,
    floating-point literal -> binary conversion is notionally run-time;
    it ought to be affected by rounding mode and exception mode;
    therefore to be certain of what you're getting hex floats are useful
(b) A compiler is a user, not an implementation,
    floating-point literal -> binary conversion is compile-time;
    it is affected by whatever rounding mode the compiler writer chose;
    therefore to be certain of what you're getting hex floats are useful.

For example, the method suggested for getting an IEEE infinity, namely
	static double infinity = 1.0e300*1.0e300;
is _not_ guaranteed to produce an infinity value; the compiler, if
thought of as a "user", may have said "never mind this Infinity business,
I want *exceptions*" and might quite reasonably reject the program
(perhaps by dumping core or some such traditional method).
Or failing that, the compiler-writer might have selected "round toward 0"
which (7.3(2)) "carries all overflows to the format's largest finite
number with the sign of the intermediate result".  Is there any reason
why an ANSI C compiler doing this would not be conforming to IEEE 754,
_if_ we regard the compiler as "user" rather than "implementation"?

The key point in the standard is that binary<->decimal conversion is
listed as an OPERATION in section 5.  It's one of the things that can
signal exceptions (if you have EXPLICITLY asked for exceptions, by
means outside the scope of the standard).  So if I write
	double boojum = 1.0e999;
I have specified in my program an >operation< which might return an
Infinity or might signal Overflow, depending on the run-time state.
Consider
	/* fragment 1; clearly run-time */
	static double x = 1.1e300;
	static double y = 1.2e300;
	void foo() { double z = x*y; ... }

	/* fragment 2; is this compile-time or what? */
	#define x (1.1e300)
	#define y (1.2e300)
	void foo() { double z = x*y; ... }

	/* fragment 3; how about this one? */
	static const double x = 1.1e300;
	static const double y = 1.2e300;
	void foo() { double z = x*y; ... }

In each case I have specified in my program that a certain operation
be performed involving certain operands; the same operation and operands
in each case.  If I get an Infinity value in z when I had asked for
exceptions, I may be in trouble...

What's the relevance of this to the conversion of literals?  Just that
conversion of 1.2e300 from decimal to binary is in every respect just
as much an "operation" as multiplication is.  It is influenced by the
rounding mode and exception mode in just the same ways that multiplication
is.

Now, I don't myself know of _any_ compiler that does decimal->binary
conversion at run time, and that interpretation would obviously cause
difficulties for static initialisers.  But the other interpretation
means that we cannot express IEEE special values portably, so either
way hex floats are useful.

IEEE 854 is similar to 754.  They mostly stuck to the same wording.
The main point of 854 was to generalise to other word lengths than
32, 64, &c, and to allow decimal as well (so you can have an 854-
conformant pocket calculator).


There is a proposed standard for the floating-point aspects of
programming language standards.  I just borrowed a copy of the
SigPlan Notices issue containing it, and don't know what it says
yet.  No doubt that will make life even more interesting, so many
standards to choose from!
-- 
"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."