Re: Replacing Codes with Text
Re: Replacing Codes with Text
- Subject: Re: Replacing Codes with Text
- From: email@hidden
- Date: Sun, 17 Jun 2001 00:21:31 -0400
On Sat, 16 Jun 2001 06:20:50 -0700, Paul Berkowitz <email@hidden> noted,
On 6/15/01 5:27 PM, "email@hidden" <email@hidden> wrote:
>
> Since there is a large number of possibilities and only a few codes in the
>
> actual list, I'd scan through the lists and search the translation table for
>
> each.
[...]
>
> Now, you can sort this list using "order list" from Akua Sweets. Then, scan
>
> through your input list, do a binary search for the three-letter code
>
Actually, Scott, once you're using Akua, why not also use 'collect items of
>
codeTable that match "bal" in position 1 with just contents'? I've found
>
that doing the repeat loops can be quicker (if it matters), which is one
>
reason I submitted a solution with repeat loops, but it's hard to beat the
>
convenience.
Paul, you get first-place kudos for your solution: you wrote it all out, it was
vanilla, and it was clear and clean. A great piece of sample code. I just
sketched out an approach.
It probably would be best to use a one-line solution with "collect items",
keeping with my philosophy of using high-level tools instead of writing code
myself, and of not worrying about efficiency until the easy solution proves
itself too slow.
But I couldn't resist making a pedantic point.
The repeat loop, and the "collect items" approach both will take time
proportional to N x M, where N is the number of list items and M is the size of
the code table. But since the code table is static, we can sort it in time M
log M, and then access an item in time proportional to log M. That means we can
produce a solution that works in time (M log M) + N log M, or (N + M) log M.
In reality, the differences between PowerPC and 68k code, between interpreted
AppleScript and executed scripting additions, and the additional overhead of
OSAX calling delays, mean the only way to see what works is to implement and
test them all. I suspect my approach will be the fastest, because there are
only two OSAX calls, which perform high-level repetitive operations on big data
structures (parsing and then sorting), and the multiple low-level actions are
done in AppleScript, but with the advantage of doing a binary search instead of
a linear search.
But with only a few comic strip names and a code table of just a few hundred
entries, you could probably use a bubblesort inside a 'tell app "Finder"' block
and still finish fast enough. Unless this routine is used many times in a
production run, it just won't matter. (And I expect the script will be used
just once a day to set the comics.)
For extra pedantic credit, nerdy readers can implement the code table as a
B-tree. 8-(:-)
>
I'm looking forward to the performance boost when Greg converts
>
Akua to PPC native, although it looks like that will now happen only when
>
Apple makes the documentation available for facilitating conversion of
>
classic osaxen to OS X as well.
I heartily agree. I'm using Akua's sorting command in a heavy-duty application
where the PowerPC speed would be very much appreciated.
--
Scott Norton Phone: +1-703-299-1656
DTI Associates, Inc. Fax: +1-703-706-0476
2920 South Glebe Road Internet: email@hidden
Arlington, VA 22206-2768 or email@hidden