Loss of precision errors in FP conversions

[Robert Jacques]

On Tue, 19 Apr 2011 20:37:47 -0400, bearophile <bearophileHUGS at lycos.com>  
wrote:
> dsimcha:
>
>> I know what you suggest could prevent bugs in a lot of
>> cases, but it also has the potential to get in the way in a lot of  
>> cases.
>
> You are right, and I am ready to close that enhancement request at once  
> if the consensus is against it.
>
> double->float and real->float cases are not so common. How often do you  
> use floats in your code? In my code it's uncommon to use floats,  
> generally I use doubles.

I do GP GPU work, so I use floats all the time. They're also useful for  
data storage purposes.

> A problem may be in real->double conversions, because I think D feels  
> free to use intermediate real values in some FP computations.

For your information, the x87 can only perform computations at 80-bits. So  
all intermediate values are performed using reals. It's just how the  
hardware works. Now I now some compilers (i.e. VS) allow you to set a  
flag, which basically causes the system to avoid intermediate values  
altogether or to use SIMD instructions instead in order to be properly  
compliant.

> Another possible problem: generic code like this is going to produce an  
> error because 2.0 literal is double, so x*2.0 is a double even if x is  
> float:
>
> T foo(T)(T x) {
>     return x * 2.0;
> }
>
> But when I use floats, I have found it good a C lint that spots  
> double->float conversions, because it has actually allowed me to speed  
> up some code that was doing float->double->float conversions without me  
> being aware of it.
>

Yes, this auto-promotion of literals is very annoying, and it would be  
nice if constants could smartly match the expression type. By the way,  
C/C++ also behave this way, which has gotten me into the habit of adding f  
after all my floating point constants.