Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!gatech!ncar!oddjob!uxc!uxc.cso.uiuc.edu!uicsrd.csrd.uiuc.edu!mcgrath
From: mcgrath@uicsrd.csrd.uiuc.edu
Newsgroups: comp.sys.mac.programmer
Subject: Re: Float to integer conversion problem
Message-ID: <22400002@uicsrd.csrd.uiuc.edu>
Date: 9 Aug 88 17:55:00 GMT
References: <5813@batcomputer.tn.cornell.edu>
Lines: 46
Nf-ID: #R:batcomputer.tn.cornell.edu:5813:uicsrd.csrd.uiuc.edu:22400002:000:2136
Nf-From: uicsrd.csrd.uiuc.edu!mcgrath    Aug  9 12:55:00 1988



> 
> /* 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.