Date: Thu, 24 Apr 2025 11:18:16 +0200
I have made such a type “natural”, multiprecision unsigned, where one can check the difference. Typically, multiprecision integers are implemented as unsigned with a separate sign, and on top of that, types for rational numbers and bignum floating-point. (Haskell has always had bignum “integer” and “rational” types.)
My type “natural” has an extra word at the bottom, in effect becoming a std::vector that is always nonempty. (Unlike your example, where it is at the top.)
For arithmetic that does not overflow, it gives a speedup of a couple of times relative only using std::vector. It is also pleasing that it is never empty, with at least one word.
One could gain several times additional speedup if one can avoid conditionals altogether in arithmetic that does not overflow, instead using CPU traps that can switch to bignum computations at need.
Then one must check for each argument if it is already in bignum format. So it does not suffice with checking for overflows.
One way would be to mark the low word with, say, unsigned -1, and set a trap for that; that is, if adding x+y, there should be a trap not only when it overflows, but if one of x or y is -1. Is that possible in CPUs?
Also, in your proposal, you might add the carry to the multiplication function, as it is how it is used when implementing bignums, and it is good to avoid an extra function call on this low level. That is:
template<class A>
std::tuple<A, bool> mul(A a0, A a1, A carry = 0)
> On 5 Apr 2025, at 16:42, Tiago Freire <tmiguelf_at_[hidden]> wrote:
>
> Hi Hans,
> I think I'm starting to understand what you mean.
> My proposal does not introduce Big Number abstraction, although it is part of the motivation.
> One of the challenges to be able to create such type of abstractions is the lack of support in the language for arithmetic operations that preserve information when basic types would overflow. And although they have been staple in CPU design since as far as I’ve ever known CPUs, there is almost no way to access them in C++ other than “write your own assembly”, and there is no portal way to do it.
> The application of such arithmetic types goes beyond big number representations.
My type “natural” has an extra word at the bottom, in effect becoming a std::vector that is always nonempty. (Unlike your example, where it is at the top.)
For arithmetic that does not overflow, it gives a speedup of a couple of times relative only using std::vector. It is also pleasing that it is never empty, with at least one word.
One could gain several times additional speedup if one can avoid conditionals altogether in arithmetic that does not overflow, instead using CPU traps that can switch to bignum computations at need.
Then one must check for each argument if it is already in bignum format. So it does not suffice with checking for overflows.
One way would be to mark the low word with, say, unsigned -1, and set a trap for that; that is, if adding x+y, there should be a trap not only when it overflows, but if one of x or y is -1. Is that possible in CPUs?
Also, in your proposal, you might add the carry to the multiplication function, as it is how it is used when implementing bignums, and it is good to avoid an extra function call on this low level. That is:
template<class A>
std::tuple<A, bool> mul(A a0, A a1, A carry = 0)
> On 5 Apr 2025, at 16:42, Tiago Freire <tmiguelf_at_[hidden]> wrote:
>
> Hi Hans,
> I think I'm starting to understand what you mean.
> My proposal does not introduce Big Number abstraction, although it is part of the motivation.
> One of the challenges to be able to create such type of abstractions is the lack of support in the language for arithmetic operations that preserve information when basic types would overflow. And although they have been staple in CPU design since as far as I’ve ever known CPUs, there is almost no way to access them in C++ other than “write your own assembly”, and there is no portal way to do it.
> The application of such arithmetic types goes beyond big number representations.
Received on 2025-04-24 09:18:32