<rcurtin[m]>
I didn't run it myself, do you want me to?
<rcurtin[m]>
the results you pasted seem reasonable; I don't think that Armadillo would replace pinv(pinv(A)) with A (I'm actually not sure that is even valid. it would be for inv(inv(A)), but I also don't know if Armadillo would optimize that out)
<rcurtin[m]>
Ahh, thanks. My guess then is just that it's not implemented on the grounds of "nobody would ever write code like that"
<rcurtin[m]>
I don't know if Conrad would accept a patch for it, but you could see what he thinks. My prior probabilities are about 50% on whether he'd accept it, but with very high variance 😃
<ShubhamAgrawal[m>
<rcurtin[m]> "I don't know if Conrad would..." <- Actually I don't know how to write these rules
<rcurtin[m]>
yeah, I think the first thing would be to ask him if he's interested and where he would suggest doing that
<rcurtin[m]>
for that one, my guess is in fn_pinv.hpp... you write another overload of pinv() and specialize on the argument type. I think it would be something like this ...
<rcurtin[m]>
so, when we get an `Op<T1, op_pinv>` as an argument to pinv(), then the user has given something equivalent to `pinv(pinv(X))`, and instead of returning `Op<Op<T1, op_pinv>, op_pinv>`, we just want to return that `T1` on the inside
<ShubhamAgrawal[m>
rcurtin[m]: How do I contact him? I dont see him here