Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Python recompile
Date: Wed, 12 Mar 2025 15:58:56 +0100
Organization: A noiseless patient Spider
Lines: 79
Message-ID: <vqs7fh$2llvo$1@dont-email.me>
References: <vq1qas$j22$1@gallifrey.nk.ca> <vq6j5h$1qosf$1@dont-email.me>
 <20250304092827.708@kylheku.com> <vq7g1p$1vmg5$1@dont-email.me>
 <vq94dt$2boso$1@dont-email.me> <vqcsk7$23bfo$1@paganini.bofh.team>
 <vqefn1$3flpt$1@dont-email.me> <vqeu5c$3imil$1@dont-email.me>
 <vqeun4$3iqbq$1@dont-email.me> <vqfcbe$3lkkc$1@dont-email.me>
 <871pv861ht.fsf@nosuchdomain.example.com> <20250308192940.00001351@yahoo.com>
 <vqi1ge$8jg8$1@dont-email.me> <vqmgjv$3a2il$1@paganini.bofh.team>
 <vqn4dn$1eb9s$1@dont-email.me> <vqo3ss$3hkas$1@paganini.bofh.team>
 <vqph2e$203bs$2@dont-email.me> <vqpjh7$210q9$1@dont-email.me>
 <vqpo1s$222s0$1@dont-email.me> <vqpqo6$23197$1@dont-email.me>
 <vqpsvc$23gc1$1@dont-email.me> <vqq5um$25dm2$1@dont-email.me>
 <vqq9ba$267fp$1@dont-email.me> <vqro58$2i773$2@dont-email.me>
 <vqrqa1$2itot$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 12 Mar 2025 15:58:59 +0100 (CET)
Injection-Info: dont-email.me; posting-host="b77a589918dd21d1d2954354f63497b4";
	logging-data="2807800"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18J1DGanKwtwGL3zsqhs6kkS5CkiAHewrc="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:e35ceAfqS2dFVvG99h7LrUm6i6M=
Content-Language: en-GB
In-Reply-To: <vqrqa1$2itot$1@dont-email.me>
Bytes: 5697

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?)



> 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.