[MATRIX-SIG] reverse of take?

[Andrew P. Mullhaupt]

At 10:45 AM 6/30/97 -0400, Aaron Watters wrote:
>
>Take should  have an inverse, and in my case I am fiddling during
>spare moments on a win95 box, and I don't have time right now
>to learn how to build other peoples stuff there.  I suspect old S
>hackers might run into something like this in NumPy and say "huh?"
>and go back to S.

Not at all. take is taken from APL, and most S programmers of any
stature at all are fluent in APL. The reason for this is that S is
sort of an 'unconscious' APL derivative - and there is a lot you can
learn from APL. Recently, S has become much more widely used, and
so you _will_ find a lot of newbie S users running around who don't
know much about APL - but that's OK, most of them will not be coming
across Python yet, either.

S is a very demanding language to understand since it is such a wide
sprawling mass of all sorts of stuff. It's a little like PL/I in that
sense but S was never really designed, and so it turns out to be more
or less a superset of APL, Lisp, and pretty much Numerical Python, too.

Scientifically oriented interpreters have been around for quite a while
now - the first generation was APL in 1963. S started in the late 60's,
and this is well to keep in mind - there is a _ton_ of experience in
these communities, especially with crystalized rigid language design as
in APL and the amoebic evolution of S.

What most programmers literate in scientific interpreters will do when
they come to Numerical Python is:

1. Nice fast second generation interpreter, fine object orientation,
   good extensibility, decent embeddability. Object orientation OK. As
   usual, TK is integrated.

2. Graphics not tightly integrated - Yet.

3. Pressure of users will probably revise unfortunate limitations on indexing,
   eliminating the need for some of the functions - (take is an example).

4. Hope they don't fall for the GC nonsense. (Been there, done that with
   APL and S). Doubt they understand VM yet, but maybe the Linux community
   will spread that gospel.

5. Threading is an unresolved issue - but it doesn't seem to get in the way
   of using multithreaded libraries (e.g. Sun Performance Library, etc.).

6. Default argument processing is consistent, interesting, but also annoying.
   However, small idioms suffice to produce the desired behaviors, so no
   problem here.

7. Event processing probably will turn out OK, but a custom main loop for
   fast response time is probably necessary. Looks like some people already
   are working on this.

8. Everything is a reference  - and the reference counting is done well.
   This helps reduce memory waste of large objects by increasing it for
   small objects. Probably a loser for memory bandwidth, but that can be
   treated easily for large objects.

9. Installation is peculiar, but this is easily remedied, too.

10. IT'S FREE, COMES WITH SOURCE, AND _NO LICENSE MANAGER_!

Give you a hint, Aaron. Numerical Python is almost identical to about 90%
of the S programming language, is frequently tens or hundreds of times faster
than the equivalent S code, costs nothing, and your sysadmin might even
like it. Sure. Lots of S programmers will just walk away. But don't hold
your breath.

Later,
Andrew Mullhaupt


_______________
MATRIX-SIG  - SIG on Matrix Math for Python

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