[Numpy-discussion] Change in the representation of complex numbers in NumPy 1.1
Francesc Alted
falted@pytables....
Fri Jul 4 02:17:27 CDT 2008
A Thursday 03 July 2008, Charles R Harris escrigué:
> On Thu, Jul 3, 2008 at 1:30 PM, Charles R Harris
> <charlesr.harris@gmail.com>
>
> wrote:
> > Hmm,
> >
> > On Thu, Jul 3, 2008 at 11:44 AM, Francesc Alted
> > <falted@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 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.
Well, I'm not sure about that. Technically, the '0.0' notation has been
chosen to diferentiate from zero integer '0'. However, all complex
types are 'floating point', so a '0j' representation refers clearly to
the complex type and there is not room for confusion here. In fact, I
prefer '0j' over '0.0j' representation (don't ask me why, but my guts
tell me that '0j' is more 'zero' than '0.0j' ;-)
Cheers,
--
Francesc Alted
More information about the Numpy-discussion
mailing list