On Wed, Jun 9, 2010 at 2:43 AM, ataggart <alex.tagg...@gmail.com> wrote: > >> For non-literals the notation would need to support this: >> >> (* (my-complicated-algo x)+(my-other-complicated-algo y)i (another- >> algo z)i) > > You're conflating notation with operation.
I wouldn't even bother with reader notation. Both (complex -1 0) and (complex-polar 1 3.14) are readable an compact enough to me. We would still need some support for notation when printing the results, though (could even be that constructor notation), unless we are happy exposing implementation details. This may not be that difficult, AFAIK "print" is already using multimethod dispatch. > The point here is not simply to add a literal notation, but to > integrate complex type handling into the math functions. Bifurcating > the math functions is a horrible idea. Exactly. Speaking for myself again, I use complex numbers (much) more often than ratios (in fact, so far I only played with ratios rather than used them) and such integration would be very useful for me. The question is, how far are we ready to go in that way? I imagine at least two more data types that could be plugged into numeric tower: - vectors/matrices - symbolic expressions Maybe instead of hardwiring all these types, we should provide a mechanism for overloading math operators? I guess multimethods would be too slow and I have no experience with defrecord/... to predict robustness of this solution. -Andrzej -- 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
