Re: complex number API

[Brian Gough <bjg@netsci.freeserve.co.uk>]

Yup, modified quantities should be passed as pointers, so that it's more
obvious that they are modified, e.g. GSL_COMPLEX_SET(&z,x,y)

I'm not sure why it's bad to use something like GSL_REAL(z) as an
lvalue. Having GSL_SET_REAL(&z, x) and GSL_SET_IMAG(&z, y) seems fine
though, so I added those.

These changes don't affect the fft code.

Mark Galassi wrote:
> 
> In writing up NEWS entries I noticed that the complex number API has
> some problems.
> 
> First of all, there should be separate macros for setting and
> retrieving the real and imaginary parts.  Otherwise you end up using
> GSL_REAL(z) as a left-hand-side, which is bad form and can hurt down
> the line.
> 
> I would add GSL_SET_REAL(z, x) and GSL_SET_IMAG(z, y).
> 
> Second, GSL_COMPLEX_SET modifies its z argument, which makes the
> interface "magic" and is bad form, and could cause problems down the
> line.  I would modify it to either return z or to take a zp (pointer
> to z).
> 
> Does anyone have any thoughts on the subject?  And Brian, how much are
> these forms of the macros used in the FFT code?