On 5/9/10, Dieter Kaiser <drdieterkaiser at web.de> wrote:
> TOP (1): 2970792 - gradef(s) together with vect package
>
> I think this is a general problem of the parser. When we define literal
> prefix operators like "grad" or "div" functions which starts with the
> same chars no longer works.
We should change the parser so that gradient is not parsed as grad ient.
It seems very unlikely that there is any code which depends on the current
behavior of the parser.
> A workaround is to define the literal operators with a captial letter,
> e.g. "Grad" and "Div". I think we should apply this workaround in the
> vect package,
Opposed. It would be better to fix the underlying problem in the parser.
Also Grad and Div are not typical Maxima names.
> TOP (3): 2011228 - vect redefines "." as commutative, was:Matrix
> multiplication
>
> I think we should cut out the declaration of "." to be commutative.
Agreed.
> The user loses some simplification like a . b - b . a -> 0.
There should a separate inner product function (perhaps named "dot")
instead of repurposing the existing "." operator.
Probably the inner product should be a simplifying function.
> It is clear that the whole package should be reworked too.
Yeah. Maxima's treatment of vectors is pretty confusing.
I'll propose that vectors should be objects distinct from lists
and matrices. As ever, it is easier to predict what's going to
happen when vectors are not confounded with other types.
We would lose some minor convenience but it is much more
important to have clear rules for operations.
This has come up before, and I probably promised to work on the
vect package ....
> Furthermore, I have written a test file for the package vect which shows
> some more bugs we have. I would like to commit this file too.
Yes, please do.
As always, thanks for working on this topic.
best
Robert Dodier