For what it's worth, I think something like 3+5i is perfectly reasonable as the + is not an operation, but part of the notation for a single value, just as the + is not an operation in 1.234e+14. The more troubling concern is whether the imaginary component should be suffixed with an i or a j. ;)
On Jun 5, 6:17 pm, Travis Hoffman <travis.a.hoff...@gmail.com> wrote: > Konrad, > > > Thanks, I'll look at that... > > I should warn that my changes don't quite seem to be working, there's > something running amuck in the code yet that I'm still working on > debugging, but the core is a bit mystifying. > > > > 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 > > > No. But I wonder if "5+3i" is very natural for a language that doesn't > > have infix arithmetic. This notation is just a sum of a real and an > > imaginary number, so in Clojure I'd expect to see (+ 5 3i) instead. > > Konrad, I see your point, but it seems that Rich has chosen a less > "lisp purist" perspective on this. Please consider the following > examples: > > (class (/ 3 4)) ; legal > (class 3/4) ; legal > (class 3 / 4) ; illegal > (class 3/ 4) ; illegal > (class 3 /4) ; illegal > (class 1.234e+14) ; legal > (class 1.234e-14) ; legal > (class 1.234 e-14) ; illegal > (class 1.234e -14) ; illegal > (class 1.234 e -14) ; illegal > > It seems to be that Rich has the perspective that a Ratio's toString() > output is also valid input as well, even though this appears to be an > infix notated '/'. What I'm proposing is that a number ending with 'i' > is imaginary or complex, and that a '+' with no spaces may be used to > define a complex > > I think the "3+5i" form makes more sense *because* there isn't infix > notation in the language. Please also consider the example of an > exponentiated double. It's permissible to have a '+' or a '-' in the > middle of that number, but it isn't to be confused with an infixed '+' > operation. > > > What trouble? > > I need to reinvestigate what the trouble was. Maybe it was in the > complexity of parsing, or simply because Rich used BigInteger in > Ratio. I'll get back to you on that one! > > > Perhaps a good compromise would be to have a thin Clojure wrapper > > around a good Java library. > > This is what I was thinking too. -- 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
