On Fri, Dec 27, 2019 at 4:48 AM Piotr Caban piotr.caban@gmail.com wrote:
On 12/27/19 4:41 AM, Erich E. Hoover wrote:
On Thu, Dec 26, 2019 at 7:05 AM Piotr Caban piotr.caban@gmail.com
wrote:
... I was working on different strtod implementation (ucrtbase (as well as glibc) uses sub 0.5 ulp precision algorithm). It's not ready yet. Also it's not something that can be added during code-freeze.
Yeah, my approach was to try and get something that can cope with the 53-bit "long double" problem on x86-64 until after code freeze. AJ wasn't particularly thrilled with adjusting the x87 FPU settings as a workaround.
... The 1.1e-30 tests is an example of a test that stopped working in strtod with your patches.
Since this test wasn't in strtod I didn't catch it until trying to fix scanf.
While working on new implementation of strtod I was running Chromium string conversion tests (it's a 100k semi random doubles conversion test). Here are some results: ...
I'd be curious to see what this looks like with my new approach, once I understand why you are getting different test results from me.
ucrtbase scanf tests:
- Windows: 0 failures
- Current 32-bit Wine: 36 failures, biggest error: 1 ulp
- Current 32-bit Wine with the patch you have attached: 49779
failures, the exponent is sometimes off by 1, e.g. on "1.5475148155234508e-252"
Just to confirm, you're running the current tests for dlls/ucrtbase/tests/scanf.c on 32-bit x86? The reason that I ask is that I'm getting 0 failures for that (both with and without the patch) and 0 ulp for 1.5475148155234508e-252.
The test that produces the biggest error for strtod function is: 4.0621786324484882e-053
I don't see this test, so I popped it in really quick and I'm getting 1 ulp with the patch (4 without).
I'm afraid that your patches will possibly cause tons of regressions and I'm not sure yet how to proceed with it during the code-freeze.
I think we need to figure out why we're getting different results on 32-bit. I've been doing most of my testing on 64-bit (since that's what broke horribly with the _control87 update), but the version I attached should pass all the current tests on both (whether applied to strtod or scanf).
There's a quite simple algorithm that should have similar results as msvcrt (I will need to implement it in order to know) that can possibly go into Wine during code-freeze. On the other hand it will need to be rewritten after the code-freeze so I'm not a fun of it. The proper algorithm I was working on will definitely exceed 1k lines of code.
Yikes, I figured a properly compliant implementation would be big - but not that big.
... I was thinking about having a common helper that will be used both in strtod and scanf. Proper string to double conversion is complicated and I don't think it should be mixed with scanf implementation. ...
Makes sense to me.
Best, Erich