[Numpy-discussion] Re: Vote: complex64 vs complex128

Robert Kern robert.kern at gmail.com
Tue Apr 4 13:06:01 CDT 2006

Tim Hochberg wrote:
> Robert Kern wrote:

>> I think it's time that we start taking backwards compatibility with
>> previous
>> releases of numpy seriously and not break numpy code without clear,
>> significant
>> gains in usability.
> So what does that mean in this case? The current status; nice for
> existing users of numpy. Or, the old status, nice for people
> transitioning to numpy from Numeric. It's hard to know which way these
> backwards compatibility arguments cut when they involve reverting a
> change from some old behaviour.

I mean numpy. Neither complex64 nor complex128 are backwards-compatible with
Numeric. Complex32 and Complex64 already exist and are hopefully isolated as
compatibility aliases for typecodes.

By backwards-compatibility, I refer to code, not habits.

> I've got an idea. Rather than go round and round about complex64 versus
> complex128, let's just leave things as they are and add a docstring to
> complex128 and complex64 explaining the situation. [code...code...]
>     >>> help(complex128)
>    class complex128scalar(complexfloatingscalar, complex)
>     |  complex128: composed of two 64 bit floats
>     |
>     |  Method resolution order:
>     |      complex128scalar
>     |      complexfloatingscalar
>     |      inexactscalar
>     |      numberscalar
>     |      genericscalar
>     |      complex
>     |      object
>    ...
> I someone wants to give me some better text for the docstring, I'll go
> ahead and commit this change. Heck if you've got some text for the other
> scalar objects (within reason) I'll be happy to add that at the same time.


Robert Kern
robert.kern at gmail.com

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

More information about the Numpy-discussion mailing list