LSL scripting: matrix type

I already put this in the suggestion tracker, but who reads that? If you actually like the idea, vote for MISC-220 in Jira.

I'd like to request that LSL support matrix types at least up to 6x6, and their associated row and/or column vectors, as well as the matrix arithmetic operators to work with them. This would allow for simulations of robotic arms and the like to work much faster without changing the language in any significant way. Once Mono is implemented, the operations could be implemented in native assembly language libraries for maximum speed.

A current implementation using these types within LSL would be dozens of times faster than doing it by hand, and a native implementation of the matrix operations would likely be thousands of times faster than LSL, and would open up all sorts of new possibilities for hobbyist and professional scripters and researchers of various kinds.

I'd like to see the matrix as well, though I disagree with limiting it to 6x6.
I've had a use for a 10x10x10x5 once.

Dude, that's nuts!!! I'd LOVE to see why you'd need such a thing

I think that the 80% case would easily be met with Matrix3 and Matrix4 types, and probably 99% would be able to use up to a 6x6 I would think.

I would be interested in seeing how this would work from a call-level interface POV. For instance, how would you define a 4x4 matrix? How would you set or retrieve a value in a matrix in LSL?

I'll check out the Jira issue, I'd dearly love to have matrix operations and types in LSL.

.

Would this not just be a multi-dimensional array? ie; you declare array[6][6] to get a 6 x 6 array. Then if you want to retrieve a value on row 3, column 2 you would do array[3][2]?

Arrays (single or more dimensional) are something I'd love to see in SL, because lists just aren't ideal at all, and aren't especially efficient for searching or storing, whereas an array of integers is exactly the same as having all those integers as separate variables, but they can be iterated over easily using a counter.

If it was done right you could also remove single rows from your matrices by doing array[3] for the entire third row (result in this case is an array with an element for each column in that row). But it would not have functionality for matrix columns, however having arrays in the first place would have you mostly set by this point, a little work to retrieve columns wouldn't be as bad.

Yes...I'd say an array would be the best implementation...

...and man...I would kill for arrays.

Admittedly I could have probably done it more simply, but it was for a simple game that was to find a location in a 10x10x10 grid and you had 5 chances, each guess giving you an relative distance to the mark (via 3 dimmentional distance forumla).

I used the array to track spheres of intersection. As I was working with a consol (i.e. text) only output I had to display the data in a form that could be represented in text. I chose to use a 10x10x10 array for each location in the game grid, and set it to be boolean values: was that room intersected by one of the distance spheres? And as bool only held 1 and 0 I needed x5 of them to hold the 5 guesses (actually, ony x4 as the fifth guess was right or wrong the game was over and there was no need to display the map, but I did it anyway just as a point of curiosity).

So I ended up managing a 10x10x10x5 boolean array.

I suppose I could have done it as a 10x10x10 int array, but I think that'd have used more data space (1/5 as many values at 8 times the size).

Recently I decided to take the game to Flash and managed to do it with a 3x5 matrix (x,y,z coords for 5 guesses as I can draw the circles on demand).

Well, it would be extremely nice to have arrays, I would certainly vote for that too. But I'd be even *MORE* excited about being able to perform matrix operations on arrays

Yeah. Matrix arithmetic is how you do robotic simulations. M3 = M1 * M2 is a heck of a lot simpler than writing the whole thing by hand. I know that you could write an LSL script to implement it, but a robot controlled using that script would, at best, look like a guy dancing The Robot. Imagine what kind of class projects for engineering you could do if you had matrix algebra available.

Defining a matrix as a list of vectors isn't a big deal, as long as vectors are extended to whatever size you need (6x1 for your sci-fi level robotic arm), though extracting the info from the list for a column vector would slow you down a lot if column vector weren't a native type.

For me, square matrix and the equivalent column and row vector data types, and matrix/vector algebra to support them, plus matrix transpose, would be sufficient. to allow robot simulations. Anything that I've missed? What else is needed to make the matrix type worth using? Rectangular matrices as well as square? Function calls to engineering libraries? What should the engineering libraries have? Adding this stuff would be trivial compared to the problems that they face daily, IMHO, so unless there are lag issues due to calculations, there shouldn't be a problem. If there ARE lag issues, maybe they can offload calculations to the client of any avatars in the sim for distributed processing.


The jira suggestion/bug report for this is found at:

https://jira.secondlife.com/browse/MISC-220


You may need to log in separately to vote. Pass the idea along to your friends if you think it is worth it.

Bump.

I like the idea but I don't think anything will happen until mono comes along.

Mono isn't coming along, though. Last time I read anything, it was a "far future" project. Adding the *syntax* for arrays would be trivial. Behind the scene they would be nxm lists with only one type (non-list) allowed. A matrix would be a special type of array with only numeric values allowed.

Behind the scenes, it would all be standard list-processing for LSL. There's a complete set of list functions that someone whipped up that does almost everything I want, array-wise, for matricies, but they are quite cumbersome to use, and don't handle the arithmetic end. Arrays would do just fine, with matrix operators defined for arrays of reals.

I want to be able to type in:

array real M1 [6][6] =...;
array real M1 [6][6] =...;
array real M1 [6][6];
M3 = M2 * M1;

and get the right results. Even if it's kludgey LSL behind the scenes. Once mono is implemented, everything can be made efficient on the compiler side, and even native libraries could be called for something so well-defined, but there is NO reason why the syntax can't be implemented right now.

No need to wait for mono to define syntax, since mono is years out, from what I have read.


Don't forget to vote on the idea, if you like it.