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

[Charles R Harris]

On Thu, Jul 3, 2008 at 2:00 AM, Francesc Alted <falted at pytables.org> wrote:

> A Wednesday 02 July 2008, Charles R Harris escrigué:
> > On Wed, Jul 2, 2008 at 9:58 AM, Charles R Harris
> > <charlesr.harris at gmail.com>
> >
> > wrote:
> > > 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.
> >
> > 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?
>

No, just that clongdoubles didn't use to print with sufficient repr
precision for reasons I didn't understand, I added a NPY_ prefix to the name
of the generated printing function, and voila, it worked. For some reason
cfloat and cdouble are using other print functions, which I suspect call the
python repr function. Anyway, I propose the following

1) Make all the prints go through the same generated code. This makes the
appearence consistent.
2) Decide how the output should be formatted.

So I can make either (0.0+0.0j) or perhaps something shorter the standard
format. If you have a preference, speak up.

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