Hi Before we try to guess what Rich will or won't think or want, are you interested in a proof of concept? So we could evaluate performance and complexity issues before the subject is definitively buried.
What do you think about it? Plínio On Wed, Apr 29, 2015 at 12:56 AM, Mikera <mike.r.anderson...@gmail.com> wrote: > You can do virtually all of that already with the Apache commons Complex > class. Any Java object can be just fine used with map / reduce / filter / > seqs etc. > > If you want to avoid Java interop and make things more "Clojure-like" then > a lightweight wrapper library is all that is needed (my suggestion b) ). > You could probably also support tagged reader literals for complex numbers > pretty easily. > > The only problem would be supporting complex types in numerical > clojure.core/+. That is very unlikely to happen - I doubt Rich and co want > to start adding complexity to the core functions which would hurt > performance and break the assumptions that people have about the numerical > functions in clojure.core. But that isn't ultimately a big problem, you can > just use a specialised addition operator like clojure.complex/+ or > clojure.core.matrix.operators/+ instead when you write complex-using code. > That's part of my suggestions b) and c), basically to have separate APIs > that understand complex types. > > > > On Tuesday, 28 April 2015 19:42:23 UTC+8, Nik wrote: >> >> .... >> 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. >> ..... >> >> >> >> >> >> >> 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.
