On Wed, Aug 26, 2015 at 3:26 PM, waffletower <christopherpenr...@gmail.com>
wrote:
> Would someone care to rationalize the implementation of (rationalize)?
>
Sorry, I don't have an answer of the form "Rich Hickey's rationale for this
behavior is X", because I don't know what X is for this behavior. I can
point out a few things below, but you may already know them.
>
> (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.
>
Note that if you leave the calls to rationalize out of your examples above,
i.e. just do (type (/ 64 8)), etc., you get the same output. (rationalize
x) returns x (with identical value and type) if x is of type
clojure.lang.Ratio or java.lang.Long (or any type other than Float, Double,
or BigDecimal).
If / is given arguments whose types are all integer types or type Ratio, it
returns an integer type if the answer can be represented as an integer,
otherwise it returns a Ratio. The same is true for the arithmetic
operations + - *. In general, arithmetic between Ratio and integer types
always puts the answer in lowest terms possible, and if the denominator
would be 1, the return value is and integer type, not type Ratio. Thus
Clojure's clojure.lang.Ratio type is only used to represent non-integer
values.
>
> 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}.
>
When a decision is made on ticket
http://dev.clojure.org/jira/browse/CLJ-1435, then we will have at least an
'accept' or 'decline' answer to whether this behavior is an oversight.
Such a response might not include the philosophy at work. If more people
vote on that ticket, it will likely lead to an accept/decline answer
sooner. Votes alone do not necessarily affect the accept/decline decision
-- an argument that convinces Rich Hickey that the behavior is worth
changing seems to have more weight than vote count alone. Changes to
functions in clojure.core are made pretty conservatively nowadays, and
numerator and denominator are documented to work only for values of type
Ratio. Note that (ratio? (/ 49 7)) is false.
Andy
--
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.
