[Numpy-discussion] add .H attribute?

Nathaniel Smith njs at pobox.com
Mon Jul 22 15:10:42 EDT 2013


On Thu, Jul 18, 2013 at 3:18 PM, Stéfan van der Walt <stefan at sun.ac.za> wrote:
> On Sat, Jul 13, 2013 at 7:46 PM, Nathaniel Smith <njs at pobox.com> wrote:
>> Why not just write
>>
>> def H(a):
>>     return a.conj().T
>
> It's hard to convince students that this is the Best Way of doing
> things in NumPy.  Why, they ask, can you do it using a' in MATLAB,
> then?

I guess I'd try to treat it as a teachable moment... the answer points
to a basic difference in numpy versus MATLAB. Numpy operates at a
slightly lower level of abstraction. In MATLAB you're encouraged to
think of arrays as just mathematical matrices and let MATLAB worry
about how to actually represent those inside the computer. Sometimes
it does a good job, sometimes not. In numpy you need to think of
arrays as structured representations of a chunk of memory. There
disadvantages to this -- e.g. keeping track of which arrays return
view and which return copies can be tricky -- but it also gives a lot
of power: views are awesome, you get better interoperability with C
libraries/Cython, better ability to predict which operations are
expensive or cheap, more opportunities to use clever tricks when you
need to, etc.

And one example of this is that transpose and conjugate transpose
really are very different at this level, because one is a cheap stride
manipulation that returns a view, and the other is a (relatively)
expensive data copying operation. The convention in Python is that
attribute access is supposed to be cheap, while function calls serve
as a warning that something expensive might be going on. So in short:
MATLAB is optimized for doing linear algebra and not thinking too hard
about programming; numpy is optimized for writing good programs.
Having .T but not .H is an example of this split.

Also it's a good opportunity to demonstrate the value of making little
helper functions, which is a powerful technique that students
generally need to be taught ;-).

-n



More information about the NumPy-Discussion mailing list