3 ms·

I'm a little confused on the callout that the lambda encodings for numbers are infinitely precise? Is that not the case for typical encodings? Our typical "pr

by taeric 2y ago

I'm a little confused on the callout that the lambda encodings for numbers are infinitely precise? Is that not the case for typical encodings? Our typical "primitive" data types are size bound, but that is a practical choice, not a required one of the encoding scheme? (This is a genuine question. I'm assuming I am misunderstanding something.)

shiandow 2y ago
Practical or not most default integer types do not support arbitrarily large numbers
- taeric 2y ago
  But they do? You will have to do some code to make it work well, obviously; but almost certainly not as much as is in this? To the specific point, though, it isn't the encoding that limits the precision. It is limiting the size of the encoding that limits the precision.
marvinborner 2y ago
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 numbers (e.g. Haskell's Integer vs Int). Compare this to lambda calculus, where restricting the size of numbers would be the difficult task.
- 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 :)

by taeric 2y ago

shiandow 2y ago

Practical or not most default integer types do not support arbitrarily large numbers

taeric 2y ago
But they do? You will have to do some code to make it work well, obviously; but almost certainly not as much as is in this? To the specific point, though, it isn't the encoding that limits the precision. It is limiting the size of the encoding that limits the precision.

marvinborner 2y ago

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 numbers (e.g. Haskell's Integer vs Int). Compare this to lambda calculus, where restricting the size of numbers would be the difficult task.

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 :)