Re: Understanding a repeat loop (strings/characters)
Re: Understanding a repeat loop (strings/characters)
- Subject: Re: Understanding a repeat loop (strings/characters)
- From: has <email@hidden>
- Date: Sun, 23 Feb 2003 19:28:23 +0000
Emmanuel wrote:
>Incorrect. The 'repeat with itemRef in val' structure iterates over
>an object's items. Both strings and lists have 'item' elements, so
>either may be used here. And since in strings 'item' is synonymous
>with 'character', what you end up with is a reference to each
>character.
Surprising but obviously true: the behavior of the loop won't depend
on what the text item's delimiters are, thus it looks like the string
is never made into a list (which would involve the t.i.ds).
TIDs are irrelevant. The 'repeat with' statement is asking the string
for its character - a.k.a. item - elements, not its 'text item'
elements.
-------
Paul Skinner wrote:
I see that in the raw apple event.
AppleScript type conversions don't involve AppleEvents (not as far as
I can tell). So this is also irrelevant.
There is no coercion to list.
This thread has strong echoes of the "magic coercion" discussion I
had with Steve Angier last November. (I was trying to save his
blushes by not dredging it up again, but it's hard to ignore the
connection; sorry Steve.) In short, there is NO magical
string-to-multi-item-list coercion in AppleScript.
What IS true:
- Strings have 'item' elements.
- Lists have 'item' elements.
- Multiple variable assignments and 'repeat with foo in bar'
statements could not give a toffee about the class of value you give
them. All they care is that the value given responds to a 'get item'
command, which values of type string, Unicode text and list all do.
(This is the basis of polymorphism in OO, btw: it doesn't matter what
object you're talking to, as long as it understands the message
you're giving it. Great stuff, but unfortunately not very obvious if
you don't know OO.)
--
So, what does this mean to me?
It means that I can pass a string of length 5000 characters, and I
won't have a problem addressing every character despite the 4069+/-
item limit on text to list conversion. Nice!
What about speed?
Well! Looping through a 2560 character string in both manners yields
some very interesting results. 100X+/- speed differences!
It's rather more complex than this...
First, getting an item of a string involves less work than getting an
item of a list; essentially, "get value of memory location x" versus
"get the value of memory location y and use it as a pointer to memory
location z".
Secondly, getting an item of a list is less efficient than getting an
item of a string; O(n) versus O(1) behaviour [1][2], where n is the
number of items. This means that the bigger the list, the longer it
takes to get an item from that list. Thus traversing across an AS
list object takes performance-plummeting O(n*n) time [3], versus O(n)
for a string. The speed difference you see in your tests is almost
entirely due to this factor.
One other thing: unlike MacRoman strings, the Unicode text type also
displays crappy O(n) behaviour when looking up an item. That's not
AppleScript's fault though; it's the fault of the Unicode standard's
designers for sleeping through their CompSci Algorithms 101 course.
Unicode may be tremendously powerful and flexible on the language
side, but it's also woefully inefficient on the machine-processing
side. I'm guessing the only thing to speed things up there is throw
heavy unicode grinding onto a scriptable application or other
environment that's been optimised up the wazoo to compensate for this.
Why hasn't this been clearly stated? It seems to be an excelent
optimization technique.
Well, it really ought to be documented in the ASLG because it's an
official language feature and the ASLG is supposed to be a
comprehensive reference to those. I guess it got overlooked at the
time; it's easily done. As far as "optimisation techniques" go,
that's getting into CompSci territory again. And this is both outside
the ASLG's remit and would fly over the heads of a lot of
AppleScripters anyway (e.g. see the above).
HTH
has
--
[1] The original AS engineers put a bunch of extra code into the
vector list type to prevent errors and crashes caused by circular
references (or something like that). Unfortunately, this results in
pretty dire performance characteristics. See previous list
discussions for more.
[2] O(1) = constant time (sweet); O(n) = linear (mmm...); O(n^2) =
quadratic (euww!)
[3] Unless you hack around with Serge-style kludges to get that O(n)
lookup back down to O(1).
--
http://www.barple.pwp.blueyonder.co.uk -- The Little Page of AppleScripts
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.