[Numpy-discussion] ndarray methods vs numpy module functions

[Sebastian Haase]

On Tue, Jun 24, 2008 at 7:40 PM, Robert Kern <robert.kern at gmail.com> wrote:
> 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.

Just for the record: I like it the way it is. I did follow the
discussion at the time, and while there was a real (historical) need
to keep functions, there were arguments for supporting a two paradigms
and thus also having methods. "Numpy serves both people coming from
the Matlab/IDL community and people coming from (strict /
method-based) OO programming".

Regarding the OP, if he stumbled over this, like probably many other
"newcomers", it should go into the FAQ section. (at
http://www.scipy.org/FAQ )
("For implementation reasons some operations are only available as
functions or as methods respectively")

Cheers,
- Sebastian Haase