On 1.6.2014 18:02, Famous wrote:
> This is different. The decimal 1.234 cannot be exacly represented as radix-2 floating-point number. In your example above, a and b are not equal. They are both approximations to 1.234 but the value of b is

Still feels iffy to me. If you add:

   printf("%.70f\n%.70f\n", a, cast(float) b);

you can see that gcc in C and gdc in D both convert value of b to float resulting in equality. Dmd doesn't, it just ignore the cast.

-- 
mk

On Sun, 01 Jun 2014 14:42:34 +0000
Famous via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
wrote:

> On Sunday, 1 June 2014 at 12:45:26 UTC, bearophile wrote:
> > It's a bad question.
>
> Actually, Martin's question is a good one.
>
> Initializing a variable of type float via a literal or as conversion from string should be the same, exacly, always. Casting a float to double should be deterministic as well.

Not necessarily, particularly because any floating point operations done at compile time are generally done at much higher precision than those done at runtime. So, it's pretty trivial for very similar floating point operations to end up with slightly different results. In general, expecting any kind of exactness from floating point values is asking for trouble. Sure, they follow the rules that they have consistently, but there are so many numbers that aren't actually representable by a floating point value, the precisions vary just enough, and slightly different code paths can result in slightly different results that depending on floating point operations resulting in any kind of specific values except under very controlled circumstances just isn't going to work.

- Jonathan M Davis

I have a couple of functions that you may find useful for comparing floats.

https://github.com/nomad-software/dunit/blob/master/source/dunit/toolkit.d#L42
https://github.com/nomad-software/dunit/blob/master/source/dunit/toolkit.d#L134