If the inverse of a matrix is your final result, rather than some intermediate calculation, it might still be possible to use \ (and, at least in some cases, advantageous):
julia> A = rand(10,10) julia> @time inv(A) elapsed time: 0.002185216 seconds (21336 bytes allocated) julia> @time inv(A) elapsed time: 0.000202789 seconds (7536 bytes allocated) julia> @time A\eye(10) elapsed time: 0.000117989 seconds (3280 bytes allocated) julia> @time A\eye(10) elapsed time: 0.000117989 seconds (3280 bytes allocated) I show the timings twice to illustrate the kind of weird behavior that the second time inv(A) is called, it’s 10x faster and allocates only a third of the memory (which is from the third time on consistent). These measurements are after precompilation (using different matrices of the same size, i.e. inv(rand(10,10)) and rand(10,10)\eye(10) to eliminate any caching or other magic), so it’s not JIT-ting. Anyone got any ideas here? Also, the results aren’t exactly equal: inv(A) == A\eye(10) returns false. However, that’s just floating point inaccuracies - all(map(isapprox, inv(A), A\eye(10)) returns true. I can’t vouch for which result is closer to the mathematically exact correct matrix inverse - it probably depends on the input. // T On Thursday, July 17, 2014 10:11:10 AM UTC+2, Tobias Knopp wrote: Indeed it is one of the first things one learns in numerical lectures that > one has to avoid explicitely calculating an inverse matrix. > Still, I think that there various small problems in geometry where I don't > see an issue of invering a 2x2 or 3x3 matrix. It depends, as so often, a > lot on the context. When considering not so well posed problems it is quite > essential to take regularization into account. A simple x = A\b would not > produce satisfying results in those cases. > > Am Donnerstag, 17. Juli 2014 06:25:27 UTC+2 schrieb Stefan Karpinski: >> >> It's a bit of numerical computing lore that inv is bad – both for >> performance and for numerical accuracy. It turns out it may not be so bad >> <http://arxiv.org/pdf/1201.6035v1.pdf> after all, but everyone is still >> kind of wary of it and there are often better ways to solve problems where >> inv would be the naive way to do it. >> >> On Wed, Jul 16, 2014 at 3:59 PM, Alan Chan <[email protected]> wrote: >> >>> any reason of avoiding inv? >> >> >>
