Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!zaphod.mps.ohio-state.edu!think.com!paperboy!hsdndev!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: Here's a challenge for floating point lovers.
Message-ID: <15010@smoke.brl.mil>
Date: 29 Jan 91 18:27:08 GMT
References: <2855@charon.cwi.nl> <14993@smoke.brl.mil> <3322@unisoft.UUCP>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 23

In article <3322@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes:
>How many different floating point formats are there out there?

There are many.  IBM mainframes use a base-16 representation, and Gould
PowerNodes have a similar if not identical representation.  Other long-
established mainframes tend to have other floating formats.  Even among
IEEE implementations, there are several variations.

>I can only assume that somehow IEEE is drain-bamaged; whether by loss of
>precision or what, I don't know.

There are several problems with IEEE floating point.  The model of
"negative infinity", "signed zero", etc. is not mathematically correct,
and programs that rely on such non-numbers can silently produce incorrect
results.  The deficiency that is relevant for our original discussion is
that the IEEE standard envisions programs actually dealing with, nay,
HAVING to deal with, detailed aspects of the model such as rounding modes.
This is utterly inappropriate for visibility at a higher-level language
such as Fortran, Pascal, Modula II, C, Ada, etc. where what is desired is
that the language implementation provide a single consistent model for
floating-point (approximate real-number) operations.  We had one heck of
a time trying to adjust the standard C library math function specifications
to accommodate the weird behavior of IEEE f.p. implementations.