On 23.11.2008, at 16:28, Rock wrote: > Furthermore, the implementation should, I think, be generic, that > is, we should be capable of creating complex numbers, the real and > imaginary parts of which can be integers, rationals, or reals. For > instance, it sould be possible to > do this: > > (1/3 + 2/5i) + (1/2 + 1/10i) = (5/6 + 1/2i) > > without any loss of precision due to type conversion (ex. towards > float).
There are good reasons for such a choice, but there are good reasons as well to have an implementation that represents a complex number as two floats with all operations optimized for speed. Ideallly, there would be both, with different constructor names, just like Clojure has two map implementations with different performance characteristics. Even more ideally, there would be a way (through type annotations for example) to tell the compiler to inline complex arithmetic operations and generate code that uses primitive Java types only, in order to avoid the boxing overhead associated with objects. On 23.11.2008, at 15:42, Rich Hickey wrote: > I have nothing against complex numbers, and interested parties should > contribute to this discussion on how best to incorporate them in > Clojure. The issues are: > > What support is required? > How hard to do with no other libs, a la Ratio? I don't know if there are any Java libs that do it well enough. As with many other things, complex numbers are not hard to implement in principle, but hard to implement really well. 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
