Options

Complex arithmetic

I'll write a little bit about robust implementations of some simple complex functions and complex arithmetic on the page complex numbers. It is good that libraries like the gsl implement it correctly. It is bad that almost none of the methods of the gsl and other implementations have any commentary at all explaining why they do things the way they do it.

Comments

  • 1.
    edited April 2011

    In my role as a "devilish make-it-go-fast guy", I'll mention that there's a fundamental big question: in a context where you've got lots of complex numbers (for example, an array) do you store that as an array of individual "complex" objects or as a complex array "real array + i* imaginary array". For performance, the second approach is better since you can use SIMD (although intel did add some special instructions for doing complex multiplication) and potentially allows you to optimise operations in the case where a Complex array is known to acutally be real or real and imaginary parts can be transformed separately. (This is what matlab/octave do under the hood.) On the other hand it's more and more complicated to code, breaks encapsulation (eg, you can't have some elements in polar form until they need to be converted) and it's not as suitable if you're genuinely processing each complex number completely separately. There's no "correct" answer, it depends what your priorities are for the codebase in question.

    Comment Source:In my role as a "devilish make-it-go-fast guy", I'll mention that there's a fundamental big question: in a context where you've got lots of complex numbers (for example, an array) do you store that as an array of individual "complex" objects or as a complex array "real array + i* imaginary array". For performance, the second approach is better since you can use SIMD (although intel did add some special instructions for doing complex multiplication) and potentially allows you to optimise operations in the case where a Complex array is known to acutally be real or real and imaginary parts can be transformed separately. (This is what matlab/octave do under the hood.) On the other hand it's more and more complicated to code, breaks encapsulation (eg, you can't have some elements in polar form until they need to be converted) and it's not as suitable if you're genuinely processing each complex number completely separately. There's no "correct" answer, it depends what your priorities are for the codebase in question.
  • 2.

    First and foremost I'm miffed at the authors of the gsl and the like that they make me look up every single algorithm myself, while it is hardly any work at all to explain what you have done after you did the coding. This is just a waste of my time, and a waste of everybody else who tries to understand the code.

    I think that an object oriented implementation that handles complex numbers and the like as objects and implements the arithmetic via methods with operator names like it is possible in Scala does help a lot in getting clearer code. It should be possible to code algorithms in a way that resembles their description in the literature almost completely. And I think we should keep such implementations around for teaching purposes, even if the production code uses some sophisticated version that is harder to understand.

    What really put me off was implementing complex arithmetic in Java that looks like

    a = c.multiply(b.add(c));

    instead of $a = c*(b + c)$, as is possible in Scala.

    Comment Source:First and foremost I'm miffed at the authors of the gsl and the like that they make me look up every single algorithm myself, while it is hardly any work at all to explain what you have done after you did the coding. This is just a waste of my time, and a waste of everybody else who tries to understand the code. I think that an object oriented implementation that handles complex numbers and the like as objects and implements the arithmetic via methods with operator names like it is possible in Scala does help a lot in getting clearer code. It should be possible to code algorithms in a way that resembles their description in the literature almost completely. And I think we should keep such implementations around for teaching purposes, even if the production code uses some sophisticated version that is harder to understand. What really put me off was implementing complex arithmetic in Java that looks like <blockquote> <p> a = c.multiply(b.add(c)); </p> </blockquote> instead of $a = c*(b + c)$, as is possible in Scala.
Sign In or Register to comment.