[Numpy-discussion] Change in the representation of complex numbers in NumPy 1.1

[Charles R Harris]

On Wed, Jul 2, 2008 at 7:12 AM, Francesc Alted <falted at pytables.org> wrote:

> Hi,
>
> I've seen that NumPy has changed the representation of complex numbers
> starting with NumPy 1.1.  Before, it was:
>
> >>> numpy.__version__
> '1.0.3'
> >>> repr(numpy.complex(0))    # The Python type
> '0j'
> >>> repr(numpy.complex128(0))  # The NumPy type
> '0j'
>
> Now, it is:
>
> >>> numpy.__version__
> '1.2.0.dev5313'
> >>> repr(numpy.complex(0))
> '0j'
> >>> repr(numpy.complex128(0))
> '(0.0+0.0j)'
>
> Not that I don't like the new way, but that broke a couple of tests of
> the PyTables suite, and before fixing it, I'd like to know if the new
> way would stay.  Also, I'm not certain why you have chosen a different
> representation than the Python type.
>

Looks like different functions are being called, as identical code is
available for all the complex types. Hmm... probably float is promoted to
double and for double the python repr is called. Since python can't handle
longdoubles the following code is called.

static PyObject *
c at name@type_ at kind@(PyObject *self)
{
    static char buf1[100];
    static char buf2[100];
    static char buf3[202];
    c at name@ x;
    x = ((PyC at Name@ScalarObject *)self)->obval;
    format_ at name@(buf1, sizeof(buf1), x.real, @NAME at PREC_@KIND@);
    format_ at name@(buf2, sizeof(buf2), x.imag, @NAME at PREC_@KIND@);

    snprintf(buf3, sizeof(buf3), "(%s+%sj)", buf1, buf2);
    return PyString_FromString(buf3);
}

So this can be fixed two ways, changing the cfloat and cdouble types to call
the above, or fixing the above to look like python. Whichever way is chosen,
I would rather they go through the same generated functions as it keeps the
code paths simpler, puts the format choice in a single location, and
separates numpy from whatever might happen in python.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20080702/6ddc089d/attachment.html>