I agree with mikera on this, the standard numeric abstraction have to be able to fulfill all performance needs. This definitly excludes multimethods (algo.generic) and protocols/interface-calls (numeric-tower). (Imagine multiplying two 5000x5000 matrices and having to go through a protocol for each scalar operation).
Ultimately wee would need numeric code like that from clojure's numeric primitives. Here is some relevant code snippet from Numbers.java from the clojure compiler https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Numbers.java#L3559-L4054 > > 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. > Maybe we could do something similar here to what was done for the ndarray implementation of core.matrix using macros. (from maps {[Type-left Type-right] operation} generate class with static methods (using gen-class) that are overloaded in the right way like in the snippet from the clojure compiler. This would make it simple to add new numeric types, but the code would have to be recompiled. > > > 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. > -- 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.
