Hi Konrad, First off, thanks for the advice, steps and link! Secondly, the link to my fork is:
git://github.com/travis-a-hoffman/clojure.git I did notice your Complex implementation in clojure-contrib, and I especially appreciated the effort in the generalizations. I'm a total n00b to Clojure and functional programming. From what I've read about the intentional exclusion of reader macros (as an example) it seems that it is in keeping with the spirit of the language to keep the basic mathematical operations in the core of the language and to *not* generalize it. Also, it seems more elegant to me to be able to simply write a complex number in a "natural" way i.e. 5+3i. I didn't see a way to do that without modifying clojure core I started with "Number" (b in your note), but ran into some trouble because of a risk a loss of precision so I used BigDecimal for the real and imaginary parts. This is what Rich does in Ratio for the numerator and denominator. Your point on having an Imaginary type is well taken. I 'll add that soon! Lastly my real motivation was to gain greater familiarity with the internals and this seemed like an approachable place to start. Cheers, Travis On Jun 2, 12:23 am, Konrad Hinsen <konrad.hin...@fastmail.net> wrote: > On 1 Jun 2010, at 20:24, Travis Hoffman wrote: > I did > > I was curious what it would take to add a complex number type to > > Clojure Core. If anyone else is curious, it doesn't take much: > > > 1.) Add clojure.lang.Complex > > 2.) Add a Pattern and code to match, parse and create complex numbers > > in LispReader (parses number of the form 1.0+0.0i) > > 3.) Add ComplexOps class (and a few related > > Two comments: > > 1) The first decision concerning complex numbers is what you want to > use them for. There at least three reasonable internal > representations, depending on the application domains: > a) (defrecord complex [^Float real ^Float imag]) > b) (defrecord complex [^java.lang.Number real ^java.lang.Number imag]) > c) (defrecord complex [real imag]) > > The first is good for numerical work as it occurs in science and > engineering. It permits the most efficient implementation because all > operations can be expressed in terma of Java primitive types. The > second is the most consistent with Clojure's numerical stack, allowing > real and imaginary parts to be integers, ratios, big integers etc. - > but there would need to be a check to prevent complex numbers to be > used inside complex numbers. The last one is the most general in that > complex numbers are seen as mathematical structures rather than as > numbers; it permits complex polynomials and other data structures that > are not numbers. As a consequence, it can't be implemented in the > number hierarchy. > > An implementation equivalent to c) but predating defrecord and deftype > can be found in clojure-contrib. I think it is useful to have > (otherwise I wouldn't have written it), but I don't think it should be > part of the language itself. If I were to choose a representation to > be added to clojure.core, I'd pick b). > > 2) It is a good idea to provide an "imaginary" type in addition to > "complex". There is an old and much-cited paper that explains the > reasons very well; it comes down to eliminating needless > multiplications and additions with zero when dealing with pure > imaginaries, which occur rather frequently. Another advantage is that > there is no need for complex literals; just have 1j return an > imaginary literal and use addition to construct complex values. > > > I tried to follow Ratio's example as closely as I could, though there > > is some trickiness things about implementing lt ... there really isn't > > an accepted definition for saying one complex number is greater than > > another. > > I'd even say that it is accepted that there is no such definition: > complex numbers have no order relation. You certainly shouldn't try to > implement java.lang.Comparable. > > > I'm a bit new to Git/GitHub and to Clojure, but if you're curious I > > think I correctly created a fork of the master branch with my changes. > > Could you give the link to your fork? > > > How would I go about submitting a ticket to add the "Complex" type and > > to create a patch to submit my proposed changes? > > 1) Join the clojure-dev list and discuss your proposal there. > 2) Send a contributor agreement to Rich. > 3) Join the clojure group on assembla.com > 4) Follow the instructions athttp://clojure.org/contributingto > prepare a patch. > > But please start with 1), that's the most important step! > > Konrad. -- 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
