Problems

- two Clojure platforms with different platform math libs
- API consumers shouldn't have to care
- wrap in Clojure fns?

- math ops need to be fast
- e.g. Clojure double dispatch not multimethods

Things to consider

- numbers in ClojureScript likely to get smarter
- will we use goog.math.long?

- break math API into subproposals
- by frequency of usage
- may end up with more than one namespace?

- perhaps by platform support

- by frequency of usage

Labels:

## 1 Comment

Hide/Show CommentsJul 26, 2011

## Mark Engelberg

A few points:

The most recent implementation of clojure.contrib.math no longer uses multimethods.

clojure.contrib.math was born out of my frustration that Clojure had no built-in exponentiation/power function, and the only one offered in Java's library was a function that operated on doubles. The lack of a way to do exponentiation on arbitrary numbers from Clojure's numeric tower seemed like a pretty big gap, so I decided to fill it. While I was at it, I implemented a few of the most important math functions from the Scheme specification. The point here is that contrib.math was always intended to fill the niche of "full numeric tower math operations". If people want to do things like exponentiation, absolute values, and square roots on primitive doubles, they already have a way to do that with Java's math library.

My understanding is that ClojureScript does not currently have any kind of numeric tower so the notion of porting clojure.contrib.math (which is all about providing full numeric tower ops) to ClojureScript doesn't make any sense. This wiki page implies that the main purpose of the math namespace is to provide programmers with a platform-independent way to do math. Platform-independent math may be desirable, but I see it as completely orthogonal to the problem that clojure.contrib.math was created to solve.