I think the current interface of left_orth and right_orth (and probably also the null equivalents) could use some improvements, mainly for the following kinds of issues:
- Since the output is allocated before the algorithm/decomposition type is selected, it is possible to run into issues when different decompositions require different output types. This already shows up with the
DiagonalAlgorithm implementations, where a polar decomposition would in general not have a diagonal output type because of the current implementation, while a qr does have that.
- Preselecting an algorithm to pass on to
left_orth additionally requires you to select a kind, and then also make sure to fill out the correct alg_kind = ... keyword, which seems rather unpractical, as that in principle requires you to keep track of kind, alg_qr, alg_polar, alg_svd and select values for that, even though only one of them might be used.
I'll try and come up with an improved interface to address these over the next couple days.
I think the current interface of
left_orthandright_orth(and probably also thenullequivalents) could use some improvements, mainly for the following kinds of issues:DiagonalAlgorithmimplementations, where a polar decomposition would in general not have a diagonal output type because of the current implementation, while a qr does have that.left_orthadditionally requires you to select akind, and then also make sure to fill out the correctalg_kind = ...keyword, which seems rather unpractical, as that in principle requires you to keep track ofkind, alg_qr, alg_polar, alg_svdand select values for that, even though only one of them might be used.I'll try and come up with an improved interface to address these over the next couple days.