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

Charles R Harris charlesr.harris at gmail.com
Thu Jul 3 15:44:46 EDT 2008


On Thu, Jul 3, 2008 at 1:30 PM, Charles R Harris <charlesr.harris at gmail.com>
wrote:

> Hmm,
>
> On Thu, Jul 3, 2008 at 11:44 AM, Francesc Alted <falted at pytables.org>
> wrote:
> <snip>
>
>>
>> Ok.  But str also represents differently the 0j:
>>
>> In [24]: str(numpy.complex64(0))
>> Out[24]: '(0.0+0.0j)'
>>
>> In [25]: str(numpy.complex(0))
>> Out[25]: '0j'
>>
>> In addition, I find the new representation not too nice looking:
>>
>> In [35]: str(numpy.complex128(5/3j))
>> Out[35]: '(0.0+-1.66666666667j)'   # note the '+-' thing
>>
>> In [36]: str(numpy.complex(5/3j))
>> Out[36]: '-1.66666666667j'
>>
>>
>> So, perhaps it would be a wise thing to mimic the python behaviour for
>> this sort of things, if possible.
>>
>
> Looks like the numpy.complex scalar is the python type:
>
> In [2]: str(numpy.complex64(0))
> Out[2]: '(0.0+0.0j)'
>
> In [3]: str(numpy.complex128(0))
> Out[3]: '(0.0+0.0j)'
>
> In [4]: str(numpy.complex192(0))
> Out[4]: '(0.0+0.0j)'
>
> In [5]: str(numpy.complex(0))
> Out[5]: '0j'
>
> ...
>
> In [9]: type(numpy.complex(0))
> Out[9]: <type 'complex'>
>
> In [10]: type(numpy.complex128(0))
> Out[10]: <type 'numpy.complex128'>
>
> In [11]: ones(1, numpy.complex)
> Out[11]: array([ 1.+0.j])
>
> Unless it is used as a dtype:
>
> In [12]: ones(1, numpy.complex).dtype
> Out[12]: dtype('complex128')
>
> So one fix would be to use the specific numpy type. Because we don't want
> to overload the usual Python complex type this distinction probably has to
> be kept in mind. Note that cfloat, cdouble, and clongdouble are more
> portable ways of getting at the c precisions.
>
> The other fix is to format numpy complex in exactly the same way as python
> complex. That is more complicated, not least because we have to figure out
> what the rules are, but can be done.
>
> I would like some folks to weigh in on the desirability of changing the
> format before I go off to do it.
>

Note that python itself is a bit inconsistent:

In [7]: complex(0)
Out[7]: 0j

In [8]: float(0)
Out[8]: 0.0

Putting on my pedant hat, I would think 0.0j would be more appropriate.

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


More information about the NumPy-Discussion mailing list