On 1 Jun 2010, at 20:24, Travis Hoffman wrote:
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 at http://clojure.org/contributing to
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
