On Wed, Jul 2, 2008 at 7:12 AM, Francesc Alted <[EMAIL PROTECTED]> 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 *
[EMAIL PROTECTED]@[EMAIL PROTECTED]@(PyObject *self)
{
static char buf1[100];
static char buf2[100];
static char buf3[202];
[EMAIL PROTECTED]@ x;
x = (([EMAIL PROTECTED]@ScalarObject *)self)->obval;
[EMAIL PROTECTED]@(buf1, sizeof(buf1), x.real, @[EMAIL PROTECTED]@KIND@);
[EMAIL PROTECTED]@(buf2, sizeof(buf2), x.imag, @[EMAIL PROTECTED]@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
_______________________________________________
Numpy-discussion mailing list
[email protected]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
