[Numpy-discussion] Change in the representation of complex numbers in NumPy 1.1
Charles R Harris
Thu Jul 3 14:30:54 CDT 2008
On Thu, Jul 3, 2008 at 11:44 AM, Francesc Alted <email@example.com> wrote:
> Ok. But str also represents differently the 0j:
> In : str(numpy.complex64(0))
> Out: '(0.0+0.0j)'
> In : str(numpy.complex(0))
> Out: '0j'
> In addition, I find the new representation not too nice looking:
> In : str(numpy.complex128(5/3j))
> Out: '(0.0+-1.66666666667j)' # note the '+-' thing
> In : str(numpy.complex(5/3j))
> Out: '-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 : str(numpy.complex64(0))
In : str(numpy.complex128(0))
In : str(numpy.complex192(0))
In : str(numpy.complex(0))
In : type(numpy.complex(0))
Out: <type 'complex'>
In : type(numpy.complex128(0))
Out: <type 'numpy.complex128'>
In : ones(1, numpy.complex)
Out: array([ 1.+0.j])
Unless it is used as a dtype:
In : ones(1, numpy.complex).dtype
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Numpy-discussion