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.
