Abnormal normalizations? (fwd)

[Tom MacDonald]

> The following question was posted recently to the comp.lang.c++ newsgroup:
> 
> >>I have a question for language lawyers.  Is it required that the
> >>following code
> > 
> >>double y=some_value;
> >>double x=y;
> >>if(x ==y)
> >>  cout<<"TRUE";
> > 
> >>always prints TRUE?
> 
> This evoked the following interesting speculation from one contributor:
> 
> >It is best not to assume this.  While I would expect most compilers to
> >copy the double value faithfully, some might throw a "normalize" in
> >during the copy and lose a few insignificant bits...
> 
> I would like to ask the experts here assembled if there is any shread of
> truth to this speculation.  May compilers normalize FP numbers during
> the course of mere assignments?  If so, may these normalization operations
> indeed cause the loss of some significant (presumably low-order) bits?
> 
> 
> -- Ronald F. Guilmette, Sunnyvale, California -----------------------------
> ------ domain address: rfganetcom.com -------------------------------------
> ------ uucp address: ...!uunet!netcom.com!rfg -----------------------------

I really like the subject line:  Abnormal normalizations.  It has that
jumbo shrimp oxymoron feel to it.

My own personal opinion is that the standard imposes no requirement
on floating-point values to compare equal.  The following expression
is not, strictly speaking, guaranteed to evaluate to TRUE:

	3.0 == 3.0

at least according to the C standard.  This is left as a quality of
implementation issue.  I believe Jim Thomas has tried to strengthen
the requirements in his floating-point proposal.  He does this by
proposing a C binding to the IEEE floating-point standard.

To date, this proposal is not part of any standard.

As an aside, Fortran doesn't require the following to print TRUE either.
The Fortran standard says very little about floating-point precision,
range and accuracy.

	REAL X
	REAL Y
	DATA X /some_value/
	Y = X
	IF (X .EQ. Y) THEN
	   PRINT *, 'TRUE'
	ENDIF

Tom MacDonald
tamacray.com
uunet!cray!tam