http://d.puremagic.com/issues/show_bug.cgi?id=5866



--- Comment #3 from Don <clugd...@yahoo.com.au> 2011-04-20 12:34:16 PDT ---
(In reply to comment #2)
> (In reply to comment #1)
> > float  = float * float + float
> > 
> > contains a conversion from double to float.
> 
> Thank you for your comment. In programming I'm always finding new and new ways
> to be wrong or just to show ignorance :-) But this program, gives no errors
> with DMD 2.052:
> 
> 
> float f1() { return 1.0f; }
> float f2() { return 2.0f; }
> float f3() { return 3.0f; }
> void main() {
>     static assert(is(typeof(f1() * f2()) == float));
>     static assert(is(typeof(f1() * f2() + f3()) == float));
>     float result;
>     static assert(is(typeof(result = f1() * f2() + f3()) == float));
> }
> 
> 
> And a good C lint gives no double->error warnings in this C program:
> 
> float f1() { return 1.0f; }
> float f2() { return 2.0f; }
> float f3() { return 3.0f; }
> int main() {
>     float result = f1() * f2() + f3();
>     return 0;
> }
> 
> 
> So where's the double->float conversion?

It's not exactly a double->float conversion. But it's part of the same issue:
to what extent is the compiler allowed to perform floating-point promotions,
and use extra precision?

It shows up when f3 is negative, and slightly less than f1*f2. If the compiler
is using doubles for intermediate results (which it is allowed to do), the
results are not the same as if floats were used throughout. 
An obvious case is when f1 = float.max, f2 = 1.5, f3 = -float.max.
If it stays as float, the result will be +infinity. If intermediate doubles are
used, the result is 0.5 * float.max. (It affects precision as well as range,
but the range examples are more obvious).
Floating point multiply-accumulate (FMA) can do the same thing.

As long as you support x87, or allow FMA, this stuff is inevitable.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

Reply via email to