Need help resolving accidental (honest!) language pissing match

[has]

<BLUSH> Careless talk costs lives, as they say. In my case, a
throwaway comment that Python could trounce the notoriously
underpowered and undersupported AppleScript language for "serious
number crunching". (And Perl could beat Python, and Fortran could kick
all their butts, etc...) Well, you'd think me and the other guy would
be old enough to know better, or at least have more important things
to do, but nooooo...
Ah well, too late now: honour is at stake, and honour must - I say,
MUST - be upheld!!! Unfortunately for me, my math is utterly shot and
I'm not really up on Python's module support in this field either
(poked briefly at numarray, but that's about it), so I'm far too
stupid and incompetent to do it all by myself. :p

Here's the problem and code:

"Suppose I want to study a random walk. Say I would like to appreciate
the distribution of the presence of the walker."

set n to 1000000 -- we'll be talking about 4 MB
set x to randomarray n range {-1, 1} -- n random draws
set x to runningsum x -- the cumulative sums of the draws
set {mean:the_mean, stdev:the_stdev} to statlist x -- compute
stats

All the real work here's being done by a C-based scripting addition
(plugin), taking about a second on a G4/867. If the worst comes to the
worst, I can force a dishonorable draw simply by calling the same
scripting addition via MacPython's Carbon support modules, but I'd
really like to punt the blighter out of the ballpark so existing
C-based Python extensions, Python-to-Fortran bridges, etc. are all
okay by me if anyone has a few minutes and spot of sympathy to point
us in the right direction. Cheers! :)

[Terry Reedy]

"has" <ha*******@virgin.net> wrote in message
news:69*************************@posting.google.co m...

<BLUSH> Careless talk costs lives, as they say. In my case, a .... stupid and incompetent to do it all by myself. :p
Perhaps you should squirm on your own petard a bit, but here are some
comments ;-)
"Suppose I want to study a random walk. Say I would like to appreciate
the distribution of the presence of the walker."

set n to 1000000 -- we'll be talking about 4 MB
There is no need to save a million of anything that i can see. If there
were, preallocate the list with "array = n*[1]
set x to randomarray n range {-1, 1} -- n random draws
This is slightly unclear. Without the unneeded array, perhaps you mean
something like
x = 0
for i in xrange(n):
x += random.random() < .5 and -1 or 1
set x to runningsum x -- the cumulative sums of the draws
The above does that as you draw.
set {mean:the_mean, stdev:the_stdev} to statlist x -- compute
stats
stats other that x itself are only meanful across multiple walks (ie, m
walks of n steps each). Since you have not specified m, I am not sure what
you have in mind. To keep x**2 fitting within an int instead of long, n =
100,000 would be better.
All the real work here's being done by a C-based scripting addition
(plugin), taking about a second on a G4/867.
If the int sums are done in C in the addition (aha! this must bei the
reason to make an array), Numerical Python will not do better and maybe not
as well.

If that C addition does floating point in C much like NumPy, then perhaps
AppleScript is less underpowered than you claim.

If the worst comes to the worst, I can force a dishonorable draw simply by calling the same
scripting addition via MacPython's Carbon support modules, but I'd
really like to punt the blighter out of the ballpark
Unlikely if the C addition is any good. Anyway, why? The competitive
advantage of Python is programming speed, especially for larger problems
than this.
so existing
C-based Python extensions, Python-to-Fortran bridges, etc. are all
okay by me if anyone has a few minutes and spot of sympathy to point
us in the right direction. Cheers! :)

If Psyco runs on Apple, try that. Otherwise, make arrays and use NumPy.

Terry J. Reedy

[Jeff Epler]

Here's my try, using numarray:
import numarray, numarray.random_array, numarray.nd_image
n = 1000000
x = numarray.random_array.randint(-1, 2, (n,))
x = numarray.add.accumulate(x)
mean = numarray.nd_image.mean(x)
st_dev = numarray.nd_image.standard_deviation(x)
print mean, st_dev
This runs for about .6 seconds on a 2.4GHz PC running Linux.

I'm not sure whether the results are right, but at least the program
finishes quickly, and involves a random array, a running sum, and some
statistics.

Jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAvgLiJd01MZaTXX0RAkO8AKChRGnD7RuSdBHPdc6vbo ywCildCACgkzMI
3qrQxU5ZMCGeTUa4XvHQa6k=
=XXRH
-----END PGP SIGNATURE-----

[has]

Jeff Epler <je****@unpythonic.net> wrote in message news:<ma*************************************@pyth on.org>...

Here's my try, using numarray: [...] This runs for about .6 seconds on a 2.4GHz PC running Linux.

I'm not sure whether the results are right, but at least the program
finishes quickly, and involves a random array, a running sum, and some
statistics.

Just what the doctor ordered! Many thanks! :)

(p.s. If your interested, the numarray script takes about 1 sec on my
G4/867 running OS10.2.6 - about same speed as the original example.
Only change I made was replacing numint with uniform to get reals. But
numarray wins on sheer size and breadth of functionality, imnsho...;)

[has]

Jeff Epler <je****@unpythonic.net> wrote in message news:<ma*************************************@pyth on.org>...

Here's my try, using numarray: [...] This runs for about .6 seconds on a 2.4GHz PC running Linux.

I'm not sure whether the results are right, but at least the program
finishes quickly, and involves a random array, a running sum, and some
statistics.

Just what the doctor ordered! Many thanks! :)

(p.s. If your interested, the numarray script takes about 1 sec on my
G4/867 running OS10.2.6 - about same speed as the original example.
Only change I made was replacing numint with uniform to get reals. But
numarray wins on sheer size and breadth of functionality, imnsho...;)

