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