4 ms·

Fair, I was largely riffing off the theme in the post. That is, I took it as an implicit idea that floats represent real numbers. That said, I'd argue that th

by taeric 1y ago

Fair, I was largely riffing off the theme in the post. That is, I took it as an implicit idea that floats represent real numbers. That said, I'd argue that they are neither reals nor rationals. They are scientific numbers with no syntax to indicate "repeated" tails. Would be like saying that you want someone to represent 1/3 using 6 digits with no bar notation. Best you can do is "0.33333" and that just isn't the same. Moving it so that you have 6 digits with 2 being exponent, you are stuck with "3.333e-01". Which is just different still.

perching_aix 1y ago
Yeah, there's a similar comment in another subthread a bit below. The way I like to frame it, and this will almost certainly not be mathematically rigorous, is that every number a float (as in, the formats defined in IEEE-754) can hold can be sufficiently described as at most a rational, though they cannot represent all rationals, and cannot represent anything "higher" than rationals. That's why I prefer to say they're representing rationals. It's in the sense that they're all representing some rational, not any arbitrary rational. To do that would require infinite space. E.g. for one third, you'd need infinite binary digits (or even infinite decimal ones, as you say). It's just not how IEEE-754 floats work, as you mention. This launched me into a research on "perfect numerical accuracy" a while back, and there I did find schemes where you store the numerator and the denominator separately, freeing you from this specific problem. It's a fun topic.
- taeric 1y ago
  Ah, I should have looked at more of the responses. This amusingly blew up on me well after I stopped watching. :D I don't tend to give much thought to real versus rational. Such that I still find it not that surprising to see people treat floats as reals. Especially since most languages make it hard to represent anything else. To that end, it will take me a bit to really internalize what you are saying here. I think I understand it. That said, my favorite for the craziness of "old is new" is that the literal "1/3" works to represent a rational in Common Lisp. Indeed, I had originally thought that they had some specific constants for common fractions defined. Nope, they just support rational literals. And I question if you need infinite space to represent repeated decimals. Strictly, you just need a way to indicate the repeating. No?
  - kazinator 1y ago
    Repeating decimal fractions are just rationals with 9s in the denominator: .123123123... = 123/999. Fourth grade long division.
    - taeric 1y ago
      I'm not sure what you mean? 1/7 repeats, as well. As does 1/14. As do... a lot of fractions. https://projecteuler.net/problem=26 https://projecteuler.net/problem=26 was a fun problem to explore for some that I remember. Pretty sure there were other problems on this general theme, as well. My point was strictly that we have "bar notation" in writing to show that 1.3 is not the same as 1.33 or 1.333 or 4/3. No matter how many 3s you put at the end. I don't know of any similar scheme in computers. I'm assuming it has been tried.
      - kazinator 1y ago
        1/7 is 142857/999999 from which representation you can readily infer that it is 0.142857 with a bar over it. The 9s are verbose but mean the same thing as a bar over as many fractional digits.
        taeric 1y ago
        Ah, I see your point, I think. You are just pointing out that any repeating decimal is a ratio. Which, fair, but my question was if a bar representation was ever tried. The idea being that you don't need to have infinite storage to represent a ratio in positional digits any more than you have to use infinite paper to write a ratio's value out. That is, yes, I know that 1/6 can be used to represent 0.1(6), but if you are already storing something in positional digits, there may have been a benefit to keeping it in positional digits? I'm assuming there was not, in fact, any benefit?
        kazinator 1y ago
        I don't know of a bar representation in a programming or data language. It requires either digit characters that have a bar, or the effect somehow produced via combining characters. Or else a multiline syntax where the coder has to prepare underscores over the digits in the previous line, and this is checked for alignment by the parser. (We could think of other representations like 0.12'34 or something where the '34 indicates repeating digits. I've not seen that anywhere either, but it would be easy to implement.)

by taeric 1y ago

perching_aix 1y ago

Yeah, there's a similar comment in another subthread a bit below. The way I like to frame it, and this will almost certainly not be mathematically rigorous, is that every number a float (as in, the formats defined in IEEE-754) can hold can be sufficiently described as at most a rational, though they cannot represent all rationals, and cannot represent anything "higher" than rationals. That's why I prefer to say they're representing rationals. It's in the sense that they're all representing some rational, not any arbitrary rational. To do that would require infinite space. E.g. for one third, you'd need infinite binary digits (or even infinite decimal ones, as you say). It's just not how IEEE-754 floats work, as you mention. This launched me into a research on "perfect numerical accuracy" a while back, and there I did find schemes where you store the numerator and the denominator separately, freeing you from this specific problem. It's a fun topic.

taeric 1y ago
Ah, I should have looked at more of the responses. This amusingly blew up on me well after I stopped watching. :D I don't tend to give much thought to real versus rational. Such that I still find it not that surprising to see people treat floats as reals. Especially since most languages make it hard to represent anything else. To that end, it will take me a bit to really internalize what you are saying here. I think I understand it. That said, my favorite for the craziness of "old is new" is that the literal "1/3" works to represent a rational in Common Lisp. Indeed, I had originally thought that they had some specific constants for common fractions defined. Nope, they just support rational literals. And I question if you need infinite space to represent repeated decimals. Strictly, you just need a way to indicate the repeating. No?
- kazinator 1y ago
  Repeating decimal fractions are just rationals with 9s in the denominator: .123123123... = 123/999. Fourth grade long division.
  - taeric 1y ago
    I'm not sure what you mean? 1/7 repeats, as well. As does 1/14. As do... a lot of fractions. https://projecteuler.net/problem=26 https://projecteuler.net/problem=26 was a fun problem to explore for some that I remember. Pretty sure there were other problems on this general theme, as well. My point was strictly that we have "bar notation" in writing to show that 1.3 is not the same as 1.33 or 1.333 or 4/3. No matter how many 3s you put at the end. I don't know of any similar scheme in computers. I'm assuming it has been tried.
    - kazinator 1y ago
      1/7 is 142857/999999 from which representation you can readily infer that it is 0.142857 with a bar over it. The 9s are verbose but mean the same thing as a bar over as many fractional digits.
      - taeric 1y ago
        Ah, I see your point, I think. You are just pointing out that any repeating decimal is a ratio. Which, fair, but my question was if a bar representation was ever tried. The idea being that you don't need to have infinite storage to represent a ratio in positional digits any more than you have to use infinite paper to write a ratio's value out. That is, yes, I know that 1/6 can be used to represent 0.1(6), but if you are already storing something in positional digits, there may have been a benefit to keeping it in positional digits? I'm assuming there was not, in fact, any benefit?
        kazinator 1y ago
        I don't know of a bar representation in a programming or data language. It requires either digit characters that have a bar, or the effect somehow produced via combining characters. Or else a multiline syntax where the coder has to prepare underscores over the digits in the previous line, and this is checked for alignment by the parser. (We could think of other representations like 0.12'34 or something where the '34 indicates repeating digits. I've not seen that anywhere either, but it would be easy to implement.)