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 17:55:40 +0100
Organization: A noiseless patient Spider
Lines: 89
Message-ID: <vqseac$2mp5t$2@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> <vqs7fh$2llvo$1@dont-email.me>
 <vqs9dt$2ltal$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 17:55:40 +0100 (CET)
Injection-Info: dont-email.me; posting-host="b77a589918dd21d1d2954354f63497b4";
	logging-data="2843837"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/rHYLJz7rw8INDTA/rB556nZvDaLFOwuo="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:yhUL3uQkgbjglMGtiXNaEGRORyc=
In-Reply-To: <vqs9dt$2ltal$1@dont-email.me>
Content-Language: en-GB
Bytes: 6061

On 12/03/2025 16:32, bart wrote:
> 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);
> 

Okay... and how often would this cause trouble for Python code?  And why 
is it specific for 64 bits?

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

I am merely trying to understand you (as well as helping you - providing 
links to the dlls you could not find yourself).

I fully understand the fun of making your own bignum code - or of adding 
bignum support to your interpreted language.  I do not understand the 
effort you go to complaining, blaming others, and making your own life 
more difficult.  I do not understand any thoughts that this is somehow a 
useful expenditure of time and effort.