<div dir="auto">On Fri, Dec 27, 2019 at 4:48 AM Piotr Caban <<a href="mailto:piotr.caban@gmail.com" target="_blank" rel="noreferrer">piotr.caban@gmail.com</a>> wrote:<br>
><br>
> On 12/27/19 4:41 AM, Erich E. Hoover wrote:<br>
> > On Thu, Dec 26, 2019 at 7:05 AM Piotr Caban <<a href="mailto:piotr.caban@gmail.com" target="_blank" rel="noreferrer">piotr.caban@gmail.com</a>> wrote:<br>
> >> ...<br>
> >> I was working on different strtod implementation (ucrtbase (as well as<br>
> >> glibc) uses sub 0.5 ulp precision algorithm). It's not ready yet. Also<br>
> >> it's not something that can be added during code-freeze.<br><br>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.<div dir="auto"><br>
> ...<br>
> The 1.1e-30 tests is an example of a test that stopped working in strtod<br>
> with your patches.</div><div dir="auto"><br></div><div dir="auto">Since this test wasn't in strtod I didn't catch it until trying to fix scanf.</div><div dir="auto"><br></div><div dir="auto">> While working on new implementation of strtod I was</div><div dir="auto">
> running Chromium string conversion tests (it's a 100k semi random<br>
> doubles conversion test). Here are some results:<br>
> ...<br><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">
> ucrtbase scanf tests:<br>
>   - Windows: 0 failures<br>
>   - Current 32-bit Wine: 36 failures, biggest error: 1 ulp<br>
>   - Current 32-bit Wine with the patch you have attached: 49779<br>
> failures, the exponent is sometimes off by 1, e.g. on<br>
> "1.5475148155234508e-252"<br>
<br>
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.<br>
<br>
> The test that produces the biggest error for strtod function is:<br>
> 4.0621786324484882e-053<br>
<br>
I don't see this test, so I popped it in really quick and I'm getting 1 ulp with the patch (4 without).<br>
<br>
> I'm afraid that your patches will possibly cause tons of regressions and<br>
> I'm not sure yet how to proceed with it during the code-freeze.</div><div dir="auto"><br></div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">> There's<br>
> a quite simple algorithm that should have similar results as msvcrt (I<br>
> will need to implement it in order to know) that can possibly go into<br>
> Wine during code-freeze. On the other hand it will need to be rewritten<br>
> after the code-freeze so I'm not a fun of it. The proper algorithm I was<br>
> working on will definitely exceed 1k lines of code.<br>
<br>
Yikes, I figured a properly compliant implementation would be big - but not that big.</div><div dir="auto"><br>
> ...<br>
> I was thinking about having a common helper that will be used both in<br>
> strtod and scanf. Proper string to double conversion is complicated and<br>
> I don't think it should be mixed with scanf implementation.<br>
> ...<br><br>Makes sense to me.<br><br></div><div dir="auto">Best,</div><div dir="auto">Erich</div></div>