Decimal string to floating point conversion with correct half-to-even rounding
ilyayaroshenko at gmail.com
Sun Jul 5 07:24:02 UTC 2020
On Sunday, 5 July 2020 at 06:23:35 UTC, Walter Bright wrote:
> On 7/4/2020 8:09 PM, 9il wrote:
>> On Saturday, 4 July 2020 at 20:35:48 UTC, Walter Bright wrote:
>>> On 6/21/2020 8:24 AM, 9il wrote:
>>>> So excited to finally announce we can correctly parse
>>>> floating-point numbers according to IEEE round half-to-even
>>>> (bankers) rule like in C/C++, Rust, and others.
>>> Great work! Would you like to add it to dmd?
>> Thank you! Yes.
>> It would be very much appreciated to preserve the `mir.`
>> namespace for the `parse` module, the required `bignum`
>> package*. Also, whenever the code will be located I would like
>> to have control over it. Will you agree?
>> * - `mir.bignum` is 6K LOC and it is expected to grow up to
>> 20K LOC if finished. The package includes abstract views for
>> big integers, decimal, and binary FP numbers; stack-allocated
>> big integers; midsize unsigned integers; software FP numbers
>> with extended precision.
> Does the float parsing code require bignum?
Yes. The decimal float parsing requires big integer arithmetic
and software floating-point multiplication with extended
precision (128-bit mantissa).
> I'm also not sure I know what you mean by control.
> Contributions to dmd would need to be Boost Licensed, which
> means anyone can do what they like with them.
The code is already Boost licensed.
We need not only literals parsing but also library text parsing.
So the code should be available for users and for the compiler. I
see two possible solutions that look good to me.
The first one is to add mir-algorithm package or its part as an
external dependency for DMD. It is preferable and either way. If
you will accept the PR, I will do it.
The second solution is to move `mir.bignum` and `mir.parse` to
DRuntime/Phobos. In this case, I would like to preserve the
`mir.` namespace and the same authority and veto right for this
part of the codebase as I have at Mir Org.
I mean the following. Your voice has a veto right for DMD and
Dlang evaluation. Andrei has a veto right for Phobos. Atila seems
to have almost the same veto right as Andrei and you and blocks
required Dlang features for Mir [1, 2]. Furthermore, if you and
Andrei really want to add or change something you will force it
to happen. I want the same veto right for evaluation of the Mir
parts in case you think they should be moved to DRuntime/Phobos.
Also, the code under `mir.` namespace should be less constrained
then `core`/`std` code in terms of API changes.
More information about the Digitalmars-d-announce