My two cents: I started to develop some support to complex numbers in Clojure, but I don't know if the Core Team/Rich Hickey has any intererest in this subject.
Even it's an unfinished work, I didn't notice any lost of performance so far. Regards Plínio Balduino On Tue, Apr 28, 2015 at 9:35 AM, Gary Verhaegen <gary.verhae...@gmail.com> wrote: > 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 >> 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. > -- 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.
