On 14 August 2015 at 04:44, Bernhard Übelacker bernhardu@vr-web.de wrote:
- /*strtof*/
- f = p_strtof(float1, &end);
- ok(compare_float(f, 12.1, 4096), "f = %lf\n", f);
Is it really that inaccurate, or did you just copy 4096 from the ddraw tests?
Am 14.08.2015 um 11:00 schrieb Henri Verbeet:
On 14 August 2015 at 04:44, Bernhard Übelacker bernhardu@vr-web.de wrote:
- /*strtof*/
- f = p_strtof(float1, &end);
- ok(compare_float(f, 12.1, 4096), "f = %lf\n", f);
Is it really that inaccurate, or did you just copy 4096 from the ddraw tests?
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?
And if not, how many representable floats difference whould be suitable? (The smallest value I see in other tests is 16.)
Thanks for reviewing.
Kind regards, Bernhard
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.
Hello Henri, thank you very much for your input.
Am 17.08.2015 um 12:42 schrieb Henri Verbeet:
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.
The tested values up to now were simple ones because the real implementaion is inherited from msvcrt.dll and the more detailed tests are probably there.
I just wanted to test how it behaves when a value fitting into a double is now put into a float. (As far as I can see is msvcr120 is the first version were this float version strtoX is available, therefore I did put the tests there).
For the different number digits - this would be more subject to wcstof and _wcstof_l ?
However, it took some time to find the meaning of "۰٫۲۵" ... I did some tests and only after changing formats in regional settings to Persian, on an otherwise german Windows, wcstof did correctly interpret "٠.٢۵" (ARABIC-INDIC DIGITs with an regular ','). "۰.۲۵" (EXTENDED ARABIC-INDIC DIGITs) did not work.
I will try to expand my tests with the other cases you mentioned and send a new version.
Kind regards, Bernhard
WCHAR floatl[] = {'0', ',', '2', '5', 0}; WCHAR floatm[] = {0x0660, 0x066b, 0x0662, 0x0665, 0}; /* L"٠٫٢۵" ARABIC-INDIC DIGIT */ WCHAR floatn[] = {0x06f0, 0x066b, 0x06f2, 0x06f5, 0}; /* L"۰٫۲۵" EXTENDED ARABIC-INDIC DIGIT*/ WCHAR floatq[] = {0x0660, '.', 0x0662, 0x0665, 0}; /* L"٠.٢۵" ARABIC-INDIC DIGIT */
On 18 August 2015 at 01:13, Bernhard Übelacker bernhardu@vr-web.de wrote:
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.
The tested values up to now were simple ones because the real implementaion is inherited from msvcrt.dll and the more detailed tests are probably there.
It looks like some of those are covered by test__strtod() in dlls/msvcrt/tests/string.c, but not all of them. For what it's worth, I think those tests would be useful things to know, but not necessarily required to get an initial strtof() implementation accepted.
For the different number digits - this would be more subject to wcstof and _wcstof_l ?
Possibly, but that would be an interesting result on its own. MSDN doesn't write a lot about the character set used for strtof(), but in principle I'd expect it to interpret the string according to the current ANSI codepage (CP_ACP).
However, it took some time to find the meaning of "۰٫۲۵" ... I did some tests and only after changing formats in regional settings to Persian, on an otherwise german Windows, wcstof did correctly
Yeah, it would depend on that kind of regional setting. How about _wcstof_l() with the appropriate locale?
interpret "٠.٢۵" (ARABIC-INDIC DIGITs with an regular ','). "۰.۲۵" (EXTENDED ARABIC-INDIC DIGITs) did not work.
Odd.
WCHAR floatm[] = {0x0660, 0x066b, 0x0662, 0x0665, 0}; /* L"٠٫٢۵" ARABIC-INDIC DIGIT */
0x0665 is '٥' not '۵'.
-
Bernhard Übelacker -
Henri Verbeet