Andreas Borgen Longva

Btw, if we define `QR` as a tuple struct, we should be able to do: ``` let QR(q, r) = A.qr().unwrap(); ``` **but** that assumes that `q` and `r` correspond...

Could you perhaps sketch out some pseudocode that demonstrates roughly what you have in mind? I'm not sure if I'm quite following! And yeah, I'm all for exploring :)

Thanks for elaborating! I think I see what you mean now. If I understand you correctly, the key point of your proposal is that we get to collect related functionality...

I'd also like to point out that both the Q and R matrices of QR can be stored in a single matrix (see for example [here](http://stackoverflow.com/questions/3031215/mystified-by-qr-q-what-is-an-orthonormal-matrix-in-compact-form)). This is also the...

I think we could actually reimplement _all_ decompositions as structs now, but keep the current functionality. I.e. for QR, we internally just store the current `Q` and `R` matrices that...

> I also agree with this - but I'm not sure how consistent we can have the API across each decomposition. For example part of the benefit of this approach,...

@AtheMathmo: I can see if I have some time this week and look into creating a preliminary PR. Might make it easier for us if we have something more tangible...

Great, just wanted to clarify what I had in mind. Thanks for the headsup, and enjoy your vacation! :)

Having considered this a bit longer, I'm actually not sold on the utility of the `eigen()` organization. I really cannot see any clear benefits to it compared to simply `matrix.eigen()`...

So, if I understand you correctly, then the idea is to expose direct wrappers around the Lapack functions, such as for example `mat.eigen().sorgtr()`? (Just to take an arbtirary example) In...