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