Bug 5866 – std.math.sin(float), std.math.cos(float) to return float

Currently (DMD 2.052) std.math doesn't seem to use the cosf, sinf C functions, but it seems to use sqrtf (or something similar): import std.math: sqrt, sin, cos; import core.stdc.math: sqrtf, sinf, cosf; void main() { float x = 1.0f; // C functions static assert(is(typeof( sqrtf(x) ) == float)); // OK static assert(is(typeof( sinf(x) ) == float)); // OK static assert(is(typeof( cosf(x) ) == float)); // OK // D functions static assert(is(typeof( sqrt(x) ) == float)); // OK static assert(is(typeof( sin(x) ) == float)); // ERR static assert(is(typeof( cos(x) ) == float)); // ERR } I'd like std.math.sin/cos to return a float value when the input argument is a float. This is useful if you want to perform operations on floats and keep intermediate expressions (that call sin/cos) as floats: enum float PI_FLOAT = 3.14159265358979323846264f; // not present in std.math float x = 0.3f; float y = 2.0f * PI_FLOAT * sin(x); // contains no double->float conversions

Bearophile, I don't think that would achieve what you think. float = float * float + float contains a conversion from double to float.

(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?

(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.

(In reply to comment #3) > As long as you support x87, or allow FMA, this stuff is inevitable. Lot of complexities, I see. Going back to the point of this enhancement request, if cos(float) and sin(float) return a double, there is zero chance that the intermediate computations get performed among floats. So I think this enhancement request stands still.

Now converted to enhancement by SomeDude.

The code in the original bug report now compiles successfully on git HEAD ubuntu 16.04. Closing as WORKSFORME.