Just a quick notice that the DWScript source code has begun a transition to Delphi 10.2.3 up from Delphi XE.
The goal is to target Win32 and Win64 compilers, mobile platforms and Delphi Linux are currently not in the scope.
At the moment “most” of the test suite is successful in both Win32 and Win64, though there are still warnings and hints when compiling which will be taken care of.
Of note is the introduction of a new TryStrToDouble function, which was introduced to work around bugs in the Win64 RTL version of StrToFloat and accompanying variants. As a bonus this new implementation should not only be more accurate, but is also 2-3 times faster and supports common float syntax variations (such as “.5” or “5.”). You can find it in the dwsUtils unit.
A new version of MPIR dll is also made available in 32 and 64bit, this is version 3 of MPIR, which is used for the BigInteger implementation.
In time Delphi XE support will fade away, and only Delphi 10.2.3 will be supported in the code base.
What about FPC compatibility? It would be just awesome, and much more future-proof.
FPC still in the distant horizon: it is passing maybe 90% of the tests, but the rest run into FreePascal idiosyncrasies or missing/partial implementations.
Next major refactor will likely be to replace Variant, as they got nerfed in Delphi 64. It will likely help with FreePascal as well (where Variants are problematic).
How good is your TryStrToDouble? Does it really always produce correctly rounded (i.e. within 1/2 ULP) values, i.e. really the nearest value possible (and it is exactly midway between, then the one that is even in the last ULP)? I found that doing a TryStrToDouble is not so easy at all, and for some values requires BigIntegers (or BigComp, as the reference implementation of strtod() uses). See: http://www.exploringbinary.com/how-strtod-works-and-sometimes-doesnt/. Note that GCC and VS/msvcrt don’t always get it right either. The site explotingbinary shows many values that are calculated wrongly (he checks them manually).
The goal was to provide accuracy comparable or higher to that of Win32 RTL’s StrToFloat under Win64, rather than accuracy comparable to strtod.
So it’s an accuracy of approx 1 ulp, rather than 1/2 ulp guaranteed, but it’s also a correct conversion for various exponent edge cases where even old Win32 RTL would fail, which is why I’m using it Win32 as well.
BTW one of the test cases shows such an ulp discrepancy, but it comes at the float exponentiation, and the precision loss could only be fixed by not using SSE2 in Delphi 64…
So all in all, it’s a “better effort” compared to previous RTL implementation, without aiming for perfect accuracy (since neither the rest of the compiler generated code nor the RTL’s Math unit aim for perfect accuracy).
And finally, more test cases welcome:)