3 ms·

I didn't want to imply that this can't be the case for typical encodings. However, it's rarely the default and is sometimes handled differently than normal numb

• taeric 2y ago
  Apologies if I took more of an implication than you meant. I do not argue that most programming languages stick with numeric types that are specifically limited in size. Feels like that is a mechanical choice, though? Not an encoding one. As evidence by the fact that different machines have different limits based on the physical size of the adders on them. I should also say this was a really fun read!
  • marvinborner 2y ago
    In general I think you're right. With the correct encoding, it's just a mechanical limit. It just depends on the specific encoding you use. GMP, I believe, is only limited by the physical memory size. Python's implementation is also limited by the encoding (not sure how it works concretely, but it doesn't seem to be a memory overflow): x = 1 while True: x <<= x > OverflowError: too many digits in integer
    • taeric 2y ago
      Right, my argument is that the smaller int/float/etc. types are also mechanically limited in size. And at least for most languages, the size limit has somewhat intuitive upper size limits. JavaScript has the odd case where larger numbers start skipping in different ways. (If my memory is accurate, at least.)
      • marvinborner 2y ago
        > With the correct encoding, it's just a mechanical limit This also applies to small numbers and small mechanical limits. Of course, here the small limits come with the nice side effect of efficiency :)