Need help resolving accidental (honest!) language pissing match

[has]

"Terry Reedy" <tjreedy at udel.edu> wrote in message news:<mailman.515.1086192193.6949.python-list at python.org>...
> "has" <has.temp2 at virgin.net> wrote in message
> news:69cbbef2.0406020615.7540ad0 at posting.google.com...
> > <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.;)