[Numpy-discussion] ndarray methods vs numpy module functions

[Robert Kern]

On Tue, Jun 24, 2008 at 02:43, Sebastian Haase <haase at msg.ucsf.edu> wrote:
> On Tue, Jun 24, 2008 at 3:11 AM, Robert Kern <robert.kern at gmail.com> wrote:
>> On Mon, Jun 23, 2008 at 19:35, Ryan May <rmay31 at gmail.com> wrote:
>>> Robert Kern wrote:
>>>> On Mon, Jun 23, 2008 at 18:10, Sebastian Haase <haase at msg.ucsf.edu> wrote:
>>>>> On Mon, Jun 23, 2008 at 10:31 AM, Bob Dowling <rjd4 at cam.ac.uk> wrote:
>>>>>> [ I'm new here and this has the feel of an FAQ but I couldn't find
>>>>>> anything at http://www.scipy.org/FAQ .  If I should have looked
>>>>>> somewhere else a URL would be gratefully received. ]
>>>>>>
>>>>>>
>>>>>> What's the reasoning behind functions like sum() and cumsum() being
>>>>>> provided both as module functions (numpy.sum(data, axis=1)) and as
>>>>>> object methods (data.sum(axis=1)) but other functions - and I stumbled
>>>>>> over diff() - only being provided as module functions?
>>>>>>
>>>>>>
>>>>> Hi Bob,
>>>>> this is a very good question.
>>>>> I think the answers are
>>>>> a) historical reasons AND, more importantly, differing personal preferences
>>>>> b) I would file  the missing data.diff() as a bug.
>>>>
>>>> It's not.
>>>>
>>> Care to elaborate?
>>
>> There is not supposed to be a one-to-one correspondence between the
>> functions in numpy and the methods on an ndarray. There is some
>> duplication between the two, but that is not a reason to make more
>> duplication.
>>
> Are you saying the duplication is "just random" ?

No. If you want a clearer (but still imperfect) dividing line is that
all of the methods are implemented in C. numpy.diff(), for example, is
not. A lot of the C functions in Numeric's core (but not FFT, SVD,
etc.) got moved into methods, partly for implementation reasons
(ndarray is subclassable now, so methods are easier to make generic),
and partly for "it seemed like a good idea at the time." We couldn't
remove the functions, then, if we wanted any kind of continuity with
Numeric, and we certainly can't now.

> It would be better
> -- as in: principle of minimum surprise -- if there would be some sort
> "reasonable set" of duplicates ....
> If there are only a handful functions missing, why not try to make it complete.

There aren't.

> ( Again, a list of functions vs. methods on the wiki would clarify
> what we are talking about ....)

Go ahead.

> Just thinking loudly of course. Don't take this as an offense .....

It's not that you're being offensive, but you are kicking up dust on
an old argument that was settled before 1.0, when it actually
mattered.

-- 
Robert Kern

"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