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".
?
