home bbs files messages ]

Just a sample of the Echomail archive

COMPLANC:

<< oldest | < older | list | newer > | newest >> ]

 Message 242,272 of 243,097 
 bart to Janis Papanagnou 
 Re: _BitInt(N) 
 30 Nov 25 17:55:38 
 
From: bc@freeuk.com

On 30/11/2025 17:17, Janis Papanagnou wrote:
> On 2025-11-30 13:51:22, bart wrote:

>> How did you represent an 80-bit type up to now? How much of a problem
>> has it actually been?
>
> I had to use workarounds and/or more effort to achieve what I intended.
> For the implementation I have to think in terms of technical entities
> unnecessarily, and not in [more natural] application domain entities.

How much storage did your type take up in the end?

Because if you expect it to occupy only 10 bytes, you might be
disappointed with _BitInts:

     _BitInt(80) A;
     _BitInt(80) B[10];

     printf("%zu\n", sizeof(A));
     printf("%zu\n", sizeof(B));

This shows 16 bytes for A (the same as for _BitInt(128)), and 160 bytes
for B.

So here need to ask questions about why you need 80 bits and not 128.

>> Which domain is that, is it representing, as an integer, the 80-bit
>> float type from an x87 FPU?
>
> That was an arbitrary number.

An arbitrary number that can represents values up to some exact power of
two.


> (Other posters provided extensive lists
> of other numbers already, based on application domain requirements.)

I've also given examples where the desire is to store numbers up to some
arbitrary value that is not of the form 2**N-1. It is also possible
numbers are in some arbitrary range that does not start at 2**N or 0 for
signed/unsigned.

BitInt won't help here.


> I could provide even more "crude" numbers, say, like _BitInt(17), to
> operate on coefficients of generator polynomials, just for example.
> The point is not to discuss any specific number. - The point is that
> they are bound to the application domain and express a sensible (not
> artificial, defined by technical CPU word-sizes) counterpart of the
> [application domain] items you work on.
>
> Programming is about implementing solutions to application problems.
> It's not primarily about focusing how the hardware looks like.

BitInt is still hardware-based (what do you think a 'bit' is?!).

And implementations appear to have hardware-based limits and compromises.
> The fact that you obviously don't see that, and also don't understand
> it after pointing that out, in addition with your squirming to *not*
> *answer* the repeatedly formulated question what your actual problem
> with it is,


I've said many times that it's a poorly designed feature. Read the
thread, as I'm not going to repeat things.




>> Yet over the past decades nobody has been screaming because they
>> couldn't have a 31-bit or 65-bit numeric type. But now suddenly
>> EVERYONE wants to be able to do that, and on huge numbers!
>
> You are again talking nonsense and exposing your non-sincere moves
> to stupidly exaggerate ("screaming") and unreasonable generalize
> ("EVERYONE"). - Yet, you prove again that you are not willing to
> be a serious discussion partner.

Yet what I said is pretty much true. Nobody care about BitInt until they
became aware of, and now it's must-have.

--- SoupGate-Win32 v1.05
 * Origin: you cannot sedate... all the things you hate (1:229/2)

<< oldest | < older | list | newer > | newest >> ]


(c) 1994,  bbs@darkrealms.ca