# Computing Inverse of a stack of matrices

**URL:** <https://discourse.julialang.org/t/computing-inverse-of-a-stack-of-matrices/45580>\
**Category:** General Usage\
**Tags:** performance, linearalgebra\
**Created:** [August 26, 2020, 4:23pm UTC](https://discourse.julialang.org/t/computing-inverse-of-a-stack-of-matrices/45580 "2020-08-26T16:23:17Z")\
**Posts on this page:** 1\
**Showing post:** 19

<div class="post-metadata">

**Author:** ![tchr](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tchr/32/15138_2.png) [@tchr](https://discourse.julialang.org/u/tchr)\
**Post date:** [August 29, 2020, 2:35am UTC](https://discourse.julialang.org/t/computing-inverse-of-a-stack-of-matrices/45580/19 "2020-08-29T02:35:42Z")

</div>

> I think the reason it has the extra parameter is that a lot of algorithm cutoffs are based on the number of elements in the matrix, so being able to get that directly from the type domain probably saves a multiplication in a decent number of places.

This may be a nice incidental advantage to having `L` (… though constant propagation could make the point of such benefits moot?) but I think the fundamental reason is that an `SMatrix{N,M,...}` is backed by an `NTuple{N*M, ...}`: since you can’t currently do arithmetic with type parameters/`TypeVar`s ([#18466](https://github.com/JuliaLang/julia/issues/18466)) in struct constructors, this forces the existence of the otherwise redundant `L`.

---

_[View the full topic](https://discourse.julialang.org/t/computing-inverse-of-a-stack-of-matrices/45580)._