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

[Robert Kern]

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.

+1

-- 
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