Arrays!!! and/or Matricies!

I just thought of this. LSL seriously needs arrays! It would simplify so many things. With an array, you could easily design a game(checkers?) or have a series of movements to follow, or easily store user info.

If your array is what I think of as a hash, then I agree, its addition would be a Good Thing.

Let's let 'em fix the current list problems first tho, eh? =)

How many dimensions do you need for your array? What functionality are looking to gain from it over the current list system?

I wrote a few methods a while ago to support up to three dimensional arrays using a list, a vector to describe the place in the 'array' and math posted by someone else.

I have considered writing some various structure methods to handle lists of data sets (for example lists of addresses where an address is a number and a street, as opposed to a list of numbers and streets seperate or something).

Looking for something more? Maybe I can help you work out a system within the existing game structure, or write some helper methods for you.

Oh and #!, I may be thinking wrong but I think a hash is a more complicated form of an Array. Or an array that follows more rules. An array is really just a single data type list (all integers or all floats or all strings etc) but can also be multidimensional (the main reason for people asking them in the past). By multidimensional I mean you can have an array that is 3 wide and 2 tall I guess (small array!) so data could be:
5 7 8
3 4 2

And elements are accessed like this myArray[j] I think. Also most systems use static arrays - they are declared to be a certain size and that size never changes.


A Hash uses an array and a hashing function to place things into that array. The hashing function can be used to quickly find things in the array. It is faster than just looking through a list, or even a binary search through a sorted list. However it is very slow if you will be displaying the items in order. And care has to be taken with the hashing function or you will get lots of collisions and that can slow things down too.

Thats what I remember, but I took data structures about 3 years ago so I may be off.

list2csv csv2list enable multidims. Or multidims of multidims. Or multimulti...etc.

Walk in isn't hard. Check for comma delim. If exists in a llList2String, you have a dim.

I use this a lot. Hope they fix the llList2Leak soon.

Tcoz.

Ama,

In perl (my only frame of reference) there are arrays and hashes.

Arrays are just like lsl's lists, except the elements do not have to be the same data type.

(all examples following are perl code -- do not attempt in LSL, folks)

Hashes are
%hash = ("Fred" => "Flintstone";
"Barney" => "Rubble";
"Wilma" => "Flintstone"

There are also multi-dimensional arrays:

@CartoonFamilies = (
[ "fred", "wilma", "pebbles" ],
[ "george", "jane", "elroy" ],
[ "homer", "marge", "bart", "lisa", "maggie"],
)

Which are referenced $CartoonFamilies->[2][3]

And hashes of arrays, and.. and.. and... =)

I had a point somewhere, but I seem to have lost it. Anyone got a point-sensing script/object handy?

Only problem is that there isn't a pretty way of splitting the data. Using SubStringIndex and DeleteSubString or GetSubString isn't anywhere near as easy/intuitive/pretty as (yes, more perl!) :

($firstString, $secondString, $thirdString) = split(/,/, $List2String)



Word on the grapevine is the 29th =)

Yeah you just have to write the operation instead of using a prepackaged one.

I didn't think lists had to hold the same data type (thus llList2String llList2Integer blah blah).

Lists don't have to hold the same data type.

#! yeah that sounds about right. A hash has a key and data attached to it, it is sorted by that key by some algorithm (which perl I think does for you) so you can access the data attached to it quickly. I generally use java and its pretty similar, you create a hash object and do things like myHash.add(key,data) or myHash.find(key) etc.

I'm a little rusty on exact form of arrays cuz my last couple of projects didn't use them. But generally arrays require all elements in them to be the same.

For an esoteric good old time, here's a link to the NIST DADS (National Institute of Standards and Technology Dictionary of Algorithms and Data Structures)

http://www.nist.gov/dads/

Fun stuff... yeah

--Bino Arbuckle, your friendly Googler and fellow computer scientist in training

Thinking back...

Generally compilers have stricter rules about arrays than interpreters do. the compiled program has a very specific set of instruction to traverse a two dimensional array of integers for example.

Interpreters (LSL and Perl are interpreters I think) generally have looser rules, allow mixed data types, and allow for arrays with different numbers of elements in each row even (I forget the word for this). If you start with a 3 x 3 array of integers and suddenly replace the center element with a character string, the interpreter can get additional storage, move the entire array and handle the different data types on an element by element basis. A compiler COULD also do this, but generally they don't because to allow for such dynamism would slow down many operations just in checking for all the exceptions that can happen.

In either case though the first thing that has to be done is to invent a syntax for these things. Once that syntax is invented, you are sort of stuck with it. It would do us all an disservice in the long run to come up with a quick and dirty array syntax now only to have a kludgy dual syntax for more complex arrays later.

Oooohhhh!!! I just thought of another thing, I'll post it in another thread. USER DEFINED TYPES!!!!!!

I've been playing with this and have some multidim code working. Nothing polished, but I can call a dim (getdim 01 for example) and set a dim (setdim 01 myvalue).

Basically, you have a list...

lMaster = [];

...to which you can add serialized-to-CSV lists or individual elements. So, say I want to set an element, and then a new dimension. I call (setelement 00 element1) and then (setdim 01 element2, element3, element4)...

and I get this...

lMaster = ["element1", "{{element2, element3, element4}}"]

...so now the call getdim 01 would = "element2, element3, element4". I use the {{ }} to allow me to determine whether the called dimension is a single element, or a dimension itself (was handy for debugging not sure if I'll ultimately needs this).

If it's an element, that's easy. If it's a dimension, I save the original list where I found it, turn the target dimension into a list, insert the new value at the desired index, then put it back.

So, setelement 010 newelement would make the whole thing look like...

lMaster = ["element1", "{{newelement, element3, element4}}"]

and if I were to call setdim 011 hey,there,guys, I get...

lMaster = ["element1", "{{newelement, {{hey, there, guys}}, element4}}"]

So the call getdim 011 would give you

"hey, there, guys"

and the call getelement 0112 would give you
"guys"

I've got no error checking or type casting set up, but I was really worried less about robustness and more about seeing if this could actually work, so far so good.

I'm not aware of the field limit of a list, both characters per field and total numbers of fields. But I suspect it's big since lists don't appear to have a notion of different types; all data gets stored as some neutral optimal format, and you pull it out with the llList2Etc() functions.

This approach btw is good for unlimited (API/crash limit) multidims; creating a two or three tier multidim with this approach is a LOT easier.

Interesting stuff.