[SciPy-Dev] QR-decomposition with Q but not Q

Martin Teichmann lkb.teichmann@gmail....
Thu Aug 11 13:01:08 CDT 2011

Hi list,
Hi Nathaniel,

> I was a little confused by your removing the scipy tril/triu
> functions. Certainly they're redundant with the ones in numpy, but
> does this have any consequences for compatibility? Do they need to be
> deprecated for a cycle first?

Well, yes. But I guess it's much simpler to just import them from
numpy, than repeating the code. Some "from numpy import triu, tril"
should do the job, I am just not sure where to put it.

> Does the "economic" versus "full" distinction still make sense when
> working with the reflectors?

No. The reflectors always have one fixed size. (Let me double
check that I got the right one...)

> IIUC, the two options you add are (1) get out the elementary
> reflections themselves, (2) get out the product of those elementary
> reflections with some matrix c. Wouldn't it make more sense to have
> just one option, for getting out the elementary reflections, and then
> have a separate function that let you compute the product of some
> elementary reflections with some matrix?

I thought about that too, and I am not sure.

I opted for the way I did it because I think it gives more readable code,
especially for beginners. You don't need to explain what elementary
reflectors are, and what to do with them. In theory, one could make
an entire object-oriented approach with a class that automatically does
the right job, but I think that's just overkill.

The problem that one might want to multiply with Q several times is
normally not an issue: in this case it is more efficient to calculate Q
and just use dot to do the multiplication. Only if Q is large and c is
small the internal multiplication is an advantage.



More information about the SciPy-Dev mailing list