History
Matrixy was an Octave/Matlab clone that I had started working on a while ago when I first got involved with Parrot. I had been working on it idly while still in school, but never made it very far because of my lack of knowledge at the time and my other commitments (like, school). I got in contact with a guy named Blair from the UK who was interested in working on the project, and together we set up a project page on Google Code to pursue it.
For a while things moved pretty quickly and we were able to implement many of the idiosyncratic features of that language reasonably well. Blair also did some great work writing bindings for CLAPACK and CBLAS, so Matrixy has reasonable linear algebra support (although many operations just haven't been implemented yet) through those libraries.
However, things eventually slowed down. Blair started working on some changes to function dispatch that would enable variable function parameter lists and variable function return lists. Because of his work in this area, I held off on some of my own dispatch-related work, and started focusing on Parrot proper. Long story short, Blair got stymied by some bugs in Parrot which also happened to be things that I was blocking on (PCC refactors being a good example), and development on Matrixy stopped completely. Yesterday I fixed a few small things, but that's hardly the same as the project being active.
Current Status
Despite the fact that Matrixy isn't being as actively developed now as it has been in the past, it still has and supports a number of important language features. Not all of the implementations are as good or as efficient as they should be, but they do exist. Here's a quick rundown:
- Support for variables, scalars, and matrices, and most of the operators that act on those things. This includes automatically-growing matrices, autovivification, basic matrix operations, and functions that can tell whether a value is a matrix, a vector, or a scalar. 2-D matices only.
- Support for basic string operations, string printing, string concatenation
- Nearly-proper handling of semicolons to print statement values
- Nearly-proper disambiguation between variables and functions using parenthesis
- Proper runtime loading of library functions from files. So the function foo() will be automatically found and loaded from file foo.m
- if/then/else, for loops, maybe some other control structures too that I can't remember.
- Ranges and iterators using ..
- Calls to system commands using !
- handing of path search locations
- Function handles and anonymous functions
- Complex numbers
- try/catch
- Several library functions written in PIR and M.
- Help functions to read documentation from M files
The Path Ahead
There are obviously more things that we need: cell arrays, structures, nargin/varargin/nargout/varargout, and others. We also need to find some kind of graphics package to tap into eventually that will enable us to implement some of the graphing functions. There are hundreds of other functions as well that need to be implemented and tested, more then I would be able to name here.
At the moment Matrixy only works with a development Parrot, it needs to be made to work with an installed Parrot (or both, if possible).
It needs to be better tested and several corner cases need to be stabilized.
And I really think that we need some significant internal refactors for a variety of systems and functions. I would love to even rewrite some of the PIR parts in Close, if I was able to do that.
I would like to separate it out into two separate (but related) projects: the Matrixy compiler itself, and the linear algebra libraries that could be reused by other languages to gain immediate, powerful, linear algebra support.
Overview
So that's a general overview of what Matrixy is, what it's current state is, and where I think development is headed. I don't think I will be focusing much of my effort on it in the near-term because of other tasks I want to work on for Parrot, and other things I have going on in real life. However, I will be dabbling on it here and there, and would like to get other developers interested in working on it too. No reason why it shouldn't be progressing just because I am not devoting a lot of time to it.
Hello,
ReplyDeleteRather late in the day, but what was your performance like? Parrot is really nice for dynamic languages, is it great for numerical intensive languages? I guess many intensive algos will be done via BLAS, so that's okay, but what about algorithms written in Matrixy itself? How was the performance of that?
Much thanks(you can mail me at saptarshi DOT guha AT gmail DOOT com)
Saptarsi
Hello,
ReplyDeleteI have one more question, regarding MatrixXY. Could you update the build process to work with Parrot 1.6? It doesn't seem to run.
Regards
Saptarshi
Hello Sapsi, thanks for the comments.
ReplyDeleteThe performance of Matrixy wasn't that great. However, much of the performance issue was because of naive parsing and lots of hack-around work that we had to do to get certain things working. We have a profiling tool now in Parrot that could be used to improve performance significantly though, so maybe that's something we could work on.
But you are right, most of the intensive numerical calculations were done in BLAS, although we did have to do some expensive stuff to get arguments from Parrot into BLAS matrices. On thing that I would like to do later if we have a chance would be to create a PMC type in C that handles multidimensional arrays in the same format that is expected by BLAS. That would save us from performing expensive structure translations.
Also, Matrixy never worked with an installed Parrot, you need to configure and build matrixy from inside the Parrot build directory. This is another issue that we need to fix. I'll post a guide on the website about how to do this.