6 ms·

Nice or not, pretending that double precision floats and arbitrary precision integers can be stacked as a tower is foolish. There are floats that can't be repr

by xscott 2y ago

Nice or not, pretending that double precision floats and arbitrary precision integers can be stacked as a tower is foolish. There are floats that can't be represented as integers, and integers which can't be represented as floats. This is where you say something about "exact" vs "inexact" as though that will hand wave it away.

em-bee 2y ago
that's not what pike is doing though. int and float are still kept separate. btw, i just checked, typeof() no longer shows the difference between int and bigint. it did in the past if i remember correctly
- xscott 2y ago
  You gotta read between the lines with the commenter above. Their name is a reference to "Smug Lisp Weeny", and they're part of the religion (cult) that thinks everything in Lisp (usually Common Lisp) is perfect. He couldn't care less about Pike, except as an excuse to be smug about Lisp.
  - anonzzzies 2y ago
    Besides his nick, was he smug? He just noted that Lisp(likes) solve this problem for some version of 'solve' with the numerical tower. The implementations don't (usually; I am not aware of any) mix exact and inexact as that would be foolish obviously.
    - xscott 2y ago
      > Besides his nick, was he smug? Saying, "That's nice." is a cliche condescension. You're free to disagree, but I think his intent was clear.
      - anonzzzies 2y ago
        Ah, I did not read that into it. But guess that might be what he was doing.
Dylan16807 2y ago
> This is where you say something about "exact" vs "inexact" as though that will hand wave it away. I'm not familiar with this debate, but how is that a hand wave? The article describes a reasonable-sounding way to extend the tower with a second dimension of precision. Following those rules, you would never just convert between bigint and float, but an expression involving both would output a float.
- xscott 2y ago
  It's a rule, and it behaves like people probably expect for small numbers. But following that rule: float(0.5) + bigint(9007199254740993) == float(9007199254740992) I wouldn't parade it around as a triumph over the problem, and it's arguably better to require people to be explicit about whether converting the float to bigint, or the bigint to float, is what you wanted.
  - Dylan16807 2y ago
    That doesn't really strike me as worse than any other use of == on a float. If anything needs to change there, I think it's more rigor in float comparisons. Basically, ULP-level inaccuracy is a problem inherent to having float at all, even without bignum interactions. They would be a menace even if you had a pure tower from 32 bit int to double to complex to more.
    - xscott 2y ago
      I wasn't trying to draw attention to comparisons for equality. Perhaps I should've used an arrow => instead of == to indicate "the result of this operation", but that probably would've caused confusion too... The real point is that you can get some non-intuitive answers from letting that numeric tower make conversion decisions for you. It's just a rule, and it's not an amazing rule.
      - Dylan16807 2y ago
        > I wasn't trying to draw attention to comparisons for equality. Perhaps I should've used an arrow => instead Then it's even less of issue. Yes if you convert to a float you get rounding, what did you expect when you introduced a float? It's somewhat unintuitive but that's the nature of floating point. > The real point is that you can get some non-intuitive answers from letting that numeric tower make conversion decisions for you. It's just a rule, and it's not an amazing rule. But again, you can have the same kind of issue without bignums. It's not a tower problem it's a float problem.
lispm 2y ago
> Nice or not, pretending that double precision floats and arbitrary precision integers can be stacked as a tower is foolish. There are floats that can't be represented as integers, and integers which can't be represented as floats. The numeric tower in Scheme describes general number types with above of in the tower graphic (in the Wikipedia article) meaning subtype of. double precision floats and arbitrary precision integers are representations of numbers. Both would also be Real numbers.

by xscott 2y ago

em-bee 2y ago

that's not what pike is doing though. int and float are still kept separate. btw, i just checked, typeof() no longer shows the difference between int and bigint. it did in the past if i remember correctly

xscott 2y ago
You gotta read between the lines with the commenter above. Their name is a reference to "Smug Lisp Weeny", and they're part of the religion (cult) that thinks everything in Lisp (usually Common Lisp) is perfect. He couldn't care less about Pike, except as an excuse to be smug about Lisp.
- anonzzzies 2y ago
  Besides his nick, was he smug? He just noted that Lisp(likes) solve this problem for some version of 'solve' with the numerical tower. The implementations don't (usually; I am not aware of any) mix exact and inexact as that would be foolish obviously.
  - xscott 2y ago
    > Besides his nick, was he smug? Saying, "That's nice." is a cliche condescension. You're free to disagree, but I think his intent was clear.
    - anonzzzies 2y ago
      Ah, I did not read that into it. But guess that might be what he was doing.

Dylan16807 2y ago

> This is where you say something about "exact" vs "inexact" as though that will hand wave it away. I'm not familiar with this debate, but how is that a hand wave? The article describes a reasonable-sounding way to extend the tower with a second dimension of precision. Following those rules, you would never just convert between bigint and float, but an expression involving both would output a float.

xscott 2y ago
It's a rule, and it behaves like people probably expect for small numbers. But following that rule: float(0.5) + bigint(9007199254740993) == float(9007199254740992) I wouldn't parade it around as a triumph over the problem, and it's arguably better to require people to be explicit about whether converting the float to bigint, or the bigint to float, is what you wanted.
- Dylan16807 2y ago
  That doesn't really strike me as worse than any other use of == on a float. If anything needs to change there, I think it's more rigor in float comparisons. Basically, ULP-level inaccuracy is a problem inherent to having float at all, even without bignum interactions. They would be a menace even if you had a pure tower from 32 bit int to double to complex to more.
  - xscott 2y ago
    I wasn't trying to draw attention to comparisons for equality. Perhaps I should've used an arrow => instead of == to indicate "the result of this operation", but that probably would've caused confusion too... The real point is that you can get some non-intuitive answers from letting that numeric tower make conversion decisions for you. It's just a rule, and it's not an amazing rule.
    - Dylan16807 2y ago
      > I wasn't trying to draw attention to comparisons for equality. Perhaps I should've used an arrow => instead Then it's even less of issue. Yes if you convert to a float you get rounding, what did you expect when you introduced a float? It's somewhat unintuitive but that's the nature of floating point. > The real point is that you can get some non-intuitive answers from letting that numeric tower make conversion decisions for you. It's just a rule, and it's not an amazing rule. But again, you can have the same kind of issue without bignums. It's not a tower problem it's a float problem.

lispm 2y ago

> Nice or not, pretending that double precision floats and arbitrary precision integers can be stacked as a tower is foolish. There are floats that can't be represented as integers, and integers which can't be represented as floats. The numeric tower in Scheme describes general number types with above of in the tower graphic (in the Wikipedia article) meaning subtype of. double precision floats and arbitrary precision integers are representations of numbers. Both would also be Real numbers.