Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!dayton!viper!john
From: john@viper.UUCP
Newsgroups: comp.lang.c
Subject: Re: Floating Point Comparisons
Message-ID: <726@viper.UUCP>
Date: Mon, 23-Mar-87 13:26:14 EST
Article-I.D.: viper.726
Posted: Mon Mar 23 13:26:14 1987
Date-Received: Wed, 25-Mar-87 01:37:26 EST
References: <842@vaxb.calgary.UUCP>
Reply-To: john@viper.UUCP (John Stanley)
Distribution: na
Organization: DynaSoft Systems
Lines: 32


  It strikes me, that while calculations in floating point can be done
in extended precision (more significant bits then are stored), that when 
a comparison is done, it -must- be for the number of significant digits 
that would be stored if I were to transfer the result of that calculation
to a non-register variable.  The operations in question are "logical" tests,
and should not in any way be considered absolute algebraic tests...!

  All logical comparisons need to make use of an operation akin to casting
which will "cast" the internal representation into a normalized, limited 
precision, form which can be safely checked against.  This only needs to
be done to a value which does not come directly from an auto or static
variable. (the result of a calculation or an extended precision register)
If register FP variables have exactly the same number of significant digits
as an non-register variables -and- is already normalized, then this "cast"
needs to be done only on FP values which are not lvalues.

  Yes, this is a nusance for the implementor, but there is no other way 
for a comparison (of any form: == >= <= etc..) to be safely considered
"logical" across any range of tests and consistant across multiple
implementations on differnt machines.  There are many things in the
ANSI standard that will be a nusance to implementors and programmers
alike in a few situations...  This is a standard..  If we're going to
have anything akin to a rational standard and include FP calculations
in that standard, this problem MUST be delt with.  We can no longer
continue to leave things like this in the category of "implementation
dependant" problems....

--- 
John Stanley (john@viper.UUCP)
Software Consultant - DynaSoft Systems
UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john