Arc Forumnew | comments | leaders | submitlogin
1 point by Pauan 2470 days ago | link | parent

Basically. You could drop down and use Racket's "fixnum?" and "integer?" functions, but Nulan doesn't provide them. If you find any way to distinguish them, I'd like to hear it.

I prefer to view integers as being a subset of floating point, so I prefer to see 1 and 1.0 as identical. Is there a reason not to?



1 point by rocketnia 2470 days ago | link

Does Nulan give access to 'write? That would distinguish them.

"I prefer to view integers as being a subset of floating point[...]"

I don't know about that. What happens with very large, but exact, integers?

---

"[...]so I prefer to see 1 and 1.0 as identical. Is there a reason not to?"

Actually I think there is a reason. We're talking about exact and inexact numbers here. If you want to know that a number is exactly 1, then 1.0 doesn't give you enough information. :-p

Personally, I think floating point numbers mostly get in the way. I'd rather treat them as a separate concept, even if it means using a special +. operator like OCaml.

I don't see much need for complex numbers, rational numbers, or negative numbers either, but at least their addition and multiplication are still associative.

-----

1 point by Pauan 2470 days ago | link

"Does Nulan give access to 'write? That would distinguish them."

Not if I change printing to always use floating point, or print exact floating points as integers. :P I actually did something like that with Arc/Nu: I was tired of typing in (/ 1 5) and getting back 1/5, so I changed Arc/Nu to print exact numbers as if they were inexact, so it would print 0.2. This only affects the printing, not the actual math stuff.

---

"I don't know about that. What happens with very large, but exact, integers?"

I dunno, what happens in Racket?

---

"Similarly, in JavaScript I tend to use Arrays of strings, storing them as their ECMAScript 5 JSON representation."

Ah yeah, that works, I didn't think of that.

-----

2 points by rocketnia 2470 days ago | link

"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 2468 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 2467 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 2467 days ago | link

Yes.

-----