Re: Python recompile

On Wed, 12 Mar 2025 15:58:56 +0100
David Brown <david.brown@hesbynett.no> wrote:

On 12/03/2025 12:14, bart wrote:

On 12/03/2025 10:37, David Brown wrote: 

On 11/03/2025 22:18, bart wrote: 

 

I needed support for big numbers in my interpreter. My product is
well-integrated, and represents 5% of the 250KB interpreter size.
The above gmp DLL is 666KB so is a poor match.
 

>
Out of curiosity - how often are such big numbers needed and used
with your interpreter, excluding demos to show how to use big
numbers? 64-bit arithmetic is enough for the huge majority of
purposes outside of cryptography and mathematics, and 128-bit
arithmetic covers almost all of the rest.  Your code is not
suitable for cryptography or mathematics.   So what is it used
for?  And could it have been handled much more simply by using
128-bit fixed sizes?

 
How often are big numbers used in Python? There, its integer type
transparently overflows into a big integer when needed (so C-style
algorithms that rely on being masked to 64 bits won't work).
 

 
I'd imagine they are not often used, as a proportion of Python users,
and that 128-bit integers would be more than good enough in most
situations.  However, Python /is/ used in mathematics work, and big
numbers are useful there.  And Python numbers are, like everything in
Python, objects - each number is already a memory allocation, a
struct, a reference to a shared object.  There's a lot of overhead
even for a simple integer.  That means there is little extra cost for
having the possibility of big numbers if the user wants them.
Similarly, the rest of Python is so large that the incremental cost
for using shared GMP libraries (which are likely already installed on
many systems) is minor.

Default Python integer is not GMP. GMP can be used from Python and
doing it is much easier than using GMP from C, but it is not transparent
to programmer.
We discussed it relatively recently on comp.lang.c++. See Message-ID:
<20241223174708.000062b3@yahoo.com> and following short sub-thread.

And of course Python is used by millions -
including people who regularly need large integers.  Your interpreter
is used by you.
 
So again, how often do /you/ need big numbers in /your/ language?
 
 
(I'm not sure what you are talking about with "C-style algorithms
that rely on being masked to 64-bits".  Are you suggesting that if
badly written C code is translated directly into bad Python code, it
might not work?)
 

Huh?
In C default modulo arithmetic on unsigned numbers is 100% standard and
is used in plenty of well-written C code.

 
 

In my language you have to explicitly request the bignum type. It
is used mainly for recreational code. Or sometimes to get accurate
reference results to compare against when working with 64-bit ints
and floats.
 
(How big is a 128-bit range for example? I can just do 'print
2L**128'.)
 
I did have 128-bit support in my implementation language once,
better than gcc's in C since it also supported literals, and Print.
I did think about using that instead of, or as well as, bignums.
Maybe as the default int type instead of 64 bits.
 
But, as you say, real needs beyond 64 bits are rare. When it is
needed, then they can be arbitrary large (forget 2**128, what about
2**1000000? Or you want to look at Fibonacci numbers beyond fib(92)
which is the limit with int64).
 
In the end I dropped 128-bit numbers, because the only use-case,
apart from bragging about it, was supporting 128 bits in the
self-hosted compiler. 

 
Whereas in your interpreted language, the only reason for having
anything bigger than 64-bits seems to be for bragging about it.  If
you think that is worth the effort, that's fine - I've nothing
against doing something like this for the fun of it.  But it seems
strange to get so worked up about how the GMP authors are forcing you
to use dependencies you don't want, and forcing you to write your own
bignum code, when all you really want is to be able to tell your
users - you alone - that you support bignums so that you can
calculate 2 ^ 128 and fib(92).  It's a lot of effort, and a lot of
aggravation, for extremely little use.
 

As already said by Bart, it is a bit of fun.
To me it sounds like sufficient reason.