Worth considering switch to ndarray

[JonathanWoollett-Light]

Implementing functionality that would seem should already exist within a library (such as EMatrix and EVector for nalgebra in this case) I find often indicates you are incorrectly using a library.

Given the data is expected to be very dynamic with frequent updates to the inputs and outputs I do not believe nalgebra suits this use case. I don't think we would see a decline in performance with ndarray and it has all the functionality needed with ndarray_linalg and functionality such as ndarray::concatenate which nalgebra notably does not have. Avoiding implementing this missing functionality from nalgebra would simplify the project as whole.

I may create a fork for this and if this is something you're open to submit a pull request.

(I did some working with EMatrix to see how nice I could make it, and I couldn't get it nice enough to be satisfied, so that is what triggered this)

[nestordemeure]

I would be open to a pull request that would be a straight port to ndarray (it has been previously discussed, in particular if friedrich is to be integrated in linfa). When first developing the library I tested both and found I was missing some needed functionalities in ndarray (but it has since evolved so this might not hold anymore).

Note that it is fairly easy to concatenate nalgebra matrices, the EMatrix type is there to reduce memory allocations when doing regular concatenations (similarly to vectors in Rust, you do not want to allocate for every push as concatenating new rows would).

The main difficulty is that I believe some numerical algorithms are not available in ndarray (I contributed the nalgebra code to update a cholesy decomposition instead of recomputing it and there is work in another issue to introduce an infailible cholesky decomposition, which I believe would be a very nice useability step up for a GP). Those might have to be contributed to ndarray or reimplemented in friedrich.