Would someone care to rationalize the implementation of (rationalize)?
(type (rationalize (/ 64 8)))
java.lang.Long
(type (rationalize (/ 64 7)))
clojure.lang.Ratio
(type (rationalize (/ 49 7)))
java.lang.Long
(type (rationalize (/ 49 6)))
clojure.lang.Ratio
Extraordinarily thorny to alternate type output in this manner IMO. But I
think a developer could cope with it if there wasn't ratio handling
weirdness elsewhere.
Perhaps because of lack of handling for the above behavior, we have:
(rational? (/ 49 6))
true
(rational? (/ 49 7))
true
but..
fin.core> (numerator (/ 49 6))
49
(numerator (/ 49 7))
ClassCastException java.lang.Long cannot be cast to clojure.lang.Ratio
clojure.core/numerator (core.clj:3462)
Why doesn't (numerator) handle java.lang.Long? Is this an oversight or is
there a philosophy at work here? In isolation I could understand a
justification perhaps, but not in light of the behavior of (rationalize)
{see above}.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
