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.