bug in _doprnt

[Darryl P. Wagoner]

In article <2788 at gryphon.CTS.COM> freuden at gryphon.CTS.COM (Ralph Freudenberger) writes:
>
>
>I just discovered a bug with the _doprnt procedure responsible for
>library functions such as printf, sprintf, etc.
>
>It seems that there is an inconsistency in the way the unix-pc rounds
>off floating point numbers through _doprnt.
>
>If one runs the following rough program and give the following input:
>	0.4750 
>
>one will get 0.47 as output.
>
>But when one gives 0.4650 as input one receives 0.47 as output.....
>very peculiar.

This will happen with all floating point machines, do to the way that
it is store the number maybe off by a little.  

For example:


0.475 is store to the closest floating point number which is
0.47499999999999998 which would be rounded down.  0.465 on the other
hand is store as 0.4560000035762869 which would be rounded up.
Also remember and never forget:  Floating point IS NOT store exact!

That is why COBOL, PL/I(which also has float), some BASIC use BCD math.
The problem is that it is very slow.


OUTPUT
------

 a=0.47  b=0.47  c=0.48
 d=0.47  e=0.47  f=0.48

 a=0.4650000035762786900  b=0.4749999940395355200  c=0.4750001132488250700
 d=0.4650000000000000200  e=0.4749999999999999800  f=0.4750000999999999800


main() {

float	a,b,c;
double  d,e,f;

a=.4650;
b=.4750;
c=.4750001;

d=.4650;
e=.4750;
f=.4750001;


printf(" a=%4.2f  b=%4.2f  c=%4.2f\n",a,b,c);
printf(" d=%4.2f  e=%4.2f  f=%4.2f\n\n",d,e,f);

printf(" a=%20.19f  b=%20.19f  c=%20.19f\n",a,b,c);
printf(" d=%20.19f  e=%20.19f  f=%20.19f\n\n",d,e,f);
}
-- 
Darryl Wagoner		dpw at unisec.usi.com
UniSecure Systems, Inc.; 			OS/2, Just say No!
Round Rock,  Tx; (512)-255-8751 (home) (512)-823-3774
UUCP:  {ut-sally!uiucuxc!kitty}!unisec!dpw