[Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation]

Huaiyu Zhu huaiyu_zhu@yahoo.com
Thu, 13 Jul 2000 22:53:38 -0700 (PDT)

On Thu, 13 Jul 2000, Paul Prescod wrote:

> It all depends on who works on it and how hard they work. I really can't

So can some one answer this question for sure:

Is it definitely possible to introduce .* ./ etc without much more
difficulty than introducing @* and @/ and so on?

If this is the case we do not need a new symbol.

> Perhaps the best bet would be for you to make a matrix variant of Python
> so popular that we could see the audience in terms of downloads and
> discussions.

That's exact what I'm doing.  By far the largest hurdle to MatPy was the
lack of binary operators.  2/3 of user discussions is on the the most
economic usage of existing symbols.  1/3 of discussion is on how to make it
work on Windows, because of relative imports and case insensitivity.

To attract users I really need to let octave users know its existence, but
this would be futile before we get symbols for both matrix and element

Here are a few indications of user support.  Some Windows users have
enthusiastically followed it for more than a month despite having to rename
several files and change module names for each release.  It was only fixed
last weekend.  I'd regard this as a testament of its usefulness and
potential.  People have also hacked the python parser and the interactive
interpreter to support additional features.  Some have also promised to
supply additional C implementations of numerical procedures.

All I had promised for this was to make an easy interface for matrix
computation that works with Python, for my own use.  Right now the only
remaining hurdle to this goal is the lack of suitable symbols, and we are on
the verge of overcoming it.

> There must be a more compact syntax! Even without knowing the semantics:
> from matrix import tickmult, backslash
> backslash( tickmult( X, X ), tickmult( X, y ))

You are almost there.  :-) The current MatPy expression is
	solve (X.H() * X, X.H() * y)

> > Now look at the total number of users of matlab/octave, and ask: Is python
> > really so inferior that most of them wouldn't switch to python?
> I have no idea. If the primary difference between expensive matrix
> packages and Python is syntax, perhaps you and I should incorporate and
> exploit that market inefficiency. :)

The market is efficient.  Matlab does worth that much (or even more).  It
does take that much human labor to get to that stage, so sadly we can't get
rich by following them.  On the other hand, open source may beat them
easily, as long as

1. we are using a better language which has more potential
2. users have incentive to contribute because it's already useful
3. there's no big hurdle beyond what's already in Numerical Recipe

I'm sure I can recruit enough developers to solve any numerical problem, as
long as you don't ask them to hack the python parser!  That's what I ask the
python developers for.

> Michael Hudson has a tagline that made me laugh out loud:
>   I saw `cout' being shifted "Hello world" times to the left and
>   stopped right there.
>                                                     -- Steve Gonedes
If this was a notation used in a century's worth of mathemetical papers, it
might not seem that strange.  Could C++ stream IO ever make into just one
mainstream math paper?

> How long until some enterprising Python programmer makes a utility that
> polls the website, and generates an email version of each message as it
> appears? :)

The same length of time that takes an enterprising Python programmer to
find the principal axes of a set of data using eigen decomposition. :-)

think-domain-specific-ly y'rs