"repeat for each" in reverse order ?

[Dennis Brown]

Wouter,

I was under the impression that JB wanted to read a list sequentially  
in reverse with the repeat for each to make it go faster, not reverse  
the list.  The split into an array is going to be faster at reading  
the list in any order given that the repeat for each in reverse does  
not exist.  However, If we were given a more complete definition of  
the problem, then perhaps the list could have generated a truly  
optimized solution.  For instance, I have had to create some  
solutions for doing stuff in reverse to a list, that I managed to use  
repeat for each loops that ran much faster than splitting.  A genius  
might be able to find all kinds of clever ways to use the existing  
Transcript capabilities, but it would sure be nice if the language  
allowed us mere mortals to tackle a problem in a straight forward way  
without suffering orders of magnitude speed penalties.

As a matter of course, figuring out how to use arrays is one of the  
most straight forward ways to manage data.  Arrays are not the  
fastest nor the most space efficient, but they are usually a  
reasonable compromise for most problems.

I see that our scripting conferences has nothing for arrays in the  
queue.  This might be a good topic based on the number of times it is  
used as a solution for newbie questions.

Dennis

On Jun 27, 2005, at 8:54 PM, Buster wrote:

> Dennis,
>
> I thought the original question on this thread was:
>
> >
>
>> Hi list,
>>
>> Is there a way to use
>> "repeat for each element thisIndexTerm in listOfTerms"
>> in reverse order, like in
>> "repeat with i=number of items of myVar down to 1" ?
>>
>> Thanks,
>> JB
>>
> >
>
> which has changed to a feature request only later on in the thread.
> This feature request would be nice, but doesn't solve the problem  
> right now.
> My answer and there you are right, I should have placed it as a  
> reply to JB's original question and not to yours, was only to help  
> out and show some peculiarities of the different solutions  
> proposed, which were:
>
> The first method I mentioned (which you called a speed killer) is  
> *not* fast at all when the number of lines exceed a certain level  
> (depending on cpu). And the larger the number of chars in those  
> lines the slower the performance.
>
> The second method on the contrary doesn't increase processing time  
> in the same way the first method does and is by far the better  
> solution for larger amounts of lines and chars.
>
> Greetings,
> Wouter
>
> On 28 Jun 2005, at 00:51, Wouter wrote:
>
>
>>
>>
>> Begin forwarded message:
>>
>>
>>> From: Dennis Brown <see3d at writeme.com>
>>> Date: Mon 27 Jun 2005 23:58:13 GMT+02:00
>>> To: How to use Revolution <use-revolution at lists.runrev.com>
>>> Subject: Re: "repeat for each" in reverse order ?
>>> Reply-To: How to use Revolution <use-revolution at lists.runrev.com>
>>>
>>>
>>> Wouter,
>>>
>>> I'm not sure what this example has to do with the question on the  
>>> thread, but you first example is a speed killer.  Putting things  
>>> in front of a string causes the whole string to be shuffled to  
>>> make room for the inserted string.  It is a worst case situation  
>>> --although I can always come up with a way to make it slower.  It  
>>> would be faster to use the slower repeat for i=number of lines in  
>>> x down to 1 and then put the lines after like your second example.
>>>
>>> Splitting into an array is usually a good approach if the repeat  
>>> for each construct will not work.  However, it does take time to  
>>> do the split.  A repeat for each could process the whole string  
>>> in less time than it takes to split it if a repeat for each fits  
>>> the problem.
>>>
>>> In your second example, sorting the keys will also take time.   
>>> You might be better off with just a simple repeat for i=number of  
>>> lines in x down to 1 as the array index.  You would have to try  
>>> it on your array to see.
>>>
>>> Dennis
>>>
>>>
>>> On Jun 27, 2005, at 4:24 PM, Wouter wrote:
>>>
>>>
>>>
>>>> Hi,
>>>>
>>>> Using the following to reverse the order of lines of a field  
>>>> containing 525605  chars in 14194 lines
>>>>
>>>>
>>>> reversing by:
>>>>
>>>> on mouseUp
>>>>   put fld 1 into x
>>>>   put the long seconds into zap
>>>>   repeat for each line i in x
>>>>     put i&cr before tList
>>>>   end repeat
>>>>   put the long seconds - zap
>>>>   put tList into fld 1
>>>> end mouseUp
>>>>
>>>> takes > 60 seconds on a slowbook (G4 400 mhz)
>>>>
>>>>
>>>> reversing by:
>>>>
>>>> on mouseUp
>>>>   put fld 1 into x
>>>>   put the long seconds into zap
>>>>   split x by return
>>>>   get the keys of x
>>>>   sort it numeric descending
>>>>   repeat for each line i in it
>>>>     put x[i]&cr after tList
>>>>   end repeat
>>>>   put the long seconds - zap
>>>>   put tList into fld 1
>>>> end mouseUp
>>>>
>>>> yields around 0.413007 seconds on a slowbook (G4 400 mhz)
>>>> (which is not too bad)
>>>>
>>>> The amount of chars and lines has a big influence on the speed  
>>>> in the first handler,
>>>> while in the second handler it has not.
>>>>
>>>> Greetings,
>>>> Wouter
>>>>
>>>> On 27 Jun 2005, at 14:40, Dennis Brown wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> The repeat for each only goes in forward sequential order  
>>>>> starting at the beginning, except for arrays where the order is  
>>>>> indeterminate.
>>>>>
>>>>> I have requested a sequential access enhancement to allow for  
>>>>> constructing this type of looping in a more flexible way (like  
>>>>> parallel instantiation, starting at an arbitrary point, and  
>>>>> reverse order), to make it possible to wander all over your  
>>>>> data sequentially with the speed of the repeat for each  
>>>>> method.  However, it would be most useful with some improved  
>>>>> string delimiter handling.  Bugzilla # 2773
>>>>>
>>>>> Having a reverse order repeat for each might be up to twice as  
>>>>> slow as the forward version depending on how it is implemented,  
>>>>> because it has to go backwards to the previous delimiter then  
>>>>> forward to pick up the data, though it could pick up the data  
>>>>> in reverse order on the way back.  However, even twice as slow  
>>>>> would be much faster than any other method.
>>>>>
>>>>> Dennis
>>>>>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>