On 13 Nov 2009, at 23:03, Stuart Sierra wrote: >> This example has maybe a problem : doesn't the symmetry of these >> Arithmetic operators seems to be crying for type multiple dispatch in >> this particular case ? :-) > > Yes, in the general case, arithmetic requires multimethods. But > multimethods -- or any dynamic type dispatch -- are too slow for math- > heavy code anyway.
That depends on how it is used and on what types. clojure.contrib.complex has a multimethod-based implementation which moreover does a multimethod dispatch on the real/imaginary parts, making it possible to use any numeric type, built-in or not, inside the complex type. That's about as inefficient as it can get, but also very flexible. You can do symbolic computing with that kind of framework, and then the overhead is tolerable, but for number crunching it is not. I think arithmetic is a bad "first example" for just about any implementation technique. Doing it well is very hard, and as far as I know no one has yet come up with any technique that is fully satisfying for all applications. 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
