A Wednesday 02 July 2008, Charles R Harris escrigué:
> On Wed, Jul 2, 2008 at 9:58 AM, Charles R Harris
> <[EMAIL PROTECTED]>
>
> wrote:
> > 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.
>
> 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
_______________________________________________
Numpy-discussion mailing list
[email protected]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
