Arc Forumnew | comments | leaders | submitlogin
2 points by rocketnia 4419 days ago | link | parent

"I dunno, what happens in Racket?"

Actually, this is going a bit off topic, since it doesn't especially matter to me whether exact integers are a subset of inexact numbers. I thought I even deleted this part of my reply, but oh well. XD

Looks like the racket docs say[1] Racket's inexact numbers are IEEE floating-point numbers of single or double precision, with double being the default. So they don't preserve integers beyond 53 bits:

  > (define foo 12345678901234567890)
  > foo
  12345678901234567890
  > (inexact->exact (exact->inexact foo))
  12345678901234569216
  > (number->string foo 2)
  "1010101101010100101010011000110011101011000111110000101011010010"
  > (number->string (inexact->exact (exact->inexact foo)) 2)
  "1010101101010100101010011000110011101011000111110001000000000000"
Odd, this suggests Racket double-precision floating-point numbers have only 51 bits of mantissa rather than 52, so maybe they actually only preserve integers up to 52 bits...?

[1] http://docs.racket-lang.org/reference/numbers.html



1 point by Pauan 4417 days ago | link

I "solved" this issue by simply making all numbers 64-bit floating point. The change was really easy to make. I didn't do it because of this issue, though. I did it because I want to eventually compile to JS, and JS only has 64-bit floating point.

Though, it also makes it easier conceptually to only have to worry about floating point, as compared to floating point + integer + rational + complex + whatever else Racket has. Even if you divide numbers into exact/inexact like Racket does, that's still more complicated than only having a single numeric type.

-----

1 point by rocketnia 4416 days ago | link

"I did it because I want to eventually compile to JS, and JS only has 64-bit floating point."

JavaScript supports a 52-bit mantissa. Are you willing to have that discrepancy of one bit of precision?

-----

1 point by Pauan 4416 days ago | link

Yes.

-----