>>>Although this is very fast, it has the same problem as my first script in
this thread: namely that 'j' can index any item in the list. As Mark's been
patiently explaining to me both on and off list, this makes some shuffle results
(marginally) more likely than others. To make all possible results equally
likely, j has to be restricted to a random number from 1 to i.

Hmmm... Well, my concern is that every card should have an equal opportunity
to land at any position in the deck on every shuffle, and I'm just not
convinced that's happening here. Maybe I'll do what they do in vegas and
shuffle three times, just to be safe!

Repeat 3 times
  Set theDeck to the reverse of shuffle(theDeck)
End repeat

>>>On the machine I'm using at the moment, this appears to be slightly faster
even than your version! (Possibly because I've used 'my' to reference the
'listIndex' property.)

Ahhh! I'm still not sure how or why using properties and script objects and
"my" references speeds things up, but it sure does.


>>>>To be fair when comparing the timings of a handler that uses an index list
and one that doesn't, you should include the time taken to build the list!  ;)

But in this application, that only has to be done once, and, if we were
truly optimizing for speed we'd simply enter the list index:

Set list index to {1,2,3, etc.}

However, if you're dealing with lists that could be any length, then yes the
time it takes to index the list should be built into the time it takes to
shuffle.

>>>The 'some item' approach wins hands down anyway.  :)

That's good to know. The random number osax call is the bottleneck.

Ed