Fix Issue 5628 - std.math unittest disabled - roundoff error in pow()

[ghost]

The original tests compare apples and oranges, that is, left side double/float, right side real. The values on the left side are correct in the precision available but real has better precision and therefore the tests failed. Casting to the lower precision fixes this.

As a side note: I dislike these tests, because the right side could still produce wrong results, depending on the implementation of * and / and rounding errors. I'd prefere to compare to manually calculated literals.

[dlang-bot]

Thanks for your pull request and interest in making D better, @berni44! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	5628	normal	std.math unittest disabled - roundoff error in pow() on SSE2

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + phobos#7321"

[ghost]

WIP: The unittest failed on FreeBSD. i added some writelns to see, what happens...

[wilzbach]

WIP: The unittest failed on FreeBSD. i added some writelns to see, what happens...

FYI: We only semi-officially support FreeBSD. For example, std.net.curl isn't supported at all anymore and with the upcoming FreeBSD 12 isn't supported either. So if there's no immediate fix/solution, I would suggest not to bother about FreeBSD (i.e. disable it for FreeBSD) and waste time into that sink, but into more interesting and impactful things ;-)

[ghost]

Unfortunately win32 has the same bug.

[ghost]

Not WIP anymore. I found a workaround with approxEqual. The constants used there are so small, that it's actually comparing for equality.

IMHO it's a bug in DMD and I filed a bugreport. We are discussing it there currently.

[kinke]

I don't think the compiler is to blame here at all. The problem/surprising fact is that this templated pow overload takes a F floating-point input type, but always uses real p = 1.0, v = void; - that's what's causing the excess/surprising intermediate precision.

The original tests compare apples and oranges

Absolutely.

[ghost]

I don't think the compiler is to blame here at all. The problem/surprising fact is that this templated pow overload takes a F floating-point input type, but always uses real p = 1.0, v = void; - that's what's causing the excess/surprising intermediate precision.

From the discussions in the bugreport I meanwhile know, that "intermediate results" is stretched far more on 32bit machines than I thought. The result type of pow is essentially F, but the compiler returns a real. If that would be cast to F before returning, as I think it should, it would work.

[thewilsonator]

This is green, is it good to go?

[ghost]

IMHO yes