How to reverse a list order?

Hi team.
I'm trying to reverse a list (curtain sculpt-maps)
Found on wiki:
// Returns a new string containing the reverse of source.
string StringReverse(string source)
{
string str;
integer x;
integer len = llStringLength(source);
for (x = 1; x <= len; x++)
str += llGetSubString(source, len - x, len - x);
return str;
}

string SCULPT_MAPS is CSV from a notecard
I started with keys and changed to texture-strings e.g. 1map, 2map etc

Tried:
StringReverse(SCULPT_MAPS);
list maplist = llParseString2List(SCULPT_MAPS, [","], [""]);

But it don't seem to reverse the order
Am I on the right track? .
What else can I try? Thanks

http://lslwiki.net/lslwiki/wakka.php?wakka=llListSort

Don't have time to do anything but provide a link, I'm sure someone else will be along to provide example code if you need it.

LIBRARY: reverse Find, and reverse order Functions


you also might find this useful

LIBRARY: Multi-ListFindList Forward and Reverse


the ones noted as "string only" actually will work on keys too.

PS thanks for reminding me that I need to add those to the wiki.

The way I understand you is:
You want to have the list elements in reversed order?
You don't want the list sorted?
You don't want the character order reversed? (the 'StringReverse' does that)

Here is a working sample that does just that:

list L = [10,20,30,15,-8];
default
{
    touch_end( integer nu )
    {
        integer m = llGetListLength( L )-1;
        while ( --m>=0 )
        {
            L = llDeleteSubList( L, m, m) + llList2List( L, m, m );
        }
        llOwnerSay( llDumpList2String( L, ", " )); // Show result
    }
}

This is just one way to do it

First, the reason you aren't seeing any change is that you cannot modify a list IN PLACE. The function you are using RETURNS a string that is the reverse of its argument, and you have to do something with that return value. So the first line in your code that uses the function should be more like:

SCULPT_MAPS = StringReverse(SCULPT_MAPS);

(Or assign to a second string if you want to keep the first one around.)

Second, you are using a function that will reverse the WHOLE STRING, character by character. That's probably not what you want. I suspect you want to reverse the order of the logical entries in the CSV (between the commas) without reversing the characters in each. So you want to parse into a list FIRST, then use a function that does with a list what your 'StringReverse' does to a string. Something like:

// Returns a new list of strings containing the reverse of source.
list StringListReverse(list source)
{
   list result = [];
   integer x;
   integer len = llGetListLength(source);
   for (x = 1; x <= len; x++)
   {
      result += [ llList2String(source, len - x, len - x) ];
   }
   return result;
}

list maplist = llParseString2List(SCULPT_MAPS, [","], [""]);
maplist = StringListReverse(maplist);

Free gift to the first person to explain how it works and why you don't want to do it this way.

list listReverse(list l)
{
  if(llGetListLength(l) <= 1) return l;

  return listReverse(llList2List(l, 1, -1)) + llList2List(l, 0, 0);
}

Hell of a call stack for long lists. But a binary (half and half) recurse wouldn't be so bad. O(log N) instead of O(N). Memory use would be (almost) just as bad though.

ITYM O(NlogN) and O(N^2).

That's only because LSL doesn't do tail recursion optimization. If it did, that function would be O(N). I kept telling em, they need to provide a Lisp front end for LSL, the byte-code is already stack based, but no....

[lisp]
(def 'listReverse (l)
(cond ((cdr l) (cons (listReverse (cdr l)) (car l)))
(t l))))
[/lisp]

LOL. Lisp in SL. Ouch. I did indeed mean O(log N) and O(N), but I was talking about only the depth of the call stack, not the overall run time complexity.

I'm talking about depth of the call stack, too. Without tail recursion elimination you get N copies of a list N elements long, that's O(N^2).

And if you think Lisp is scary:

[forth]
: listReverse recurse
dup llGetListLength 1 > if pop >R listReverse R> llAppendList then ;
[/forth]

Oh , how about "⌷ ← list[⍒⍳⍴list]"?

can you say stack heap collision with a quickness... I knew you could....

lsl+recursion = "bad, very bad" (said in best rain man imitation)

ETA and yes I see that all the functions as well as their reference would all be on the stack because lsl copies the whole damn variable

Okay. Let me say, "number of stack frames." Maybe that will clear things up. It's what "call stack depth" usually means. In any case, I think list contents go on the heap. But we're only disagreeing over terminology in any case; I think we both have a clear understanding of the matter.

OK, so how about that APL front end to LSL?

I think you're out of your mind. And I suppose we'd need prim touchpads or something to allow the proper character entry. Heh.

Thanks for the help team!
Don't know why my searches didn't find Voids' work.
Learning all the time.
llAvatar2Avatar(animate HUGS,avatar MULTI)

yw (and I can guess why... the terms "reverse" and "order" are pretty common =)

Dora's code is actually near identical to my small memory version, but her's will run a hair faster on small lists... mine is optimized to run on medium to larger lists, although it does one more loop than it actually has to to simplify the test logic for speed of repetition (and 1 operation on single item lists).... I'm not sure if hers pushes more running space than it needs to, by calling the delete and add on the same line though... something I should have tested, because it'd actually be an improvement on mine if it doesn't.

Did you read what it said on the wrapper? "Contents: ferret".

Try this:
}
}
string=re-type(list in reverse order by hand, HAHA)
}

string=re-type(dnah yb redro esrever ni tisl, HAHA)
Done!

oh btw, your original solution, only suffered from counting from the wrong end. if it'd started at -1, and run to negative length or at length-1 and run to 0 it would've worked fine.

Not quite. See my first point. Even if reversing the order of the whole string (rather than the list) was the intent, there was another problem....

gah, half awake, wasn't even looking at the type (ok and the fact that it needs to return len, -1)

it was the right conceptual track though...