[has]

"Terry Reedy" <tj*****@udel.edu> wrote in message news:<ma*************************************@pyth on.org>...

"has" <ha*******@virgin.net> wrote in message
news:69*************************@posting.google.co m...

<BLUSH> Careless talk costs lives, as they say. In my case, a ...

stupid and incompetent to do it all by myself. :p

Perhaps you should squirm on your own petard a bit, but here are some
comments ;-)

LOL. If I had a dollar for every time I put my foot in it... ;)

"Suppose I want to study a random walk. Say I would like to appreciate
the distribution of the presence of the walker."

set n to 1000000 -- we'll be talking about 4 MB

There is no need to save a million of anything that i can see. If there
were, preallocate the list with "array = n*[1]

First rule of Language Pissing Match: common sense, real-world
requirements and reality in general need not apply. ;)

set x to randomarray n range {-1, 1} -- n random draws

This is slightly unclear. Without the unneeded array, perhaps you mean
something like
x = 0
for i in xrange(n):
x += random.random() < .5 and -1 or 1

Part of the reason for the AppleScript version using a custom array
'type' would be that performing your version in native AS code would
take in the order of minutes. The AS interpreter is probably a tenth
the speed of Python's on average, and with almost all useful
functionality being provided by external sources - OSA eXtensions and
scriptable apps - there's a serious Apple event messaging overhead to
pay if you're going to call the 'random number' OSAX a million times.
I've been using Python almost a year now, and I'm still like "Whoa!
Can't believe how speedy this is!" <g>

stats other that x itself are only meanful across multiple walks (ie, m
walks of n steps each). Since you have not specified m, I am not sure what
you have in mind. To keep x**2 fitting within an int instead of long, n =
100,000 would be better.
Heh, don't look at me. Our high school stats classes were mostly spent
reading Exchange And Mart and discussing how to pull the lassies. And
this was like back in 1989, so I can't even remember how to do those
any more, never mind calculate the mean of the whatsit of the
distributed thingamuyjig... ;)

All the real work here's being done by a C-based scripting addition
(plugin), taking about a second on a G4/867.

If the int sums are done in C in the addition (aha! this must bei the
reason to make an array), Numerical Python will not do better and maybe not
as well.

Yeah, in the end it works out about the same speedwise. Though
numarray has the better language integration and by far the larger
featureset so wins on that.

If that C addition does floating point in C much like NumPy, then perhaps
AppleScript is less underpowered than you claim.
The AppleScript language itself is severely underpowered (something
about being a twelve year-old language that's never gotten beyond a
v1.x release inevitably invites Peter Pan comparisons).

C-based/Pascal-based OSA extensions (osax[en]) actually plug into the
Open Scripting Architecture, which is the scripting component
framework that the AppleScript language component (amongst others)
plugs into to let it communicate with the outside world. They're kind
of like an even cheaper-n-nastier version of HyperCard's XCMD system
(or whatever it was called), and really a bit of a hack that was
tossed in quickly to fill an obvious hole in the AS language spec
itself, and never got replaced with something better. If I tell you
that all osaxen add keywords to the global language namespace... yes,
I thought that might make you squirm.;) Plus the Apple event overhead
makes osax calls about ten times slower than local handler calls.

If the worst comes to the

worst, I can force a dishonorable draw simply by calling the same
scripting addition via MacPython's Carbon support modules, but I'd
really like to punt the blighter out of the ballpark
Unlikely if the C addition is any good. Anyway, why? The competitive
advantage of Python is programming speed, especially for larger problems
than this.

Yep. Plus lots and lots and looooots of amazing wonderful shiny toys
to play with! Coming from a language that has at most a few dozen
native libraries - most of which, incidentally, were written by me :p
- to something like Python... I tell you, while I'm no Python weenie
myself (while it's pretty damn decent by mainstream standards, it
still falls some way short of my "Perfect" scripting language) for the
time being at least you'd need to snap most all of my fingers to
detach it from my vice-like grip. <g>

If Psyco runs on Apple, try that.

It might work under Darwin, but I don't really know and am far too
much of a C lightweight to find out by myself. Still, if me mighty
opponent fancies another round I might take a look at it then.

Thanks, and we'll see how it goes... :)

has

(p.s. I'm only really baiting the poor lad 'cos he works for the folks
that produce my favourite AppleScript environment, the quirkily Gallic
yet also wonderfully deep and customisable Smile platform
<http://www.satimage-software.com/>, and it'd just tickle me pink if
they'd make it work with Python as well. Friendly joust.;)

[Timo Virkkala]

has wrote:

(p.s. If your interested, the numarray script takes about 1 sec on my
G4/867 running OS10.2.6 - about same speed as the original example.
Only change I made was replacing numint with uniform to get reals. But
numarray wins on sheer size and breadth of functionality, imnsho...;)

How long does the AppleScript version take? We want results here! *grin*

--
WT

[has]

Timo Virkkala <[e-mail]> wrote in message news:<JR*************@read3.inet.fi>...

has wrote:

(p.s. If your interested, the numarray script takes about 1 sec on my
[Gahhh! I can't believe I just wrote "your"! I did, of course, mean
"you're". <smak> x100]
G4/867 running OS10.2.6 - about same speed as the original example.

How long does the AppleScript version take? We want results here! *grin*

"About the same speed as." :)

(Though try to coerce the otherwise impenetrably packed array to an
AppleScript list afterwards, and you'll be lucky to finish afore the
Heat Death of the universe. ;p)