Re: Python recompile

On 12/03/2025 14:58, David Brown 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.   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?)

It might be code like this where the top bits of left-shifts disappear:
   z = ((Q[i]<<41)>>1)+((Q[i]<<39)>>1)+(carry>>1);

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.

I see. So the real reason for your apparently friendly interest comes to light. It is just to trash everything I do and to be as condescending as hell.