Re: Sorting? [sorted]
Re: Sorting? [sorted]
- Subject: Re: Sorting? [sorted]
- From: has <email@hidden>
- Date: Fri, 13 Sep 2002 22:43:36 +0100
Arthur J. Knapp wrote:
>
> 2. you take your existing sort routine and move the comparison part out of
>
> the sort handler and into its own handler. You then modify the comparison
>
> handler alone.
>
>
I also used option 2, but with a twist:
>
>
The problem with the comparison handler is that it has to munge/mangle
>
a single item of the list each time it encounters it, which could be many
>
times throughout the sort.
This is something I noted in the followup. And I spent some time humming
and hawing over what sort of script to post - in the end I deliberately
chose the one that was simplest and easiest for a reader to understand,
rather than the one that was most efficient (which would've been much more
complex and the point would probably have been lost).
All the same, you've got to consider everything in context: unless the time
taken per string munge is significant, you're unlikely to see a huge dent
in the overall running time. Especially with an O(n^2) sort algorithm as
was posted. Especially especially with the O(n^2) sort algorithm posted
being run in AppleScript with its horribly inefficient lists? [Can you say
N-to-a-very-large-number?]
None of which I could've gotten into in the original message anyhow, as I
was already hard against the 8K list limit :p
>
I perform a modification to every item of the
>
list before calling the sort, ensuring that the items were in a sort-
>
ready state.
This is basically the approach John was talking about, and if I'd been
paying more attention I might have suggested it too (but I wasn't).
>
> So, here's the Guidebook sort routine
>
>
> --generalised sort code
>
>
>
> on ASCIISort(myList)
>
>
What a strange contradition. Our comment tells us that this is a
>
"generalised" sort,
Technically, I think this is what's called a "big fat fib". It's almost
impossible to write a sort routine that can't sort any data type that
responds to the "<" and "=" operators, but somehow this one manages it. Try
it with a list of integers and see what happens - totally braindead. And,
as you say, the name is highly misleading as it doesn't actually sort text
by ASCII order.
I hate to have to say it, but I'm _extremely_ unimpressed with the code
samples in the guidebook. There's any number of folks on this list who
could've written better examples (both in terms of usefulness and their
educational value). [Inserts obligatory "AppleScripter For Hire, Cheap
Rates" banner here.;]
>
> Because of some implementation crappiness in AS, you have to wrap your
>
> comparison routine inside a script object: you can't just feed the handler
>
> direct to the sort routine
>
>
Not entirely true, but I suppose you know that, based on your footnote,
>
(which you misnumbered):
Numerically literate too. Yes, you can pass a handler object, but it's not
a documented technique and [due to flaws in AS] it'll blow up horribly
under certain circumstances. Therefore it's not a good practice to
encourage. [4]
>
> Okay, three options if you count rolling a completely non-standard,
>
> highly specialised piece of code from scratch [JD's?], but I really can't
>
> recommend that approach: you want to make your life _easier_, not harder.
>
>
But JD's solution was quite elegant, and given the need in AppleScript
>
for speedy solutions, I really liked it. :)
Clever? Certainly. Elegant? Maybe. Easy to grok? Not particularly. Easy to
generalise to handle different string arrangements? Not until you've
grokked it, and maybe not even then. (I don't know because I didn't fully
grok it.) JD's a smart guy and all, but I didn't think a solution that's
harder to understand than the alternatives was entirely to the OP's
benefit. [3]
Anyway, the need for speed is all very relative; all you actually need is
"fast enough". While "premature optimisation is the root of all evil".
It's easy to obssess over "speed at all costs", but nothing's for free, and
speed optimisations are no exception: the fastest code is _rarely_ the
easiest to read or write. [2]
Given the choice, I'll go for the straightforward solution first. If that
turns out too slow for practical use, _then_ I'll start looking for
something faster, but not before. [1]
Cheers,
has
[4] Yes, I know a couple of my own scripts do it; one of these days I will
get around to making it do it the "proper" way. [When in doubt: WWSND?:]
[3] Dazzle 'em with high science, or teach 'em the basic mechanics?
[WWCSD?:] I might not have been tactful (am I ever?), but I don't think I
was wrong.
[2] (...for anything beyond the most trivial algorithm.) For example, I
believe Python's been getting a new sort recently; go check _that_ baby out
if you want to see F-A-S-T. Just don't attempt to actually understand how
it works: you'll seriously injure yourself if you do.
[1] And let's face it, if you want "fast" then for heaven's sake _don't_
use AppleScript in the first place...;p
[0] ;)
--
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.