On 15 August 2015 at 15:55, Bernhard Übelacker bernhardu@vr-web.de wrote:
It is not that inaccurate and yes, I did just copy from the ddraw tests.
The constants I use in the test would allow for using 0 as ulps. If I understand correctly a direct comparison would then also be possible (at least on my system and testbot).
So should we remove the compare_float altogether and use a direct comparison?
If you're careful about using values that are exactly representable you can just use a simple compare, yeah. Arguably the more interesting tests would be values that aren't exactly representable with different FPU precision and rounding modes though.
As an aside, other potentially interesting things to test are the decimal separator depending on locale, different number digits depending on locale (e.g. "۰٫۲۵"), C99 hexadecimal floats, and floating point specials like e.g. 1.#inf/INF/INFINITY.
And if not, how many representable floats difference whould be suitable? (The smallest value I see in other tests is 16.)
It depends on a lot of things, like what you're testing, how close you need to match the Windows values and how much the values are expected to differ between different machines because of e.g. hardware or driver differences. In practice you'd start with something reasonable and then either make the bounds tighter when you run into an application that depends on those tighter bounds or looser when you encounter more variance in the test results. For something like strtof() it may actually be reasonable to compare to an specific bit-pattern instead of a floating point value.