Your messages are a bit confusing. Playing nice with collection functions would depend on the collection, not on its contents.
Maybe you could elaborate a bit more on what you're trying to accomplish? If you do not care about performance, you need to decide whether you want your type to work with clojure.core arithmetic operators, which from Alex's comments would seem to require modifying Clojure itself, or if it would be acceptable to you to define your own operators in your own namespace (which could check the type and default to the clojure.core versions, providing some transparency in exchange for some performance). Of course, you then have to worry about other functions that maybe call clojure.core operators indirectly, and the bahavior of functions such as min and max. On Tuesday, 28 April 2015, Nik <nkripl...@gmail.com> wrote: > It does seem as though there is no way to meet all the criteria, unless > the support for it comes from Java/Oracle. That said, I feel like having a > complex type with reasonable performance is better than having nothing at > all. > > What I would like is a complex type that plays well with Clojure's generic > abstractions and functional style (much like Ratio), and is > indistinguishable from other types - for example, the ability to work with > (map/reduce/filter), the ability to be a part of seqs and use Clojure core > functions on it, and so on. It might not as efficient as the complex type > in, say C++, but depending on your definition of reasonable, it might be > acceptable. I am willing to explore this further. > > Alex, would opening up the type system as you pointed be a way to go? > > Also, I am not sure is this is possible for us to accomplish, but some > academic work has been done where a Java complex class has been created, > and through the use of semantic expansion, it has very high performance. > PDF Link: > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.42.7264&rep=rep1&type=pdf > > > > > > > On Tuesday, April 28, 2015 at 12:22:08 AM UTC-4, Mikera wrote: >> >> Complex numbers are tricky because: >> - They need to be fast in order to be useful for numerical computing. The >> "obvious" implementations that you might create with boxed values, >> vectors/maps, multimethods and protocols are likely to be unacceptable for >> many use cases >> - You still want to be able to use them in a generic way, with operations >> that play nicely with other values (Doubles etc.) >> >> I have thought about this a lot w.r.t. core.matrix and have come to the >> conclusion that there is no simple, elegant answer that meets all use cases. >> >> What I'd like to suggest is: >> a) The community converge on a single, minimal, lightweight >> representation for a boxed complex scalar value. This is probably best as a >> Java class (for easy interop with Java libraries). I think >> http://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math3/complex/Complex.html >> is a good candidate >> b) A lightweight wrapper library that provides nice complex functions in >> Clojure, using the above type. Nothing fancy. But can make extensive use of >> type hints etc. for performance so should be pretty fast >> c) A library using core.matrix that implements complex vectors, complex >> matrices etc but also uses a) for complex scalar values. This should use a >> underlying double-array backed implementation for performance, probably >> vectorz-clj would be best (though that could be hidden as an implementation >> detail). This library would also implement all the core.matrix protocols >> for the chosen complex number type, mostly just by calling b) directly >> >> >> On Monday, 27 April 2015 23:39:34 UTC+8, Nik wrote: >>> >>> I have been thinking along the lines of mikera and Maik - and it seems >>> like there is no further progress here? I would like to take a crack at >>> creating a complex number type, but implemented as a library to Clojure. I >>> am not sure where to start, and if anyone here has suggestions, I'd be >>> happy to hear them. >>> >>> A complex number could simply be a vector of two elements, or a map with >>> :real and :imag keys (or something lightweight) - and I am not sure what it >>> would require to make this type work happily with code arithmetic functions >>> in Clojure and Java Math. >>> >>> It would also have to work with seq operations in Clojure - for >>> instance: >>> If I have a complex number c = {:real 3 :imag 4}, and a vector v = [1 -2 >>> c], it would be nice to have the call 'map #(Math/abs %) v' produce (1 2 >>> 5). >>> >>> I am having trouble figuring out all the pieces that need to be >>> implemented. Is it even possible to implement this as a library, or does >>> this need to be a part of clojure.core? >>> >> -- > 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 > <javascript:_e(%7B%7D,'cvml','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 > <javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@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 > <javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@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.
