Planning Ahead for BigNum INTEGER!

[hostilefork]

That's a series, which presumably have an allocation, which lets you do that. How would you do it with a 32-bit or 64-bit number?

So for the example to apply to integers, then it comes back to your question:

@drkameleon

So, if the most likely scenario is using smaller (32- or 64-bit) integers, why not stick to that as the "default" type and switch internally to GMP big ints when needed?

You wouldn't wait because the GMP offers you the allocation of an identity for the number.

(Though my intent is using mbedTLS BigNums, for smaller code size and because it's what our encryption already uses.)

[iArnold]

Right,

@drkameleon

Well, bignum support sounds to me like an absolute must.

And given that GMP is already there, with thousands of hours invested in the project, why reinvent the wheel?

That is correct, and the way to handle stuff. But there is a dependency issue with this.

@drkameleon

Python's approach - everything being a bignum - seems like a total overkill to me.

Let me put it this way: what are the chances that you will be constantly using bignums, with all the overhead that it brings?

Completely agree on this too. As I said, most of the integers one encounters are staying well within the limit of the given bits.

@hostilefork

(Though my intent is using mbedTLS BigNums, for smaller code size and because it's what our encryption already uses.)

Right. For things as MySQL support, I only need this for my webdevelopment, talking to the MySQL database my provider hosts for me. So I need to install the MySQL (or MariaDB) libs for that case only. But when I want BIGNUM's, I want this available in a general sense. Having a dependency on GMP makes everybody that want to use it have a copy of the gmp library used, and if you want to compile the newest Ren-C you will need the gmp source library as well. So we get yet another dependency on the other project. Everybody in Ren-C world will need one, and to be able to debug and help each other we need the SAME version of the sources used. Then we are also depending on the GMP project not to introduce bugs in the latest versions...

The dependency on the AGG library (or for that matter any other GUI library) for R2 has a similar problem making the open sourcing of Rebol back in the day an extra problem, where R2 closed source could just use the AGG library of choice and ship with that built-in.
I call this for myself the "moving target problem", knowing that this project is also a moving target.
I also now have 96 libgmp.so libs on my system.