It looks like you're new here. If you want to get involved, click one of these buttons!

- All Categories 2.3K
- Chat 500
- Study Groups 19
- Petri Nets 9
- Epidemiology 4
- Leaf Modeling 1
- Review Sections 9
- MIT 2020: Programming with Categories 51
- MIT 2020: Lectures 20
- MIT 2020: Exercises 25
- MIT 2019: Applied Category Theory 339
- MIT 2019: Lectures 79
- MIT 2019: Exercises 149
- MIT 2019: Chat 50
- UCR ACT Seminar 4
- General 67
- Azimuth Code Project 110
- Statistical methods 4
- Drafts 2
- Math Syntax Demos 15
- Wiki - Latest Changes 3
- Strategy 113
- Azimuth Project 1.1K
- - Spam 1
- News and Information 147
- Azimuth Blog 149
- - Conventions and Policies 21
- - Questions 43
- Azimuth Wiki 713

Options

## Comments

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.

`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.`

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

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

`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.`