[Numpy-discussion] LA improvements (was: dot function or dot notation, matrices, arrays?)

David Goldsmith d.l.goldsmith@gmail....
Wed Dec 23 13:19:02 CST 2009

On Wed, Dec 23, 2009 at 10:30 AM, David Warde-Farley <dwf@cs.toronto.edu> wrote:
> On 23-Dec-09, at 10:34 AM, Anne Archibald wrote:
>> It's been a little while since I took a really close look at it, but
>> I'll try to describe the problems I had. Chiefly I had problems with
>> documentation - the only way I could figure out how to build
>> additional gufuncs was monkey-see-monkey-do, just copying an existing
>> one in an existing file and hoping the build system figured it out. It
>> was also not at all clear how to, say, link to LAPACK, let alone
>> decide based on input types which arguments to promote and how to call
>> out to LAPACK.
> I tried to create a new generalized ufunc (a logsumexp to go with
> logaddexp, so as to avoid all the needless exp's and log's that would
> be incurred by logaddexp.reduce) and had exactly the same problem. I
> did get it to build but it was misbehaving (returning an array of the
> same size as the input) and I couldn't figure out quite why. I agree
> that the documentation is lacking, but I think it's (rightly) a low
> priority in the midst of the release candidate.

Thanks Anne (and Dave): it may seem to you to be "a bit silly to dream
up an API without implementing anything," but I think it's useful to
get these things "on the record" so to speak, and as a person charged
with being especially concerned w/ the doc, it's particularly
important for me to hear when its specific deficiencies are
productivity blockers...

>> The key idea would be that the "linear
>> algebra dimensions" would always be the last one(s); this is fairly
>> easy to arrange with rollaxis when it isn't already true, would tend
>> to reduce copying on input to LAPACK, and is what the gufunc API
>> wants.
> Would it actually reduce copying if you were using default C-ordered
> arrays? Maybe I'm mistaken but I thought one almost always had to copy
> in order to translate C to Fortran order except for a few functions
> that can take row-ordered stuff.
> Otherwise, +1 all the way.

...and of course, discussing these things here begins a dialog that
can be the beginning of getting these improvements made - not
necessarily by you... :-)

Thanks again, for humoring me


More information about the NumPy-Discussion mailing list