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

Tim Hochberg tim.hochberg at cox.net
Tue Apr 4 12:52:04 CDT 2006


Robert Kern wrote:

>Joe Harrington wrote:
>  
>
>>When I first heard of Complex128, my first response was, "Cool!  I
>>didn't even know there was a Double128!"
>>
>>Folks seem to agree that precision-based naming would be most
>>intuitive to new users, but that length-based naming would be most
>>intuitive to low-level programmers.  This is a high-level package,
>>whose purpose is to hide the numerical details and programming
>>drudgery from the user as much as possible, while still offering high
>>performance and not limiting capability too much.  For this type of
>>package, a good metric is "when it doesn't restrict capability, do
>>what makes sense for new/naiive users".
>>    
>>
>
>I'm pretty sure that when any of us say that such-and-such is going to make the
>most sense to new users, we're just guessing. Or projecting our experienced-user
>prejudices onto them. If I had to register my guess, I would say that either way
>will make just as much sense to new users.
>  
>
Agreed.

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

Regards,

-tim








More information about the Numpy-discussion mailing list