Python

To what extent are APLers aware of Python's array oriented
capability? My group is in the process of comparing various
languages in their ability to represent a generic filter estimation
problem in missile defense. I was surprised to see my APL2 version
translated to Python in almost line-for-line fashion, with very
similar execution efficiency. What are Python's pros and cons
generally? Thanks.

On Aug 25, 7:15*am, Jack <jgr...@comcast.net> wrote:
> To what extent are APLers aware of Python's array oriented
> capability?

I can't talk about the general pros and cons of Python, but I have
looked briefly at the language and the numerical library which I
believe goes under than name of NumPy. I have also had the pleasure of
meeting the author of the NumPy a few times... Jim Hugunin , who I
believe is on the "Dynamic Languages" team at Microsoft, acknowledges
that the library was inspired by APL in some of the introductory
texts.

It is true that with NumPy, Python contains functions (or should I say
"methods") which work on arrays and that you can translate a subset of
APL more or less line-by-line to NumPy (as you can to SmartArrays, or
using Dyalogs APL-to-C# translator). Performance will depend very much
on what you are doing. For example, I don't believe NumPy offers bit
booleans, and many APL interpreters have highly tuned algorithms for
common APL idioms.

In my opinion, the MAIN problem with translation to NumPy, SmartArrays
or C# is that these languages don't function as a "tool of though" for
array thinking. In the resulting code, "methods" take a list of
parenthesised, comma-separated arguments, which turns expressions
"inside out", making them much less readable (IMHO). Also, although
the notion of passing function pointers does exist in many other
languages than APL, without an infix, operator-aware notation, the
languages just do not assist array-oriented thinking in the way that
the APL does.

I maintain that APL is a more appropriate "Tool of Thought" for
working in any area where array processing algorithms are changing. I
suspect that many APL development environments also have features
which are finely tuned to support this kind of R&D.

Yes, I agree with Morten on this.

On Python generally, I've played with it, and it is an interesting
language. (We might well add an interface to from APLX, in the same
way that we have with Ruby). However, it has one feature which seems
to me so spectacularly bad that I personally would never touch it,
namely the fact that the program logic depends on white-space
indentation. Hence:

if x < 0:
x = 0
print 'Blah blah'

means something different than:

if x < 0:
x = 0
print 'Blah blah'

In general, if you want a Python-style language, Ruby seems to me to a
better choice.

(Just my personal opinion you understand. Python lovers: Please send
hate-mail to /dev/null)

Richard Nabavi
MicroAPL Ltd

It's actually worse. This:

> if x < 0:
> * * * x = 0
> * * * print 'Blah blah'

might be perfectly well-formed Python code while this

> if x < 0:
> x = 0
> print 'Blah blah'

might not.

<tabs> are not permitted in Python...

Kai

Semantically valid indentation, that IS a bit weird... :-) But it
could be made to work if you used an editor that enforced indentation
rigorously. Gupta SQLWindows (later Centura and subsequently off the
market, I believe) came equipped with one of these. It was actually
quite convenient, you never had to think about indentation - it just
happened automagically.
I've never seen this idea catch on anywhere else - makes one wonder
what the drawback is. "Prettyprinting" can do the same thing, of
course, only then it's to late to be of any real use.

On the topic of appearances: Semantic color-coding has helped
immensely in modern editors. But it is all based on character
foreground colours. What about background colours? One might have an
option to put different background colours (light pastels, I suggest)
on blocks of code (say between pairs of parens or brackets). This
would be especially useful in legacy applications where deeply nested
blocks (and expressions with lots of parens) are common.

Perhaps less useful in well-written APL where you are more able to
avoid excessive "blocking".

Thoughts, anyone ?

kai wrote:
> <tabs> are not permitted in Python...

Huh? Tabs are fine in Python programs and are
replaced with spaces equivalent to 8-character
tab stops by the Python lexer.

On Aug 27, 2:21*am, Stuart McGraw <smcg...@acedialup.com> wrote:
> kai wrote:
> > <tabs> are not permitted in Python...
>
> Huh? *Tabs are fine in Python programs and are
> replaced with spaces equivalent to 8-character
> tab stops by the Python lexer.

The APL wiki runs on MoinMoin which is a Python Wiki. When changing
the configuration it happens from time to time that I forget about
this and press accidentically the <tab> key - that results in a
"configuration error".

I am using the latest version of MoinMoin/Python with standard config.
It MIGHT be the case that one can change this somehow but I doubt
that: there are warnings in MoinMoin everywhere to add <tab> chars.

Stuart McGraw wrote:
> kai wrote:
>> <tabs> are not permitted in Python...
>
> Huh? Tabs are fine in Python programs and are
> replaced with spaces equivalent to 8-character
> tab stops by the Python lexer.

I believe that depends on whether the tabs actually reach Python

some editors may already have substituted more or less than 8 spaces
before saving the script

On Aug 26, 11:00*pm, admin9...@hotmail.com wrote:
> Semantically valid indentation, that IS a bit weird... :-)

Python is not the only language with semantically valid indentation.
Haskell is another. I'd rather have that than ignored whitespaces
(like in Fortran...). ^__^
--
Stefano

microapl@microapl.demon.co.uk wrote:
> Yes, I agree with Morten on this.
>
> On Python generally, I've played with it, and it is an interesting
> language. (We might well add an interface to from APLX, in the same
> way that we have with Ruby). However, it has one feature which seems
> to me so spectacularly bad that I personally would never touch it,
> namely the fact that the program logic depends on white-space
> indentation. Hence:
>
> if x < 0:
> x = 0
> print 'Blah blah'
>
> means something different than:
>
> if x < 0:
> x = 0
> print 'Blah blah'

ah, the little things that turn people off

David Barron said he would never touch a language which returned "false"
to the expression 1<2<3

another prof would never touch a language whose errors messages
consisted of only 2 words, one of which was ERROR

a lot of people shy away from languages where 2×3+4 evaluates to 14

I knew somebody who wouldn't buy an otherwise suitable house because the
present occupants had furnished it throughout with plastic imitation
wood grain, and it looked tacky

there again, somebody else wouldn't buy a house because she didn't like
the wallpaper in the downstairs loo

I never liked the way Unix shell scripts treated explicit tabs
differently from a visually identical sequence of spaces, but there's a
big difference between "not liking" and "never touching"

/phil