[PYTHON MATRIX-SIG] Last complaints about NumPy 1.0a5

[Jim Hugunin]

> Reading David's excellent tutorial has made me aware of a few
> peculiarities that I had forgotten, and which should be cleaned
> up before the beta release:
> 
> 1) where() is just a special case of choose() and should be
>    eliminated.

I find that almost everybody I've explained it to understands the where
function.  For some reason the increased generality of choose is confusing
to many people.  So I plan on leaving the where function in.  It serves the
same purpose as sum == add.reduce and similar convenient abbreviations.

I do see the value in making the seperation a little bit mnore clear in the
tutorial between core functions and convenience functions.  If you look at
my own docs you'll see that I went out of my way to make this point.

> 2) compress() is just a special case of repeat() and should be
>    eliminated.

Similarly for compress, the main addition is that it makes sure the
arguments are either zero or one before doing the repeat operation and this
is just a lot easier for some people to understand.

> 3) binarysearch() should be called just search(), or find().
>    The name of a function should not indicate the algorithm
>    that is uses, however obvious the choice of the algorithm
>    is.

Frederick's point that this function name helps to make it clear to people
that this function requires a sorted array is my original reasoning.  I've
always been a little bit concerned that this function can be easily misused
by naive users and there's no efficient way to detect an error if it's used
on an unsorted array.  So, the very specific name I think is helpful here.

> 4) I am a bit confused about the exact meaning of the parameters
>    to diagonal() and trace(). Shouldn't that simply be to integers,
>    indicating the two axes along which the diagonal is constructed,
>    and defaulting to -2 and -1?

I think you're right about this one.  If you were to give me a better
implementation of diagonal that works as you describe I'd be happy to use
it.  (Although I do think that the proper choice of arguments for the nd
case is a tuple of two OR MORE integers specifying the axes along which to
take the diagonal).

> 5) There's dot() and matrixmultiply(). Dot() does something for which
>    I have never found a direct need, and which anyway should not be
>    called dot() because it doesn't work like what linear algebra
>    users expect dot() to mean. How about having just dot() with a
>    useful generalization of the dot product, i.e. summing along
>    the last axis of the first and the first axis of the second argument?
>    (I think we have discussed this before, but I don't remember
details...)

In case you haven't noticed as we've worked on this for the past year, for
some reason I really dislike any generalizations I've seen of the
innerproduct.  This is the basic reason why the is no "inner" method on
ufuncs.  I'm personally quite happy with how things are currently defined
now, and for all of my matrixmultiply-like tasks, I find dot is the way I
think about the world.

On the other hand I understand your complaints.  I'll think about this one
(yet again), any other comments on this issue would be appreciated.

-Jim

PS - I somehow doubt that these are truly your last complaints, not that
I'd want it any other way ;-)


=================
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================