From: Christopher Di Bella Sent: Sunday, March 26, 2017 7:42 AM To: ISO C++ Standard - Future Proposals Reply To: std-pr...@isocpp.org Cc: Casey Carter; Eric Niebler Subject: [std-proposals] Number Concept Family |
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/49308661-71b7-f4a1-b2b2-d5320f6b5372%40wanadoo.fr.
> Why char types are not considered as Numbers? isn't int8_t a Number?int8_t is a signed integral; it should be a signed char^, which is a distinct type from char. char is not a Number, it is a character type that is also an arithmetic type, but signed char is a Number. Number is not intended to be a super-set of arithmetic types.^It's strictly implementation-defined, but I don't think it can be a char either way?
> why do you associate pre-increments and post-increment to an ordered number?
Poor naming decisions. The other name that I came up with for OrderedNumber was StrictNumber, but I preferred OrderedNumber, since I couldn't think of any non-ordered numbers that can be incremented, and communicates the strict ordering imposed. Something like s/Number/WeakNumber/ s/OrderedNumber/Number/ is desirable, but "WeakNumber" needs some justification I can't provide.
> Why char types are not considered as Numbers? isn't int8_t a Number?
int8_t is a signed integral; it should be a signed char^, which is a distinct type from char. char is not a Number, it is a character type that is also an arithmetic type, but signed char is a Number. Number is not intended to be a super-set of arithmetic types.
^It's strictly implementation-defined, but I don't think it can be a char either way?
> I don't see the operator% on you clasification
operator% is a tricky one: floating-point numbers don't support operator%. Does it make sense to use operator% on a some type that isn't an integer? If so, it would be a good addition for RegularNumber/FieldNumber, but I think there should be a general group of numbers that we can use operator% on.
> Where numeric types that double the range under addition and multiplication> T + T -> D(T) // D(T) means a type that double the range of T
> T * T -> D(T)
> will fall on this clasification?
I am not sure I understand this one. Can you provide a concrete example, please?
Le 26/03/2017 à 22:05, Christopher Di Bella a écrit :
It is weird to have += on a type and don't have increment.
> why do you associate pre-increments and post-increment to an ordered number?
Poor naming decisions. The other name that I came up with for OrderedNumber was StrictNumber, but I preferred OrderedNumber, since I couldn't think of any non-ordered numbers that can be incremented, and communicates the strict ordering imposed. Something like s/Number/WeakNumber/ s/OrderedNumber/Number/ is desirable, but "WeakNumber" needs some justification I can't provide.
Le 26/03/2017 à 22:05, Christopher Di Bella a écrit :
So we couldn't have an unsigned Number of 8 bits, at least not a builtin one :(
After a deep reading you add
{-cn} -> N;
So you are considering only number with closed arithmetic.
cardinal (as proposed in n3352) is not closed for the - operation.
-cardinal -> integral
cardinal - cardinal -> integral
C++ Binary Fixed-Point Arithmetic http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html
an so it couldn't be a Number
On Sun, Mar 26, 2017 at 5:37 PM, Vicente J. Botet Escriba <vicent...@wanadoo.fr> wrote:
Le 26/03/2017 à 22:05, Christopher Di Bella a écrit :
It is weird to have += on a type and don't have increment.
> why do you associate pre-increments and post-increment to an ordered number?
Poor naming decisions. The other name that I came up with for OrderedNumber was StrictNumber, but I preferred OrderedNumber, since I couldn't think of any non-ordered numbers that can be incremented, and communicates the strict ordering imposed. Something like s/Number/WeakNumber/ s/OrderedNumber/Number/ is desirable, but "WeakNumber" needs some justification I can't provide.
It is weird.
And it depends how "mathy" we want to get. When I see OrderedNumber, I think "ordinal". ie 1st 2nd 3rd instead of 1 2 3.
An ordinal would/should have a ++ ("successor") and += would be like std::advance(). But it wouldn't be operator+=(Ordinal ord), it would be operator+=(int amount) - ie give me the 5th ordinal after this one.
ie if doubles were Ordinals ++ would/should give you the _next_ double. Just like an iterator does.
I'm not saying we want Ordinals; I'm saying we need to think carefully.
On Sun, Mar 26, 2017 at 2:37 PM Vicente J. Botet Escriba <vicent...@wanadoo.fr> wrote:
Le 26/03/2017 à 22:05, Christopher Di Bella a écrit :
...
So we couldn't have an unsigned Number of 8 bits, at least not a builtin one :(
After a deep reading you add
{-cn} -> N;
So you are considering only number with closed arithmetic.
cardinal (as proposed in n3352) is not closed for the - operation.
-cardinal -> integral
cardinal - cardinal -> integral
C++ Binary Fixed-Point Arithmetic http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html
an so it couldn't be a Number
This is certainly an interesting paper, but Number etc. seem to be on the exclusive side. I've no idea whether this is a good idea or not.
It's not just many of the types being considered for a Numerics TS which would fail Number. Consider dimensional analysis types such as those in Boost.Units. Returning novel types is very useful but is commonly overlooked.
Also, Number seems to exclude integers shorter than `int` because it expects results of binary arithmetic to be `common_type_t` whereas the result of some integer arithmetic operations is promoted to `int`.
Perhaps what are being described here are types which can replace fundamental scalar types under certain circumstances. For instance, compositional types such as `std::chrono::duration` might be instantiated on a type which supports some arithmetic operators but not others. The resultant type will be similarly limited but still correct and "numbery". It might be useful to say that `duration<Rep>` is a Number iff `Rep` is also a Number.
Could there be a concept for types which do not wrap around on overflow? When you add 1 to a signed type, it should always be greater. That's a very valuable property which does not extend to unsigned types.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/96c8303e-2f0b-4658-9e4d-3baa0773c921%40isocpp.org.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
Lots of great feedback so far :)I apologise if I miss your contributions: I've got a lot to work with. Please don't be shy to raise a point twice.
> No. It's required to be a "signed integer type", which plain char isn't regardless of representation
Thanks for the clarification :)
> So we couldn't have an unsigned Number of 8 bits, at least not a builtin one :(
Both signed char and unsigned char are permitted, which means that int8_t and uint8_t are allowed :)
> And it depends how "mathy" we want to get. When I see OrderedNumber, I think "ordinal". ie 1st 2nd 3rd instead of 1 2 3.
>> An ordinal would/should have a ++ ("successor") and += would be like std::advance(). But it wouldn't be operator+=(Ordinal ord), it would be operator+=(int amount) - ie give me the 5th ordinal after this one.
>> ie if doubles were Ordinals ++ would/should give you the _next_ double. Just like an iterator does.
>> I'm not saying we want Ordinals; I'm saying we need to think carefully.
I'm fielding a name new name for Number:
s/Number/BasicNumber/s/OrderedNumber/Number/
Thoughts? Until I get some feedback on this, Number still refers to the base concept.
Ordinals haven't been considered at all.
> It is weird to have += on a type and don't have increment.> It is weird.
I thought so too, but types such as complex don't support operator++, etc.,
which is why I moved it, along with StrictTotallyOrdered out of Number. I think the trick here is to work out what a "Number" really should be, and not to let types such as complex or N3352's cardinal dictate the requirements.
> I'm not an expert, but I believe that it has a sens only for integer numbers. I was wondering just why this operation is not considered in your classification, while you consider bitwise operations.
This is a good point: it's the only mathematical operator missing, but I can't think of a good way to include it. Definitely open to suggestions.
> I was thinking of safe numbers
>
> safe<short> * safe<short> -> safe<int>
>
> or fixed point numbers (as proposed by L. Crowl in n3352).
>
> or bounded::integer ( http://doublewise.net/c++/bounded/)
>
> Which kind of Numbers would be those?
> As an exercise, one might try to apply the "Number Concept" to the> variety of "numbers" we've already been working with in our real code.
> I think the utility would be limited.
I'm currently working with bounded::integer and the Boost-proposed safe<int>. I've also emailed Lawrence to find out if there's a prototype for N3352, so I can toy with that.I'll look for some other numbers to toy with and report back. The critical key here is to produce real-world examples, not just contrived examples.
> Could there be a concept for types which do not wrap around on overflow? When you add 1 to a signed type, it should always be greater. That's a very valuable property which does not extend to unsigned types.
Only if we can syntactically assert this, but this feels like a property of a concept, rather than a concept itself. I'd need to see more to be convinced either way, but I am definitely erring on the side of property.
> It's not just many of the types being considered for a Numerics TS which would fail Number. Consider dimensional analysis types such as those in Boost.Units. Returning novel types is very useful but is commonly overlooked.> Perhaps what are being described here are types which can replace fundamental scalar types under certain circumstances.
> This is certainly an interesting paper, but Number etc. seem to be on
> the exclusive side. I've no idea whether this is a good idea or not.
> I'm in agreement with this sentiment. I'm not really understanding what
> this would be used for and why it would be helpful. We use the word
> "Number" (and by implication the concept of "Number") in a variety of
> ways which sometimes from conflict.
I will confess that the only types that I've considered are fundamentals and types that mimic fundamentals. It never even occurred to me that there might be other ways to represent a number. The implicit motivation (based off my actions, not words) is for an algorithm or type to be allowed to accept any type that can be used like an integer or floating-point and use it as such. I'm not even sure I consciously was aware of this while writing. This will likely go back to the case study suggested above.
> BTW, for Regular Numbers I will request N{1} and require the identity axioms for +,N{0} and *,N{1}.
N{1} would be the same as N{0}, since it's constructing N from an int-literal. How would this be semantically different to N{0}?I do like where you're going with these though, so if there's an number-r2.pdf, they'll be in there as textual semantic requirements.
>> Also, Number seems to exclude integers shorter than `int` because it expects results of binary arithmetic to be `common_type_t` whereas the result of some integer arithmetic operations is promoted to `int`.
> Right. builtin short is already in line with my example
> short + short => int
Hmm... I wasn't aware of this, but Number<T, U> is definitely valid for all fundamentals T and U, at least on GCC. Won't know anything else until Clang or MSVC implement Concepts too. This failing would be a non-starter/staller.
> No. duration<Rep, Period> would fall on the 1-dimensinal quantity. The operations are not the same as those of a Number. Note that some of the operations, e.g. *,/ and % can > take a Regular Number on the rhs parameter. However, the Rep parameter must be a Regular Number.
I think that's what John means:template <RegularNumber Rep, typename Period>class duration;
That's definitely something I'd like to see it used for.
> I would characterise this idea of one of "premature conceptualization"
Possibly!
I believe that what Robert means is that we should conceptualize the parameters of generic functions. We should start by the generic algorithms.
While the Range Ts has some numeric types, I don't think there is
enough material there for this classification.
This should be part of the Numeric library.
std::duration<R,P> could be used to see what is required from R.
Note that duration<R,P> behaves quite differently depending
on the trait treat_as_floating_point<R>. I see this as a
union of concepts.
Vicente
I'm currently working with bounded::integer and the Boost-proposed safe<int>. I've also emailed Lawrence to find out if there's a prototype for N3352, so I can toy with that.I'll look for some other numbers to toy with and report back. The critical key here is to produce real-world examples, not just contrived examples.