Very strange problem with comparing floating point numbers

[monarch_dodra]

On Sunday, 30 September 2012 at 18:31:17 UTC, so wrote:
> On Sunday, 30 September 2012 at 17:07:19 UTC, monarch_dodra 
> wrote:
>> On Sunday, 30 September 2012 at 01:29:24 UTC, Ivan Agafonov 
>> wrote:
>>> // Tell me about this sutation, may be it is a bug?
>>>
>>> [SNIP]
>>> 	// all of this fails!!!
>>> 	assert (a.length == a.length); // This is really shocking
>>> 	assert (a.length == a3.length);
>>> [SNIP]
>>
>> This is just a fact of life regarding how floating point types 
>> work. Here is a well documented explanation. It pertains to 
>> C++, but applies.
>>
>> http://www.parashift.com/c++-faq/floating-point-arith2.html
>>
>> As a rule of thumb, NEVER use opEqual with floating point 
>> types aniways. You need to use some sort of comparison with 
>> leway for error, such as std.math.approxEqual.
>
> Floating point types are trouble enough without these
> optimization failures.
> There are many unsolved problems, things like approxEqual are 
> far
> from answering them. Whatever the justifications they come up
> with, "a.len == a.len" failure is IMO unacceptable, an opEqual
> like this must not fail.
>
> A suggestion: do what i do and have this in your config files.
>
> alias real evil;

I don't really agree with that. floating point operations are 
just inexact, regardless of optimizations. That's how they work, 
period.

Either you can work with inexact results, and you use them, or 
you can't, and don't. Banks don't use floating point types for 
exactly this reason. You have to know what you are getting into 
before you begin.

The real troubles really only start when you start using floating 
point type, but you expect exact results.