Hacker News new | ask | show | jobs
by xscott 600 days 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.

3 comments

> 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.

> 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.

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.
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.

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.

> 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.

I think I can summarize your point of view as, "any use of floats should be treated as undefined behavior, so you get what you deserve."

And that says nothing about whether implicit conversions are a good idea or not.

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

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.
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.
> 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.

Ah, I did not read that into it. But guess that might be what he was doing.