[Numpy-discussion] Re: Please chime in on proposed methods for arrays

[Joe Harrington]

I'll start by saying something positive: I am very encouraged by all
the work that's going into resolving the small/big array split!

That said, I view a.Sin as a potentially devastating change, if
traditional functional notation is not guarranteed to be preserved
forever.

>From a learning user's perspective, having to say a.sin() or a.Sin
rather than sin(a) will be enough to make most people stay away from
numerical python.  I say this from experience: most of what Python
does well, guile also did well.  After the IDAE BoF at the 1996 ADASS
meeting, we considered whether guile would be a better platform than
Python.  It had a lot of development force behind it, had all the
needed features, etc.  We asked our audience whether they would use a
lisp-based language.  There was laughter.  The CS people here know
that lisp is a "beautiful" language.  But nobody uses it, because the
syntax is so different from the normal flow of human thought.  It is
written to make writing an interpreter for it easy, not to be easy to
learn and use.  I've tried it about 8 times and have given up.
Apparently others agree, as guile has been ripped out of many
applications, such as Gimp, or at least augmented as an extension
language by perl or python, which now get most of the new code.
Normal people don't want to warp their brains in order to code.

Consider the following:

math:
            2      1/2
    -b +- (b - 4ac)
x = ------------------
          2a

IDL:

x = (-b + [1.,-1] * sqrt(b*b-4*a*c)) / (2*a)

lisp:

(let x (/ 
          (+
             (- b)
             (sqrt (- 
                      (* b b) 
                      (* 4 a c))))
          (* 2 a)))

You can verify that you have coded the IDL correctly at a glance.  The
lisp takes longer, even if you're a good lisp programmer.  Now
consider the following common astronomical equation:

           sin(dec) - sin(alt) sin(lat)
cos(a)   = ----------------------------
                cos(alt) cos(lat)

IDL:

a = acos((sin(dec) - sin(alt) * sin(lat)) / (cos(alt)*·cos(lat)))

proposal:

a = ((dec.Sin - alt.Sin * lat.Sin) / (alt.Cos * lat.Cos)).Acos

readable, but we start to see the problem with the moved .Acos.  Now
try this:

         2
      sin x + cos(tan(x + sin(x)))
a = e

a = exp((sin(x))^2 + cos(tan(x + sin(x))))

a = (x.Sin**2 + (x + x.Sin).tan.cos).Exp

Half of it you read from left to right.  The other half from right to
left.  Again, the IDL is much easier to write and to read, given that
we started from traditional math notation.  In the proposal version,
it's easy to overlook that this is an exponential.

So, I don't object to making functions into methods, but if there's
even a hint of deprecating the traditional functional notation, that
will relegate us to oblivion.  If you don't believe it still, take the
last equation to a few non-CS types and ask them whether they would
consider using a language that required coding math in the proposed
manner versus in the standard manner.  Then consider how much time it
would take to port your existing code to this new syntax, and verify
that you didn't misplace a paren or sign along the way.

A statement that traditional functional notation is guarranteed always
to be part of Numeric should be in the PEP.  Even calling it syntactic
sugar is dangerous.  It is the fundamental thing, and the methods are
sugar for the CS types out there.

--jh--