Numbers TS scope and priorities

[apolukhin]

We need a short sentence that describes the Numbers TS and a prioritized list of goals.

My best attempt Scope: "User friendly numeric types, aliases and low level building blocks to implement them"

Goals:

1. Provide integral types that are widely useful and exist in other programming languages: a. integer - an unbounded integer type b. wide_integer - a non allocating integer of a compile time specified size c. elastic_integer - never overflowing integer that at compile-time generalize promotion rules d. safe_integer ???
2. Provide non-integral types that are widely useful and exist in other programming languages: a. rational - allocating? rational number representation b. decimal ??? c. unbounded float ???
3. Provide basic building blocks for overflow detection
4. Provide arithmetic operations for each numeric type
5. Provide basic locale-unaware string <> numeric conversions
6. Provide arithmetic operations for interaction of different numeric types

What we are NOT planning to provide:

• iosteams for numeric types
• trigonometric functions
• description of the storage format for numeric type
• ???

@ZaMaZaN4iK @johnmcfarlane @Lawrence-Crowl please tell what do you think about the goals and scope?

[zamazan4ik]

@apolukhin I think it's quite good attempt :) . FMPOV safe_integer shall be included too.

I thought that rational and unbounded float are the same things...

By the way for every class, which we want to introduce, we shall have very good explanation/motivation, why we want to add it into the Standard. Feedback from people who has large experience with unbounded arithmetic IRL will be great to see here.

Also I think we want to add some interactions with std::format and/or iostreams because it's very strange that we can calculate something and cannot show it :)

[zamazan4ik]

The most important point from me: we should look on another examples of unbounded arithmetic in another languages: Java (has BigInt class in JDK), C#, Rust (has no standard classes for unbounded arithmetic, but has some crates (packages) for this), etc.

FMPOV C# variant is good point to start.

[johnmcfarlane]

• IO is beyond the scope of the TS. That is guidance from LEWG-I.
• rational is quite different from unbounded float which has no paper.
• Python3's fundamental integer might be a good inspiration for unbounded integer.
• safe_integer (as I see it) is a combination of overflow_integer<elastic_integer<Digits>>. overflow_integer is a much simpler type which genuinely provides a drop-in replacement for native integer.

One other thing I should mention, following the Numerics TS discussion in LEWG-I in Cologne, I don't know that it's all that important to have the number of bits or the number of digits in the interface to wide_integer. Places where this is going to be used as a component -- very often elastic_integer -- are likely to use families of types where a family is a metafunction which returns a type, given a width.

[apolukhin]

BTW, we also have to make some schedule with the following deadlines

• time0 - ok to add/remove major features and numeric types <-we are here
• time1 - no new numeric types are allowed for merge to the TS
• time2 - new functionality could be added to the TS only by the LEWG request
• time3 - wording fixes only (LWG)

And time1 should happen very soon. Probably after the next meeting.

IO is out of scope, that's true. But we should provide some basic conversions. We still have to decide which ones.

Bits/bytes/words/digits is a neverending discussion for wide_int. LEWG requested bits, so we have bits in the TS. That decision could be changed, to do that new information should be provided in a form of a proposal.

[johnmcfarlane]

I recall Davis' push for numeric families in LEWG-I's affected this decision. My takeaway from that is to turn P0554 into a proposal for addition of the fixed-width to the library. (Let's just call it a library for now.) So perhaps I'll propose an alternative to wide_integer in that -- possibly in the form of a multiword_integer which theoretically underlies wide_integer.

[apolukhin]

I've failed to find any notes on acceptance of decimal and elastic_integer into the Numbers.

@johnmcfarlane, @Lawrence-Crowl is there any info on those types or we have to revise their acceptance in SG6?

[johnmcfarlane]

Can you clarify what you mean by acceptance into Numbers?

On Thu, 28 Nov 2019 at 12:44, Antony Polukhin notifications@github.com wrote:

I've failed to find any notes on acceptance of decimal and elastic_integer into the Numbers.

@johnmcfarlane https://github.com/johnmcfarlane, @Lawrence-Crowl https://github.com/Lawrence-Crowl is there any info on those types or we have to revise their acceptance in SG6?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ZaMaZaN4iK/numeric-papers-in-latex/issues/9?email_source=notifications&email_token=AAFTGN4O6NPKV7N275CAVHTQV64LZA5CNFSM4JNQDQYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFMQBNY#issuecomment-559481015, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFTGN6KCV7FG3JULGFCNKDQV64LZANCNFSM4JNQDQYA .

[apolukhin]

Can you clarify what you mean by acceptance into Numbers?

In http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0101r0.html decimal was listed, but the wiki has no track of its fate for the Numbers. If at the meeting everyone agreed to include it in Numbers, then we can just embed it into P1889 as an editorial change. If there were objections and they were addressed or if no one remembers the decision - we have to write a paepr "Consider including decimal into P1889".

Same story with elastic_integer. We can embed it right now if SG6 is OK with that, or we need a paper "Consider including elastic_integer into P1889".

[johnmcfarlane]

In P0101, I see decimal floating-point and mention of decimal fixed-point. Do you mean decimal floating-point, i.e. N3871? I've not worked on that. I have proposed decimal fixed-point in P0037 but that wasn't mentioned in P0101 and doesn't use the identifier decimal.

I don't recall the name 'Numbers' being used before Belfast so I doubt you'll find any minutes where elastic_integer was commended to it. I've also not asked for votes on adding my numeric types to a numerics TS because that entity also did not exist.

Perhaps it would help if there was an explanation of how the existing content of P1889 qualified. If I could read the minutes/votes leading to those decisions, it might help me know what to look for.

[apolukhin]

I've tried to add some explanations on P1889 and scopes/goals in this draft paper https://apolukhin.github.io/papers/numbers_scopes.html

Any comments or suggestions are welcomed!

I'll also add more explanations directly into the P1889 soon.

[johnmcfarlane]

Thanks. This paper explains why P0101 is in. It doesn't explain why wide_integer is in, nor why elastic_integer or fixed_point are out. Does the synopsis need to be closer to final wording? Is there some additional committee criteria beyond making it to LEWG? I've revised P0037 seven times already. I really need to know what I'm missing before devoting time to iterating on these proposals further. (I also have some family matters that will occupy a lot of my time over the next 3-6 months so my time is more limited than before.)

[apolukhin]

We started P1889 because if wide_integer. All the discussions of that paper were ending by a phrase that it should progress as a part on Numbers TS. Because the Numbers TS was not created and was not progressing fast, we made the P1889. We put there the papers approved via P0101 and wide_integer.

Unfortunately, I can not find in notes about Numbers TS in wide_integer discussions. I should double check that SG6 still wants it as a part of Numbers TS P1889.

This leads me to another idea. Probably SG6 does not want to have a TS any more, so we can progress individual papers without waiting for all of them to be ready. I'll ask the above question in https://apolukhin.github.io/papers/numbers_scopes.html