https://issues.dlang.org/show_bug.cgi?id=20451

          Issue ID: 20451
           Summary: comparing identical floating points does not work on
                    Win32 and FreeBSD32.
           Product: D
           Version: D2
          Hardware: Other
                OS: Windows
            Status: NEW
          Severity: normal
          Priority: P1
         Component: dmd
          Assignee: [email protected]
          Reporter: [email protected]

Evolving from issue 5628:

---
import std.math;
import std.stdio;

void main()
{
    immutable real x = 46;
    immutable float xf = x;
    immutable double xd = x;
    immutable short neg2 = -2;
    immutable long neg8 = -8;

    writefln!"%.70f"(pow(xd, neg2));
    writefln!"%.70f"(cast(double) (1 / (x * x)));
    writefln!"%.70f"(pow(xf, neg8));
    writefln!"%.70f"(cast(float) (1 / ((x * x) * (x * x) * (x * x) * (x *
x))))$

    assert(pow(xd, neg2) == cast(double) (1 / (x * x))); // line 7902
    assert(pow(xf, neg8) == cast(float) (1 / ((x * x) * (x * x) * (x * x) * (x
$
}
---

I ran essentially this program in the testsuite and got:

0.0004725897920604915061933148923145608932827599346637725830078125000000
0.0004725897920604915061933148923145608932827599346637725830078125000000
0.0000000000000498812518796420273359260022516536992043256759643554687500
0.0000000000000498812518796420273359260022516536992043256759643554687500
****** FAIL release32 std.math
core.exception.AssertError@std/math.d(7902): unittest failure

This is the output of FreeBSD-32. On Win32 the result was essentially the same.
All others worked. If this program doesn't work (I have no direct access to any
of the two OSs), go to std.math, look for the test containing "neg8" and put
the last 6 lines of the unittest there (and remove @safe etc. from the test).
Then let the testsuite run.

And I'm pretty aware, that one should not compare floating point numbers with
== due to rounding issues. But the output above shows, that the numbers have
identical bit patterns and they are also of identical type. That should not
even fail with floating point numbers.

--

Reply via email to