On Sunday, 15 May 2016 at 07:10:49 UTC, Era Scarecrow wrote:
But the const and immutable still have to fit within the confines of the size provided, so the fact they were calculated as real doesn't matter when they are stored as floats. If all the results are inverted, I don't see how that works...
The problem is that they aren't stored... It is implementation defined...
What is really bad about this is that you have: writeln(f==cf); // true writeln(f==1.30); // false writeln(cf==1.30); // true hence the following fallacy: ((f==cf) && (cf==1.30)) implies (f != 1.30) That is _very_ bad.
Although it does make sense that a float is being promoted up, and the lost precision vs the real is the problem...
The problem is that D "optimizes" out casts to floats so that "cast(real)cast(float)somereal" is replaced with "somereal":
writeln(1.30==cast(real)cast(float)1.30); // true
But then why does f==If fail? It doesn't answer that critical question, since they should be identical.
Because D does not cancel out "cast(real)cast(float)1.30)" for "f", but does cancel it out for cf.
Or basically: it uses textual substitution (macro expansion/inlining) for "cf", but not for "f".
?