quot and rem in the doubles case (where any one of the arguments is a floating point) gives strange results for non-finite arguments:
quot and rem also do divide-by-zero checks for doubles, which is inconsistent with how doubles act for division:
Attached patch does not address this because I'm not sure if this is intended behavior. There were no tests asserting any of the behavior mentioned above.
Fundamentally the reason for this behavior is that the implementation for quot and rem sometimes (when result if division larger than a long) take a double, coerce it to BigDecimal, then BigInteger, then back to a double. The coersion means it can't handle nonfinite intermediate values. All of this is completely unnecessary, and I think is just leftover detritus from when these methods used to return a boxed integer type (long or BigInteger). That changed at this commit to return primitive doubles but the method body was not refactored extensively enough.
The method bodies should instead be simply:
Which is what the attached patch does. (And I'm not even sure the d==0 check is appropriate.)
Even if exploding on non-finite results is a desirable property of quot and rem, there is no need for the BigDecimal+BigInteger coersion. I can prepare a patch that preserves existing behavior but is more efficient.
More discussion at Clojure dev.