On 3/19/08, Alexey Beshenov <al at beshenov.ru> wrote:
> In my opinion, vect.mac approach is better. Anyway, this behavior could be
> controlled by some flag.
I think the multitude of flags makes it difficult for the user to
understand what is going on, since the same code can have a
different effect depending on flags. So I am not in favor of
introducing another flag.
> Okay, but here "~" is the cross-product operator, so it should be
> named "cross"; "curl" is the other vector calculus operator (also
> known as "rot").
You're right, I was confused.
> "." confuses anyway since "listarith" is "true" by default, so "." works just
> like "dot" operator for lists (vectors are represented as lists in
> vect/vector):
>
> (%i1) [1,2,3] . [4,5,6];
> (%o1) 32
Wow, I didn't know about that ... That seems like something of a
mess since it is not [1 . 4, 2 . 5, 3 . 6] as one would expect from
other listarith-enabled computations.
> Well, "dot" could be introduced to denote not only vector-vector, but also
> scalar-vector commutative multiplication and we can use "*" only for
> scalar-scalar multiplication. Replacing "+" as vector-vector sum operator by
> something else ("plus"?) is bad idea... If we do so, we'll get peculiar
> syntax ("(x cross y plus -z) dot u dot v"), but it will remove "listarith"
> issues. What do you think?
Another way to avoid the whole listarith problem is to represent
vectors as objects distinct from lists, e.g. vector(1, 2, 3)
instead of [1, 2, 3]. Actually I am in favor of that; conflating
different kinds of objects for convenience leads to unexpected
results (e.g. listarith problems with vectors).
> The directional derivative denoted as "dotdel" should be implemented
> in some way.
You're right, dotdel is a distinct operator which should have its own
definition.
> As for curlgrad, graddiv, divcurl, curlcurl, they could be preserved,
> but they are not very important.
I guess I don't see the need for them.
best,
Robert Dodier