[comp.sys.mac.programmer] Float to integer conversion problem

mcgrath@uicsrd.csrd.uiuc.edu (08/10/88)

> 
> /* Written 11:45 pm  Aug  7, 1988 by eacj@batcomputer.tn.cornell.edu in uicsrd.csrd.uiuc.edu:comp.sys.mac.programmer */
> /* ---------- "Float to integer conversion problem" ---------- */
> I hope someone can explain this one for me.  The following code fragment
> is a simplified version of a routine that was giving me unexpected
> results.  The results below were obtained in LightspeedC version 3.0,
> running under System 6.0:
> 
>         double d;
>         long m,n;
> 	
>         m = 126.0;          /* m becomes 126 */	
>         d = 12.6 * 10.0;    /* d becomes 126 */
>         n = d;              /* n becomes 125 !! */
> 		
> I cannot understand why n gets "rounded down" to 125.  Am I missing
> something subtle about C syntax or IEEE type conversions, or is this a bug
> in SANE or LSC?  The variable values shown in the comments were verified
> with the LSC debugger and with my own debugging dialog.  If I use the
> debugger to force a value of 126.0 into d before the last line is
> executed, then n gets the correct result.  What's happening here?    
> -- 
> Julian Vrieslander     "Don't rush me... you'll get a rotten miracle."
> Neurobiology & Behavior, W250 Mudd Hall, Cornell University, Ithaca NY 14853    
> UUCP: {cmcl2,decvax,rochester,uw-beaver,ihnp4}!cornell!batcomputer!eacj
> INTERNET: eacj@tcgould.tn.cornell.edu     BITNET: eacj@CRNLTHRY
> /* End of text from uicsrd.csrd.uiuc.edu:comp.sys.mac.programmer */

My (admittedly old) copy of the draft ANSI standard for C says:

"When a value of floating type is converted to integral type, the
fractional part is discarded....  
When a value of integral type is converted to floating type, some 
loss of precision occurs if the destination lacks sufficient 
precision." [section 3.2.1.3]

Hence, this is correct behavior assuming that the floating point
value was actually represented by a number a little smaller than
126.

I found that the 4.3bsd 'cc' compiler produces identical code
for "d = 126.0" and "d = 12.6 * 10.0".  If your compiler does
something similar, then the loss of precision occurs in the
COMPILATION, not during the execution.