Matlab vs Python (was RE: Discussion: Introducing new operators for matrix computation)

[Huaiyu Zhu]

On 18 Jul 2000 02:01:58 GMT, Kevin Jacobs <jacobs at darwin.epbi.cwru.edu> wrote:
>What if it could be as simple as:
>
>e(r'(A .* B)\C') # --> PyAlgebra.evaluate(r'(A .* B)\C', globals(), locals())
>where A, B and C are bound to variables in the current namespace
>automatically?  Does this not go 95% of the way toward the ideal solution?

Well, not that much.  What about this:

webpage = webobject(url)
result = e(r'transform * get_data_from(webpage)')

If it is allowed wouldn't we allow

result = e(r'transform * get_data_from(webobject(url))')

or even using "http:..." in place of url?  Eventually, wouldn't the
e(r'...') be able to parse the whole python grammer?

If on the other hand it is limited to numerical type objects only it is too
limited.  In MatPy.gplot we use lists, dicts and strings to deal with
multiline plots and titles, etc.

Well, maybe I just don't like to treat numerical type objects any
differently from other objects because they are intermixed all over in the
programs.  Otherwise a python-octave gateway or just stick with octave may
even be preferable.

One of my biggest gripe about matlab is it forces me to treat strings as
part of matrix.  Now you are asking me to treat matrix as part of string.
:-)

>I disagree with your conclusion.  Having worked with many algebra and
>statistical languages, I know the road you are undertaking.  It doesn't and
>can't stop with one extra dot in the grammar.  To do it right, you need the
>ability to break more rules that are intrinsic to Python's core.  e.g.,
>consider changing the rules for '\' as above.

This makes some sense, but I know a lot of people who can resist the
temptation of other syntactic sugar, except infix operator for arithmetics -
it's just too good a thing to miss.

There are proposals for using @/ and /@ for two directions of division, or
using % for left division.  I'm comfortable with the current solve(a,b), or
maybe a shorter sol(a,b) but am open to any suggestions.

>Another advantage to compromising and implementing a domain specific
>mini-language is that it simplifies some very tough design issues that only
>come up when working with the full Python grammar.  Some of these syntactic
>and semantic issues are very likely irreconcilable.  In the end we could end
>up with a any number of splinter languages with inferior support and narrow
>audiences.  Lets not forget we are a community of users with very diverse
>goals, all trying make our lives easier by building better tools.

I'm not quite with you here.  Exactly for the purpose of making numerical
objects and other objects work seemlessly together I am against changing
syntactic structure, and only for adding syntactic contents within current
structure. Well, let's see if this makes sense.  What I'm saying is, .* is
just another operator, so if you replace it with * the syntax structure does
not change. On the other hand, using e(r'...') changes the structure because
variable names within a string suddenly gets out.  In this sense it is less
like a function call with a string literal argument, but rather a special
syntax zone delimited with strange combination symbols e(r' and ').  If a
program is littered with such special zones the effect is very much like an
aspect of Perl that I happen to dislike.

Just my thoughts.

Huaiyu