Xref:	news2.mv.net comp.lang.c:54267 comp.lang.c++:69758 comp.os.msdos.djgpp:633 gnu.g++.help:4411 gnu.gcc.help:5626
From:	axl AT zedat DOT fu-berlin DOT de (Axel Thimm)
Newsgroups:	comp.lang.c,comp.lang.c++,gnu.gcc.help,gnu.g++.help,comp.os.msdos.djgpp
Subject:	float != float and floats as return types
Date:	Mon, 29 Jan 1996 20:12:38 GMT
Organization:	FU Berlin
Lines:	56
Message-ID:	<4ej9lb$mpc@fu-berlin.de>
Reply-To:	axl AT zedat DOT fu-berlin DOT de
NNTP-Posting-Host:	axl.dialup.fu-berlin.de (160.45.218.93)
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

Hello,
I am getting confused, about how C/C++ manage float binary operations,
in particular multiplication. The next C++ example gives me surprising
results:
	*** cut here: begin file t_prec.cc
	#include <iostream.h>
	#include <iomanip.h>
	#include <math.h>
	float quad( float );
	int main() {
	  for( int i=0; i<10; ++i ) {
	    float a, b, c;
	    a = i/13.123123;
	    b = a*a;
	    c = quad(a);
	    cout << (b - c) << '\t';
	    cout << (b - a*a) << '\t';
	    cout << (c - quad(a)) << '\n';
	  }
	  return 0;
	}
	float quad( float x ) { return x*x; }
	*** cut here: end file t_prec.cc
(Sorry for not using C-syntax. You can substitute the "cout <<" part
with "printf" calls, I realized it to late to try it out, and
"translating" it on the fly might get typos in)
I compile with the MSDOS port of gcc as follows: gcc t_prec.cc -lgpp 
So here is my output:
	*** cut here: begin output
	0	0	0
	0	3.21547e-11	3.21547e-11
	0	1.28619e-10	1.28619e-10
	0	-1.25443e-09	-1.25443e-09
	0	5.14475e-10	5.14475e-10
	0	7.14357e-10	7.14357e-10
	0	-5.01772e-09	-5.01772e-09
	0	-1.46904e-08	-1.46904e-08
	0	2.0579e-09	2.0579e-09
	0	-2.02694e-09	-2.02694e-09
	*** cut here: end output
At first I thought all numbers should be zeros. The middle column might
not be zero, if the compiler calculates in higher precision than what
the variables are, so an intermediate storage (b) might loose some
digits, but I cannot understand what happens with c! Both times a
function is called, that _is_not_ inlined, so in both cases the same
loss of digits should be observed.
Any ideas?

Regards
	Axel Thimm

===
Axel Thimm <axl AT zedat DOT fu-berlin DOT de>
Freie Universitaet Berlin
===

- Raw text -