User talk:Decimus Schomer/Scripts/Libraries/LSL sets

What are the set_add_*_list functions meant to do? Following the code, it looks like they only add the list of numbers if it's a duplicate of an already existing set, in the same order, otherwise they bail out. Additionally, they do no duplicate checking. So, what am I missing? - Katharine Berry 19:26, 18 July 2007 (BST)

The set_add_*_list functions are meant to only not add them if they're a *perfect* duplicate of a list already in the set. I think that you're thinking that it's supposed to append each item to the set separately, but it's not - it adds the list as a single new entry. --Decimus

So {1,2,3} and {1,3,2} are different sets? I that order was irrelevant (and Wikipedia backs me up on that), and I can't see any sorting code. - Katharine Berry 19:45, 18 July 2007 (BST)

Those sets are the same, but set_add_*_list makes a set of lists (which are ordered), not a set of sets. --Decimus

Ohh. I'm being stupid now. >.> Sorry. :p - Katharine Berry 19:50, 18 July 2007 (BST)

'Skay. Everyone does that some days :p (and it's very likely that a large part of the problem was my lack of comments :p) --Decimus

One thing I've noticed with this code is that it's got a large amount of code duplication - set_add_int and set_add_str differ in a single call name. That's why I'm planning on making my own programming language which is some kind of cross between C, Python and possibly a bit from C++ (I dislike C++ for the simple reason that someone who doesn't understand the language wouldn't know where the 'this' value used in many functions comes from, among others)

That can be worked around if you take your function input as lists - you can then use llGetListEntryType to pick the appropriate function. The only downside is having to put [] around the arguments to the function. - Katharine Berry 20:01, 18 July 2007 (BST)

I think this is flawed - "mda_val_lens = [];" is followed by "for (i = 0; i < mda_len(-1); i++)". As such, nothing gets done, because you're essentially doing "0 < 0". - Katharine Berry 20:33, 18 July 2007 (BST)

That explains a lot! The grammar analyser thing wouldn't work, and that's precisely why. I should've fixed it now --Decimus

Sorry. Being really dumb today. :( - Katharine Berry 21:37, 18 July 2007 (BST)

It's okay; I felt the same when I realised that what the problem with the grammar analyser was :p --Decimus

I reckon that this would be faster (and it what I actually meant), but I don't want to screw up again:

                if (llList2String(l, x) == llList2String(val, x))
                {
                    return;
                }

Looks like it'll work. And yes, I think that that'd be faster.

Actually, I thought you'd put llList2CSV (well, I actually thought for a moment that that was what it did. Silly me :p). I'm guessing that that'd be faster - after all, the conversion is done in compiled, rather than interpretted, code. And you can optimise it so that llList2CSV(val) is only done once, which I've done

Do you have any objection to the rest of my changes? - Katharine Berry 21:44, 18 July 2007 (BST)

Nope, they're fine. (and I don't have any intentions of learning LSL all that much - it's annoyingly rubbish, to say the least (wait, I could say that about the only other program-specific C variant I've seen, too :p))