Re: Dice
Re: Dice
- Subject: Re: Dice
- From: kai <email@hidden>
- Date: Wed, 27 Oct 2004 21:31:39 +0100
On Wed, 27 Oct 2004 16:55:31 +1000, Malcolm Fitzgerald wrote:
On Tue, 26 Oct 2004 23:03:23 -0400, David Andrews <email@hidden>
wrote:
[snip: code/results]
Not bad, if there were not some item! :)
kai wrote:
Hm... 'some paragraph' has the edge OMM - although my test differs
from
yours somewhat.
I used 1000 items, characters, words, paragraphs, etc and repeated 1000
times to get these two sets of results from Smile's chrono on a G4 400.
random number: 0.2048569, 0.2265079000001
some item: 1.034765, 1.041271
some character: 0.033748, 0.033304999999
some word: 30.082584, 30.110024
some paragraph: 0.212169, 0.212347000001
Paragraph is a strong performer but it is slower than random number
here
and they are both left in the dust by character.
Right. The fact that character performs well doesn't surprise me.
However, since we can only extract a single character/digit at a time
with this method, its usefulness beyond the range "0123456789" might be
limited (in the context of a numerically-based series).
--
On Wed, 27 Oct 2004 17:36:10 +1000, Malcolm again:
Joseph Weaks wrote:
And I am getting even differenter results picking randomly from a set
of
ten repeating a million times as per this handler:
Yes Joe. You may recall that I mentioned earlier (Wed, 27 Oct 2004
06:58:15 +0100):
... the fastest method in any other situation would depend largely on
the range of numbers involved...
... 'random number' isn't particularly competitive when the range is
limited, but comes into its own as the range increases - and is
extremely effective when hundreds of numbers are involved. In fact,
there seems to be be very little variation in the time taken to
generate a random number - be it from 2 or 2000 numbers. By contrast,
the execution of list methods can take significantly longer as list
length increases.
While Malcolm's tests were run on 1000 items, yours involved only 10.
So I'd expect 'random number' to do pretty well in his tests - with the
list-based methods comparing more favourably in yours.
Back to Malcolm:
You are doing a lot more inside the timing routine than I am. That
could have an effect.
His point is a good one. Apart from the statements being specifically
tested, anything else that appears between the start and end times
could skew results in some way.
Also I'm using a different and more finely tuned instrument than
current date. This is how I set up the test.
[snip: details of test]
Quite. With an accuracy of 1 second, 'current date' can be a bit of a
blunt instrument in the context of this kind of testing.
--
Then, on Wed, 27 Oct 2004 08:11:25 -0700, Jon Pugh:
At 2:10 AM -0500 10/27/04, Joseph Weaks wrote:
>How such a huge difference for the "random number" method?
The "random number" function is a scripting addition, and as such
takes a speed hit via AppleEvents. The construct "some item" is
purely AppleScript and requires no AE, thus it is significantly
faster, but harder to control...
Yet in spite of the overhead, some scripting additions can achieve
quite a lot, quite quickly - once that initial call has been made.
Therefore, if a job warrants it, using a scripting addition can pay
dividends.
This discussion is perhaps a case in point. While the speed of
list-based methods (some item of..., some paragraph of..., etc.)
depends on list length, 'random number from 1 to 2' can take pretty
much the same time as 'random number from 1 to 1000000'. So, for a
narrow range of numbers, an AS list-based method should work well. For
a wide range, Standard Additions' random number could well prove the
much faster option.
Just another case of "horses for courses", really... :-)
---
kai
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden