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)