[Numpy-discussion] Vote: complex64 vs complex128

[Charles R Harris]

I can't get worked up over this one way or the other: complex128 make sense
if I count bits, complex64 makes sense if I note precision; I just have to
remember the numpy convention. One could argue that complex64 is the more
conventional choice and so has the virtue of least surprise, but I don't
think it is terribly difficult to become accustomed to using complex128 in
its place. I suppose this is one of those programmer's vs user's point of
view thingees. For the guy writing general low level numpy code what matters
is the length of the type, how many bytes have to be moved and so on, and
from the other point of view what counts is the precision of the arithmetic.

Chuck

On 4/4/06, Colin J. Williams <cjw at sympatico.ca> wrote:
>
> Sebastian Haase wrote:
>
> > Hi,
> > Could we start another poll on this !?
> >
> > I think I would vote
> > +1  for complex32 & complex64  mostly just because of "that's what I'm
> > used to"
>
> +1 Most people look to the number to give a clue as to the precision of
> the value.
>
> Colin W.
>
> >
> > But I'm curious to hear what others "know to be in use" - e.g. Matlab
> > or IDL !
> >
> > - Thanks
> > Sebastian Haase
> >
> >
> >
> > Travis Oliphant wrote:
> >
> >> Sebastian Haase wrote:
> >>
> >>> Tim Hochberg wrote:
> >>> <snip>
> >>>
> >>>> This would work fine if repr were instead:
> >>>>
> >>>>    dtype([('x', float64), ('z', complex128)])
> >>>>
> >>>> Anyway, this all seems reasonable to me at first glance. That said,
> >>>> I don't plan to work on this, I've got other fish to fry at the
> >>>> moment.
> >>>
> >>>
> >>>
> >>> A new point: Please remind me (and probably others): when did it get
> >>> decided to introduce 'complex128' to mean numarray's complex64
> >>> and the 'complex64' to mean numarray's complex32 ?
> >>
> >>
> >> It was last February (i.e. 2005) when I first started posting
> >> regarding the new NumPy.   I claimed it was more consistent to use
> >> actual bit-widths.   A few people, including Perry, indicated they
> >> weren't opposed to the change and so I went ahead with it.
> >>
> >> You can read relevant posts by searching on
> >> numpy-discussion at lists.sourceforge.net
> >>
> >> Discussions are always welcome.  I suppose it's not too late to
> >> change something like this --- but it's getting there...
> >>
> >> -Travis
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > language
> > that extends applications into web and mobile media. Attend the live
> > webcast
> > and join the prime developer group breaking into this new coding
> > territory!
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> > _______________________________________________
> > Numpy-discussion mailing list
> > Numpy-discussion at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20060404/94e5c02e/attachment.html>