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.

Reply via email to