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

Francesc Alted falted@pytables....
Thu Jul 3 03:00:23 CDT 2008


A Wednesday 02 July 2008, Charles R Harris escrigué:
> On Wed, Jul 2, 2008 at 9:58 AM, Charles R Harris
> <charlesr.harris@gmail.com>
>
> wrote:
> > On Wed, Jul 2, 2008 at 7:12 AM, Francesc Alted
> > <falted@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@name@type_@kind@(PyObject *self)
> > {
> >     static char buf1[100];
> >     static char buf2[100];
> >     static char buf3[202];
> >     c@name@ x;
> >     x = ((PyC@Name@ScalarObject *)self)->obval;
> >     format_@name@(buf1, sizeof(buf1), x.real, @NAME@PREC_@KIND@);
> >     format_@name@(buf2, sizeof(buf2), x.imag, @NAME@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.
>
> And I suspect this might be fallout from changeset #5014: Fix missing
> format code so longdoubles print with proper precision. The
> clongdouble repr function used to be missing and probably defaulted
> to cdouble.

I'm not sure I follow you.  Are you telling that this is a result of 
upcasting cfloats and cdoubles to clongdoubles when representing NumPy 
complex numbers?  If so, why this should happen at all?

Cheers,

-- 
Francesc Alted


More information about the Numpy-discussion mailing list