Innula Zenovka Posted March 28, 2018 Share Posted March 28, 2018 (edited) 5 hours ago, Phil Deakins said: It's not like that. Suppose you have a list of 20 elements (0 - 19), and you want every 4th element (0, 3, 7, 11, 15, 19), I'm not quite sure what you mean here. If I have a list of 20 elements, and I want every 4th one, I'd do something like this: integer interval=4; integer max; integer counter; list lList =[ "0","1","2","3", "4","5","6","7", "8","9","10","11", "12","13","14","15", "16","17","18","19" ]; default { state_entry() { max = llGetListLength(lList); counter = 0; do { llOwnerSay(llList2String(lList,counter)); counter += interval; } while(counter < max); } } That gives me 0, 4, 8, 12, and 16, as does list temp = llList2ListStrided(lList,0,-1,interval); llOwnerSay(llList2CSV(temp)); If I wanted 3, 7, 11, 15, and 19, then I'd do list temp = llList2ListStrided(llDeleteSubList(lList,0,2),0,-1,interval); llOwnerSay(llList2CSV(temp)); or I'd use my first example, only with counter = 3 for the staring value. But I don't see how 0 and 3 both end up in the results you have. Given my notorious tendency to get mixed up by LSL's habit of counting from 0 rather than 1, I hesitate to suggest anyone may have made a similar error, but I don't really understand why you expect the results you do. Edited March 28, 2018 by Innula Zenovka Link to comment Share on other sites More sharing options...
Phil Deakins Posted March 28, 2018 Author Share Posted March 28, 2018 Suppose you have a list of 20 elements (0 - 19), and you want every 4th element (0, 3, 7, 11, 15, 19) That was a mistake in my brain when I typed the post, but not in my knowledge. I've changed the post now. I was never after the 0 element. If I had been, the problem wouldn't have arisen. My original workaround was to loop through the source list, similar to yours, but I changed that when the first 2 code snippets were posted, because they showed a much nicer way of doing it. 1 Link to comment Share on other sites More sharing options...
Phil Deakins Posted March 28, 2018 Author Share Posted March 28, 2018 20 hours ago, Xiija said: It's a good catch Phil Someone should make a note in the wiki.... if start & end both point to the same list item, the function apparently has NO operating range ? list mylist = [0,1]; list result_a = llList2ListStrided(mylist,1,-1,2); ( or ... llList2ListStrided(mylist,1,1,2); ) It's still puzzling, because, although the start and end in my orginal line (1, -1) both pointed to the same element (list item), the line(s) in the solution do too, and yet the solution works. I.e. with the original 2-item list, make a new list as a copy of the orginal list but with the first item removed. Then set the start at 0 and the end at -1. Both parameters point to the same first element, because there is now only item in the list. And yet it works. Very puzzling. Link to comment Share on other sites More sharing options...
Qie Niangao Posted March 29, 2018 Share Posted March 29, 2018 I've been hoping to eventually discern what about this function's behavior is perceived as anomalous. I have a tentative theory. It seems there's an expectation that the list strides begin with the specified starting element. Rather, as I understand the function's behavior, it strides the list first, and then first-of-stride elements are returned beginning from the specified starting element of that list. So if there's no stride starting at or after that specified start, the result will be empty. I think this is the "Confusing spec" in the wiki article's Discussion. Link to comment Share on other sites More sharing options...
Phil Deakins Posted March 29, 2018 Author Share Posted March 29, 2018 (edited) 1 hour ago, Qie Niangao said: I think this is the "Confusing spec" in the wiki article's Discussion. That "Confusing spec" paragraph exactly mirrors my problem. The only differrence being the sizes of the source lists. Mine was 2 elements, and Sharie's was 7 elements. I particularly like Sharie's statement, "Perhaps we need an llList2ListStridedNotBraindead?" lol Strife said, "I'll submit a feature suggestion for a new function, not sure what to call it." - he was being serious - but it doesn't need a new fuction. It needs the llList2ListStrided() function to be fixed, because it's flawed. It doesn't do what it says on the tin. Edited March 29, 2018 by Phil Deakins Link to comment Share on other sites More sharing options...
Phil Deakins Posted March 29, 2018 Author Share Posted March 29, 2018 (edited) 3 hours ago, Qie Niangao said: I've been hoping to eventually discern what about this function's behavior is perceived as anomalous. I have a tentative theory. It seems there's an expectation that the list strides begin with the specified starting element. Rather, as I understand the function's behavior, it strides the list first, and then first-of-stride elements are returned beginning from the specified starting element of that list. So if there's no stride starting at or after that specified start, the result will be empty. That's my expectation, yes. What do you mean by "strides the list first"? With my 2-item list without the solution, the list that llList2ListStrided is applied to always contains a full stride, but it fails. With the solution method, the list that the function is applied to doesn't contain a full stride of 2, and it succeeds. Edited March 29, 2018 by Phil Deakins Link to comment Share on other sites More sharing options...
Qie Niangao Posted March 29, 2018 Share Posted March 29, 2018 1 hour ago, Phil Deakins said: What do you mean by "strides the list first"? With my 2-item list without the solution, the list that llList2ListStrided is applied to always contains a full stride, but it fails. With the solution method, the list that the function is applied to doesn't contain a full stride, and it succeeds. I mean that before anything else, the stride is applied to the list, starting at the 0th element. The initial element of each stride starts out eligible to be returned in the result list. But then the exclusions are applied: any of those initial elements that come before the specified starting element (or after the specified ending element) will be excluded. It doesn't matter whether all the parts of a stride are available because only the initial element can be part of the result. Link to comment Share on other sites More sharing options...
Phil Deakins Posted March 29, 2018 Author Share Posted March 29, 2018 I understand now - maybe Apply that to Sharie's 7-element list (0 to 6), the stride (2) is applied to it starting at the 1st element (0). That would give 0, 2, 4, 6. Then the start element (1) comes into play so the 0 element is excluded, leaving 2, 4 and 6. OR maybe you mean that the function creates a new list for itself comprising the source list with the befores and afters trimmed off (excluded). So now it starts at element 0 of its own list and gets every n (stride) elements. That would work, except it doesn't in the 2 examples (mine and Sharie's). OR maybe I'm being really obtuse I'm still puzzled, but now I'm also confused lol. But, whatever the reason why it doesn't work as it should, my understanding of why it fails isn't going to change anything, so it doesn't matter. Sharie wrote that 'Confusing spec' piece in 2012 and they didn't fix it, so this isn't going to make any difference. Link to comment Share on other sites More sharing options...
Phil Deakins Posted March 29, 2018 Author Share Posted March 29, 2018 (edited) According to Maestro Linden in the Bug Tracker, "When the start and end indices for llList2ListStrided(mylist, start, end, stride) don't include the full list, this function creates the strided list (always including indices which are multiples of stride), and then trims the output to the indices which were between start and end on the original list.", which sounds a lot like you suggested, @Qie Niangao Edited March 29, 2018 by Phil Deakins 3 Link to comment Share on other sites More sharing options...
Lindens Mazidox Linden Posted April 2, 2018 Lindens Share Posted April 2, 2018 Thanks for teaching me something new about LSL Phil! 3 Link to comment Share on other sites More sharing options...
Phil Deakins Posted April 2, 2018 Author Share Posted April 2, 2018 I think a number of us learned something from this thread, Mazidox. 1 Link to comment Share on other sites More sharing options...
Recommended Posts
Please take a moment to consider if this thread is worth bumping.
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now