Floating point computation "non-bug"

[Dave Elcock]

>
>
>But, in effect, you're demanding that long double and double should be 
>identical, but expecting the compiler to read your mind.
>
Stop for a moment and imagine I'm not as experienced as you. I don't 
know what the compiler chooses as a default for constant or temporary 
values. I had imagined it was just a double. I'm showing my ignorance, 
but that's why I come to you guys for help. I'm no compiler expert.

Here's my logic - it works on other compilers, it doesn't on gcc, 
therefore there might be something wrong with gcc. Fairly simple.

>There are several ways to make that happen, but you chose not to.
>
It's nothing to do with "choosing not to". It's everything to do with 
ignorance, and my ignorance at that. I'm not as experienced as you, 
obviously.

Can you please just chill out a bit? If I'm wrong, just say so. Tell me 
in a direct, helpful way, rather than suggesting I'm out to deliberately 
mislead anyone.

>Or, if you mean to use lrint() instead of (int), write it that way.  Yes, 
>some compilers have command line options to make that conversion 
>automatically.  That violates all the C standards.
>
I've never heard of lrint() before. As I said, I'm probably not as 
experienced as you.
At least it is something I can use to get the desired results. I tried 
lrint() instead of (int) and it worked. Thanks for that.

>>Compiled with another compiler (e.g. Portland Group's pgcc), I get the
>>correct answer for the last line, so it's not about the machine's
>>precision.
>>    
>>
>How not?  You're probably choosing inconsistent options between the two 
>compilers.  You chose not to reveal the information, so I'll assume that.  We 
>don't even know whether your two compilers are using the same or different 
>library implementations of atof(), or whether you made any effort to make 
>them the same.
>
The information I "chose not to reveal" is just the default options for 
each compiler.
gcc test.c
and
pgcc test.c

If I modify the code to print out to a silly level of precision, the two 
compilers still come up with the same value for f1:
2.2999999999999998223643160599749535322189331054687500000000000000000000000000000000000000000000000000
with %.100f
So from my side of the story it looks like at least atof() is producing 
identical results.

Given that f1 is represented not as exactly 2.3, how does gcc manage to 
turn that in to 23 when assigning to f2, but 22 when casting to int? To 
my ignorant mind, they are both casts to int, so they should both give 
the same result. Can someone explain it simply please without assuming I 
know the guts of gcc?

>>If I had the expertise necessary to help with this, you could be sure
>>I'd get stuck right in and help out.
>>    
>>
>If you have the expertise to write this little sample, you have the expertise 
>to fix it.
>  
>
Surely not. Compilers are notoriously complicated pieces of software. I 
have huge respect for the GCC team. I wouldn't know where to start and I 
imagine it would take me months (if not years) to familiarise myself 
with the code base, never mind the theory behind compilers.


Having taken a step back after reading your reply, I have realised that 
I have made a rather humbling mistake - the code behaves the same in 
pgcc when f1 and f2 are declared as floats. However, when I swap them 
for doubles, pgcc gets it right, but gcc still comes up with the same 
answer of 22.


I'm sorry if I seem a bit narky Tim, but I was slightly thrown by your 
suggestion (intended or not) that I might somehow be trying to mislead 
people by not telling the whole story. I've told is as best I can. No 
hard feelings.


Cheers,
Dave.