Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: David Brown 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: References: <20250304092827.708@kylheku.com> <871pv861ht.fsf@nosuchdomain.example.com> <20250308192940.00001351@yahoo.com> 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: 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.