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

[Francesc Alted]

A Friday 04 July 2008, Francesc Alted escrigué:
> A Thursday 03 July 2008, Charles R Harris escrigué:
> > 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.
>
> Well, I'd choose that route.  Perhaps digging into the python code we
> can find the relevant code and copy it 'as is' for maximum
> compatibility.

I've added a ticket about this issue:

http://scipy.org/scipy/numpy/ticket/841

Cheers,

-- 
Francesc Alted