While that library might “just work” since it seems pretty vanilla, it has a ton of code you might not really need for things like chol, QR, eigenvalues etc. depending on exactly what kind of inverse you want to compute.
The other choice might be the GNU Scientific Library (gsl) which I think you will find might be too large for your needs.
And then there has been some interest in the ARM-specific CMSIS-DSP which looks closer to what you need.
I don’t know of anyone who has these working on Particle devices, but they are all possible depending on your time and energy.
There may be other ways to do what you want:
Can you say how large are your matrices? There is a big difference between 3x3 or 4x4 and 10x10!
What are you trying to do with the matrix inverse? Do you know anything special about the matrix (symmetry, condition number, etc.)?
It helps to know if you really need the determinant scaling (multiply by 1/det(A)) since not every application does. If you do need it, that is just another algebraic expression but it roughly doubles the amount of arithmetic you have to do.
The library you are using looks very straight-forward and simple. I would just stay away from dynamic allocation (calling new or constructing matrices on the stack) to avoid memory problems.
And @msolters I am not sure I get the ski instructor from Southpark–am I missing a “bad time” joke or something?
It’s just a snarky way of conveying that if you are trying to do matrix inversion in an embedded environment, in general, “you are going to have a bad time.” I certainly wasn’t trying to call “rank.” (heh)
As you said – it would be better to find some mechanism that would allow these systems to be reduced to a smaller set of sub-calculations rather than bust out the big guns!
On a different note is there an easy modification I can make to the library so that the overloaded operators will work with different types? I get the error below when I try, I tried googling but I don’t think I know the correct terms to search for…
error: no match for 'operator-' (operand types are 'QSMatrix<int>' and 'QSMatrix<double>')
I think you have two matrices defined, one that has floating point numbers (1.0 3.14 etc.) and one that has only integers (1, 2, 3, etc.). You probably have something written as 1, 2, 3 and you should change it to 1.0, 2.0, 3.0 to be sure to get floating point numbers (either float or double in C/C++).
I took the CMSIS math library and I am using it to do FFT on audio. While you can do f32 which on the Photon will be done in software. You can also choose to use one of the Qx.y formats.
I am using Q15 for my project and it is much fast then f32. as it uses normal integer math. I have not use the Matrix functions in the math lib, They do have them and they will probably compile for the M3.
I had to put all the files in my project including the .h which are in the build somewhere but no the correct version for the library I found. I also had to put this at the top of arm_math.h to solve some compile issues
#undef A0 #undef A1 #undef A2
Actually it would be nice to include these in the actual build libraries. (hint any Particle employees)