[MATRIX-SIG] random number generator?

[David J. C. Beach]

Geoffrey Furnish wrote:

> Speed is the most important counter argument, imo, and one which ought
> to be of considerable concern to NumPy customers.  I have previously
> done timing tests between loops containing expressions like:
>
>         a[i] = a[i] + x[i];
>
> versus
>
>         a[i] += x[i];
>
> in C and C++.  The += form was as much as 20% faster on some tests on
> some architectures.
>
> Frankly, for a language litered with "self." on nearly every line, it
> is very hard for me to buy that "a = a + 1" is syntactically more
> beautiful.  It certainly is slower.

There's nothing inherently slower about "a = a + 1" than there is about "a +=
1".  The difference is in how the compiler interprets them.  Now, any good
optimizing C compiler should transform "a = a + 1" into "a += 1"
automatically.  (Were you using optimizations?)

Perhaps the Python byte code compiler would only look-up the lvalue for a (or
a[i]) once.  This would make "a = a + 1" just as fast as "a += 1".  The point
here is that you're confusing a language difference for a performance
difference.  The language is what you type, but the performance depends on how
the compiler/interpreter transforms that language into machine instructions.

Come to think of it, I'm pretty sure that FORTRAN users (not that I like the
language) don't have either a += or a ++ operator, and I'd be pretty willing
to bet that you're a[i] = a[i] + x[i] test on a good optomizing FORTRAN
compiler would outperform the C version of a[i] += x[i].  You might give it a
try.

As for the litered with "self" argument, I'm assuming that you're complaining
because you're needing to type "self.a[i] = self.a[i] + 1" instead of
"self.a[i] += 1".  Well, I rather like the "self" prefix for object attributes
because it makes it crystal clear that you're setting an attribute of the
object instead of some other variable.  I find that it's easier to read other
people's code when this self "littered" style is employed.  And I could be
wrong, but I doubt I'm the only one.

And I think there's room for some fair comparison here.  How do you like the
complete lack of standard's for container classes in C/C++?  Sometimes people
use Rogue Wave's classes, sometimes they use STL, sometimes he write they're
own, sometimes they you their "in-house" class library.  But they're all
different:  different ways to get elements, slices, append, insert, etc.  I'll
grant you in an instant that C++, as a machine-compiled language, runs faster
than Python byte-compiled code, but it sure seems to lack any consistency.  In
C++, templates are generally a mess, there are six different kinds of
inheritance (public virtual, protected virtual, private virtual, public,
protected, and private), compilation tends to be a slow process, and you get
all the advantages (AND DISADVANTAGES) a strongly typed language.  (In Python,
I was able to use the same function for a runge-kutta4 in python for a single
equation system, and a multiple equation system just by virtue of whether I
passed it floats or matrices.  You could get that same behavior from C++, but
you'd have to go well out of your way to spoof dynamic typing, or simply write
multiple versions of runge-kutta4.)

I could go on, but this email is already too long as it is.  Even if you don't
like the lack of a '+=' (most languages lack this feature which is really only
in C, C++, JAVA, etc.)

I'm pretty willing to bet that the Python language as a whole more than stands
up to C or C++.

Dave

--
David J. C. Beach
Colorado State University
mailto:beach@verinet.com
http://www.verinet.com/~beach




_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________