[Numpy-discussion] Change in the representation of complex numbers in NumPy 1.1
Charles R Harris
charlesr.harris@gmail....
Wed Jul 2 11:16:55 CDT 2008
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.
Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/numpy-discussion/attachments/20080702/a90cc670/attachment-0001.html
More information about the Numpy-discussion
mailing list