>>>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