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 <[EMAIL PROTECTED]>
Date: Mon 27 Jun 2005 23:58:13 GMT+02:00
To: How to use Revolution <use-revolution@lists.runrev.com>
Subject: Re: "repeat for each" in reverse order ?
Reply-To: How to use Revolution <use-revolution@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
