How does this work?

[Ruthven Ravenhurst]

I was looking at the group chat for the Scripting group and someone was having trouble with a script.

I noticed they were using what looked like an odd way of getting a random number

list thenumbers = [(area of texture uuids)];

integer which = llFloor(llFrand(thenumbers != []));//This right here, how does it work?

From looking at it, I would have guessed llFrand would be fed a True/False making it choose a number between 0 and 1, and then llFloor would round that down to 0 every time.

But when I tested it with 10 entries as they were doing, it was working as they intended which was giving a random integer between 0 and 9

[Rolig Loon]

That's a peculiar one.  My guess is that it relies on implicit typecasting of thenumbers != [] to a float, and therefore equal to 1.0 unless the list doesn't exist.  It's clever, but I'm not sure whether to give it points for much more than cleverness.  Its only mild advantage over llFrand(1.0) is that it yields 0 if the list is empty -- perhaps an important failsafe in the context of the script where you found it.

Edited August 2, 2017 by Rolig Loon

[KT Kingsley]

See http://wiki.secondlife.com/wiki/LlGetListLength#LSO_Optimizations

Quote

A faster and lighter (in bytecode) way to determine the length of a list is to do a not-equals compare with a null list. This works because the list not-equals compare returns the difference between the lengths, meaning that it returns the same result as llGetListLength(), minus the overhead in bytecode, and performance penalty of calling a non-native function. Note: This optimization is much less beneficial time-wise in Mono as Mono's llGetListLength function is almost twice as fast, however the bytecode saving is still about 30 bytes.

 

[Love Zhaoying]

Too bad there is no seeding function or parameter for llFrand().

[Ruthven Ravenhurst]

Just now, Rolig Loon said:

That's a peculiar one.  My guess is that it relies on implicit typecasting of thenumbers != [] to a float, and therefore equal to 1.0 unless the list doesn't exist.  It's clever, but I'm not sure whether to give it points for much more than cleverness.  It's on;y mild advantage over llFrand(1.0) is that it yields 0 if the list is empty -- perhaps an important failsafe in the context of the script where you found it.bu

But it's not changing it to 1, it's resulting in a random number between 0 and the length of the list, but no where in theirs or my script is it using llGetListLength 

[Rolig Loon]

2 minutes ago, Ruthven Willenov said:

But it's not changing it to 1, it's resulting in a random number between 0 and the length of the list, but no where in theirs or my script is it using llGetListLength 

Yup.  You're right.. KT Kingsley got it.  It's the old hack for llGetListLength.  I had forgotten that momentarily.

[Ruthven Ravenhurst]

3 minutes ago, KT Kingsley said:

See http://wiki.secondlife.com/wiki/LlGetListLength#LSO_Optimizations

 

Ah, that makes sense. Interesting.

[Nova Convair]

LSL has no true/false, there is no boolean data type.

And the compiler solves the compare by using getlistlength. Since we have no boolean data type there is no need to typecast the result into a proper true/false.

Thats a bit sloppy and a change in the compiler would break that stuff but I'm pretty sure LL will never touch the compiler more then necessary - so it's safe enough.

I'll never use this fancy stuff though and leave that to the byte seekers

[Ruthven Ravenhurst]

Another "How does this work?" Question. I'm messing with a script that will have a customizable timer and wanted to play with casting some strings to a float

So how does this work? It's returning 10.000000, when i figured it would just return 0 because of the non-number text in the string. I even tried casting to integer and it works too, and changing the plus sign to minus makes it a negative number

default
{
    state_entry()
    {
        float number = (float)"+10.0sec";
        llSay(0, (string)number);
    }
}

 

[KT Kingsley]

The comments in the examples at http://wiki.secondlife.com/wiki/Typecast mention that leading white space and trailing non-numeric text is ignored when typecasting strings to floats or integers, but that's about it.