There is really no "perfect" numerical type: - primitive doubles are best if you care about performance and reasonably good precision (but no complex numbers!) - boxed Doubles are needed in some circumtances, e g. storage in collections, passing to dynamic code - something like org.apache.commons.math3.complex.Complex is a good general purpose complex number - you might also want "rational doubles" where both the real and imaginary part are rationals - sometimes libraries might use a length 2 vector as a complex number (many libraries do this, including vectorz-clj) - quaternions would be nice too!
With all this in mind, I'd love to see a way to get a numerical stack that abstracts away from the concrete number type, in roughly the same way that core.matrix abstracts away from the underlying array type. That way, mathematical functions could defined to work intelligently on arbitrary numerical types. Performance would be the main concern.... if this is going to be the "standard solution" for Clojure then we want it to work for all use cases, including the performance-sensitive ones. Multimethods (the approach used by algo.generic) are flexible but way too slow. Even protocols are probably too expensive for performance-oriented numerical code if you are paying the dispatch overhead for every single operation. Note that protocols are fine for core.matrix, since you only pay the protocol once per whole-array operation which might execute millions of individual element operations. Basically... I think making this work both elegantly and efficiently is going to need compiler enhancements. Ideally there would be a mechanism to allow type hints / type inference or something similar that would optimise away the dynamic type-based dispatch checks in the case where the compiler knows or can infer the exact concrete type. On Friday, 15 August 2014 23:24:24 UTC+8, Maik Schünemann wrote: > > Hi, > is there a recommended way to do complex arithmetic in clojure ? > I am interested to see clojure going forward for scientific computing > purposes. > There is already considerable effort going on with core.matrix, incanter, > expresso etc. > But something thad is oddly lacking is support for complex numbers. For > some areas, this is > a show stopper and it is very basic stuff in other languages and systems: > - common-lisp, python etc all have a standard complex type as part of the > language/standard library > - see language support here http://en.wikipedia.org/wiki/Complex_data_type > > In Java, there are multiple incompatible complex number classes and I > don't want that incompatibilities > in clojure libraries that provide complex number manipulation. > > In my opinion we should strive as a community for a standard complex > number datatype, that is agreed on by clojure libraries, > and plays nicely with clojures other numeric types. > Ideally, this would be provided as part of clojure.contrib or even clojure > itself - like rationals are! > > > > > -- 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.