lichtkind

As you can see in the Changefile, there is a lot stuff coming in the next release of Math::Matrix, the de facto standard for now for Perl 6 Matrix Math, as mentioned in the docs. However, I have further plans I want to announce here and also ask my readers if I should do the proposed change of name space or not. This should be maybe a lightning talk in at TPC in Riga, but I already have a regular and a lightning there, so I choose this format.

1. feature set: We already have a lot of features but like with any lib, there are the nice to have's and the important ones, that do the mainline work and are not easy to get right. These are IMO dot product, invert, determinant, a solve method and the decompositions. That is why I see the aim of the lib not in implementing the numerically fanciest algorithms for number crunching but to have your tools to do an PCA or geometric work. Stuff you do need for scripting in the math world. Thus I see the lib as feature complete when we also have a solve, an eigenvalue decomposition (EVD), single value decomposition (SVD) and an QR decomposition and maybe and least square solve for overdetermined systems.

2. Change of repo. As pierre is out of the project for a long time I will move into my name space on github. When doing so I should then migrate to assixt and thus upload also to CPAN.

3. Change of name. This will be a good moment to think about the name of the module. Most of the reasons will come in the subsequent chapters but as a gist: you can not really separate Matrix from Vector math and there are some other tools and utils handy, that IMO should bundle together with a matrix lib and are not that much overhead code wise and the user will still be free how much he wants to use. That's why Math::Matrix::Bundle is of my liking.

4. Vector lib. There is already the one made by colomon. Since this is open source, nothing can prevent me to just include it in my distro. For type interoperability reasons, also for coherent testing etc. i want to to swallow it and only change the API when I strongly must, which I do not have a reason for now.

5. Matrix Array lib. I know, jnthn does a lot of wonderful optimization work, but you don't always need a matrix object. Even most attributes are computed lazily, there are a lot of them, since we already have many features. Maybe it is a braino, but currently like the idea being able to do the basic matrix math with bare bones arrays of arrays. It would help to put these functionality in an own package and thus organize this growing code base a bit. It would be also useful internally. While computing a matrix in several steps, the lib creates Math::Matrix objects on some of them, just to throw them away in the next line. You could ask why I created the objects in the first place. Because I wanted reuse the methods available to get robust and readable code. Same happens when using several methods on an matrix object in a row. When I have an AoA matrix package I would have reusable methods that do not create matrix objects, that I have to trow away the next millisecond.

You can write me here or per mail for any comment or start an issue on github.

Thanks