Dear Volker,
Thank you for your thoughtful reply. As I said before, it is certainly not
my intent to try to talk anybody out of doing something useful. My concern
was about the possibility that a lot of work may end up being invested into
something that is already covered by existing Maxima code.
I admit that I am not an educator. I use Maxima on a daily basis as a
research/engineering tool. Just to name a few examples, I have used Maxima
in recent years to generate C++ code for thermal radiation modeling; I have
used Maxima to verify the derivation of the field equations of a modified
gravitational theory from its Lagrangian, and obtain some solutions; and I
have used Maxima to do electroweak unitarity calculations in quantum field
theory. Hopefully, these qualify as something more than just playing a
self-serving sudoku game. I don't even like sudoku :-)
So, my comments are coming from this perspective. But, I think I appreciate
the educational aspect of what you are saying. The main feature of the
vector object you are proposing, then, appears to be the fact that
expressions such as x*[a,b,c] are not automatically evaluated into
[x*a,x*b,x*c], hence the equation structure remains apparent to the student
user. Is this a correct assessment?
If this is correct, then can we not just have a flag that prevents the
automatic evaluation of such expressions in the existing vector/matrix code?
With this flag, we would have
(%i13) u+r*v+s*w;
(%o13) s*[7,8,9]+r*[4,5,6]+[1,2,3]
without introducing a new data type and duplicating a lot of code. What do
you think?
Regarding expressions like vector.matrix, I think that if the dimensions do
not allow evaluation of the dot product as an inner product, an error should
be thrown. It is pointless to leave an invalid expression unevaluated.
As to vector^^-1, I don't think it is a mathematically meaningful
expression. The only possible meaning for such an expression would be the
solution to the equation,
v.x = 1,
but for any vector v with two or more elements, this equation has infinitely
many solutions. If you ask me, vector^^-1 should throw an error.
Yes, Maxima sometimes "helpfully" treats row and column vectors the same
(even when they are represented by matrices, not lists.) I was never
comfortable with this. Sometimes it is helpful as it allows you to omit a
few calls to transpose(), but at other times, it just hides real errors in
your calculation. I also think it is bad for pedagogical reasons, since it
further blurs the difference between covariant and contravariant vectors.
As to the commutative (*) product of matrices and vectors in Maxima, this
never made sense to me! I suppose there is some obscure utility to
componentwise multiplication of vector/matrix quantities, but as far as I am
concerned, it's just a particularly nasty way to introduce bugs in a Maxima
program, when you accidentally use * instead of . and rather than getting an
error, you get a nonsense result. In my opinion, expressions such as
[1,2]*[3,4] should throw an error. Trouble is, there's probably lots of
existing Maxima code that relies on this "feature", so changing it would
probably break a lot of things.
Viktor
-----Original Message-----
From: van Nek [mailto:van.nek at arcor.de]
Sent: Tuesday, November 18, 2008 6:41 AM
To: Viktor T. Toth
Cc: Maxima at math.utexas.edu
Subject: Re: [Maxima] proposal about vectors
Am 17 Nov 2008 um 20:48 hat Viktor T. Toth geschrieben:
> Volker,
>
> I am writing somewhat hesitatently, since it's not my intent to talk
anybody
> out of writing something useful. So, I ask for your forgiveness if I am
just
> missing something obvious, but it seems to me that much of the
functionality
> you propose already exists.
Viktor,
I don't think so. My approach was originally invented in 2004 by my vector
algebra
studends, who obviously missed a readable form of vector expressions. Since
that time I
was often asked by teachers in my country to go that direction.
Collapsed expressions like
(%i1) [-3,0,1]+p*[0,5,4]+q*[9,8,0];
(%o1) [9 q - 3, 8 q + 5 p, 4 p + 1]
(%i2) load(eigen)$
(%i3) covect([-3,0,1])+p*covect([0,5,4])+q*covect([9,8,0]);
[ 9 q - 3 ]
[ ]
(%o3) [ 8 q + 5 p ]
[ ]
[ 4 p + 1 ]
do not look very funny for studends who are doing thier first steps with
vectors. From a
paedagicical point of view this is a complete mess.
Ok, if Maxima should not care about people who are learning, then you are
right. People
who already have the necessary structures in their brains can easily read
these expressions.
People like you and me don't care about that.
I act here for all these 20 years old kids who want to use Maxima in their
work learning
vectors. (Perhaps there might be lots of potential developers for the
future.)
> For instance, while there are differences in detail, I get much the same
> functionality that you propose if I just do this:
>
> vector([elements]):=transpose(matrix(elements));
>
> which lets me define a vector as a column matrix. Some of the code from
your
> example then would look like this:
>
> (%i1) vector([elements]):=transpose(matrix(elements));
> (%o1) vector([elements]) := transpose(matrix(elements))
> (%i2) v:vector(a,b);
> [ a ]
> (%o2) [ ]
> [ b ]
> (%i3) w:vector(c,d);
> [ c ]
> (%o3) [ ]
> [ d ]
> (%i4) m:matrix([i,j],[p,q]);
> [ i j ]
> (%o4) [ ]
> [ p q ]
> (%i5) declare(x,nonscalar);
> (%o5) done
> (%i6) v+v;
> [ 2 a ]
> (%o6) [ ]
> [ 2 b ]
> (%i7) v+w;
> [ c + a ]
> (%o7) [ ]
> [ d + b ]
> (%i8) v.w;
> (%o8) b d + a c
> (%i9) x*v;
> [ a ]
> (%o9) x [ ]
> [ b ]
> (%i10) s*v;
> [ a s ]
> (%o10) [ ]
> [ b s ]
> (%i11) alias(vec,vector);
> (%o11) [vec]
> (%i12) plane1:vec(1,2,3)+p*vec(4,5,6)+q*vec(7,8,9);
> [ 7 q + 4 p + 1 ]
> [ ]
> (%o12) [ 8 q + 5 p + 2 ]
> [ ]
> [ 9 q + 6 p + 3 ]
> (%i13) plane2:s*vec(9,8,7)+r*vec(6,5,4)+vec(3,2,1);
> [ 9 s + 6 r + 3 ]
> [ ]
> (%o13) [ 8 s + 5 r + 2 ]
> [ ]
> [ 7 s + 4 r + 1 ]
> (%i14) map("=",transpose(plane1)[1],transpose(plane2)[1]);
> (%o14) [7 q + 4 p + 1 = 9 s + 6 r + 3, 8 q + 5 p + 2 = 8 s + 5 r + 2,
> 9 q + 6 p + 3 = 7 s + 4 r
+
> 1]
> (%i15) algsys(%,[p,q,r,s]);
> 16 %r2 + 13 %r1 + 16
> (%o15) [[p = %r1, q = %r2, r = - --------------------,
> 3
> 13 %r2 + 10 %r1 +
> 10
> s =
> --------------------]]
> 3
Now you have reached the point where you don't go further. Let me do it:
(%i32) params: [p = -1/3*(16*u+13*v+16),q = 1/3*(13*u+10*v+10)]$
(%i33) plane2, params;
[ - 2 (13 v + 16 u + 16) + 3 (10 v + 13 u + 10) + 3 ]
[ ]
[ 5 (13 v + 16 u + 16) 8 (10 v + 13 u + 10) ]
[ - -------------------- + -------------------- + 2 ]
(%o33) [ 3 3 ]
[ ]
[ 4 (13 v + 16 u + 16) 7 (10 v + 13 u + 10) ]
[ - -------------------- + -------------------- + 1 ]
[ 3 3 ]
Compare this to
(%i21) params: [p = -1/3*(16*u+13*v+16),q = 1/3*(13*u+10*v+10)]$
(%i22) vector_rebuild(plane2,[v,u]), params;
(%o22) u*vector(7,8,9)+v*vector(4,5,6)+vector(1,2,3)
No further comment.
>
> There are, of course, some differences. You propose not to simplify
> automatically expressions such as v.w; perhaps that is a good thing, but
one
> can already achieve that by quoting:
>
> (%i16) 'v.'w;
> (%o16) v . w
> (%i17) %,eval;
> (%o17) b d + a c
Quoting doesn't help. This is just a copy of the input line.
I want to read
(%i13) u+r*v+s*w;
(%o13) s*vector(7,8,9)+r*vector(4,5,6)+vector(1,2,3)
instead of
(%i15) u+r*v+s*w;
(%o15) [7*s+4*r+1,8*s+5*r+2,9*s+6*r+3]
> Another distinction is that your scheme doesn't differentiate row and
column
> matrices, whereas in my example, we get an error:
>
> (%i18) v.m;
> incompatible dimensions - cannot multiply
> -- an error. To debug this try debugmode(true);
I guess you meant the line
(%i22) v.m, vector_simp;
(%o22) vector(a,b) . matrix([i,j],[p,q])
This should show that vector . matrix won't be evaluated at all (even if the
demensions fit).
If that's not wanted an error can easily be thrown. What about vector^^-1 ?
Error or leave
unevaluated?
Generally the code is supposed to recognize dimensions that do not fit:
(%i3) load("vectors.lisp")$
(%i4) m1:matrix([1,2,3],[4,5,6])$
(%i5) m2:transpose(m1)$
(%i6) v:vector(1,2,3)$
(%i7) display2d:false$
(%i8) m1.v;
(%o8) matrix([1,2,3],[4,5,6]) . vector(1,2,3)
(%i9) m2.v;
(%o9) matrix([1,4],[2,5],[3,6]) . vector(1,2,3)
(%i10) m1.v, vector_simp;
(%o10) vector(14,32)
(%i11) m2.v, vector_simp;
Incompatible dimensions found.
-- an error. To debug this try debugmode(true);
>
> Personally, I don't see this is a problem though, on the contrary: often,
it
> is important to treat row and column vectors as distinct types of
entities,
> both for pedagogical reasons and also in practical situations when the
> underlying coordinate system is not rectilinear. In any case, when we wish
> to multiply a row vector with a matrix on the right, we can always write
>
> (%i19) transpose(v).m;
> (%o19) [ b p + a i b q + a j ]
>
>
> What do you think?
(%i1) m1:matrix([1,2,3],[4,5,6])$
(%i2) m2:transpose(m1)$
(%i3) v1:[1,2,3]$
(%i4) load(eigen)$
(%i5) v2:covect([1,2,3])$
(%i6) m1.v1;
[ 14 ]
(%o6) [ ]
[ 32 ]
(%i7) m1.v2;
[ 14 ]
(%o7) [ ]
[ 32 ]
Row and column vectors act the same.
(%i10) v1.m2;
(%o10) [ 14 32 ]
Does this make sense? Or the following?
(%i18) m2*v1;
[ 1 4 ]
[ ]
(%o18) [ 4 10 ]
[ ]
[ 9 18 ]
Just keep the dimensions right and have a lot of fun:
(%i19) m3:matrix([1,2],[3,4])$
(%i20) v3:[1,2]$
(%i21) m3.v3;
[ 5 ]
(%o21) [ ]
[ 11 ]
(%i22) v3.m3;
(%o22) [ 7 10 ]
(%i23) m3*v3;
[ 1 2 ]
(%o23) [ ]
[ 6 8 ]
(%i24) v3*m3;
[ 1 2 ]
(%o24) [ ]
[ 6 8 ]
Seriously speaking: I am sure there are a lots of points to be clearified
and there may be
many mathematical details that I am not aware at this very moment of
development, but the
point of decision is, if Maxima wants to be as much as user-friendly as
possible or if it does
not care about people who are not in this sophisticated state of mind the
Maxima developers
are. Who are the people who should use Maxima?
Maxima is open source and you don't get any money for your work on this
project. You do it
just for fun. Right. But there is a big difference to just solving sudoku
games on your own.
The community of Maxima developers administrates the most valuable open
source CAS
which is available at the moment and is therefor responsible for all the
users on this planet
who want to learn mathematics with the help of an open source CAS.
The actual state of working with vectors in Maxima is from a paedagogical
point of view a
total mess. If the approach I act for is not clever enough please create a
better one.
Volker
>
> Viktor
>
>
>
>
> -----Original Message-----
> From: maxima-bounces at math.utexas.edu
[mailto:maxima-bounces at math.utexas.edu]
> On Behalf Of van Nek
> Sent: Monday, November 17, 2008 5:07 PM
> To: Maxima at math.utexas.edu
> Subject: proposal about vectors
>
>
>
> According to the recent discussion I propose the following
> basic conception for vectors:
>
>
> (%i1) load("vectors.lisp")$
> (%i2) v: vector(a,b)$
> (%i3) w: vector(c,d)$
> (%i4) m: matrix([i,j],[p,q])$
> (%i5) declare(s, scalar)$
> (%i6) display2d: false$
> (%i7) stardisp: true$
>
>
> Implicit simplification:
>
>
> (%i8) v+v;
> (%o8) 2*vector(a,b)
> (%i9) v+w;
> (%o9) vector(c,d)+vector(a,b)
> (%i10) v-v;
> (%o10) vector(0,0)
> (%i11) 0*v;
> (%o11) vector(0,0)
> (%i12) v*x;
> (%o12) x*vector(a,b)
> commutative, non-vector x is displayed left
> (%i13) s*v;
> (%o13) s*vector(a,b)
> (%i14) v.w;
> (%o14) vector(a,b) . vector(c,d)
> (%i15) m.v;
> (%o15) matrix([i,j],[p,q]) . vector(a,b)
>
>
> Explicit simplification:
>
>
> (%i16) v+w, vector_simp;
> (%o16) vector(c+a,d+b)
> (%i17) x*v, vector_simp;
> (%o17) x*vector(a,b)
> (%i18) s*v, vector_simp;
> (%o18) vector(s*a,s*b)
> (%i19) v.w, vector_simp;
> (%o19) b . d+a . c
> (%i20) w.v, vector_simp;
> (%o20) d . b+c . a
> (%i21) m.v, vector_simp;
> (%o21) vector(j . b+i . a,q . b+p . a)
> (%i22) v.m, vector_simp;
> (%o22) vector(a,b) . matrix([i,j],[p,q])
> (%i23) x.v, vector_simp;
> (%o23) x . vector(a,b)
> (%i24) v.x, vector_simp;
> (%o24) vector(a,b) . x
> (%i25) declare(a,scalar)$
> (%i26) v.w, vector_simp;
> (%o26) b . d+a . c
> (%i27) dotscrules:true$
> (%i28) v.w, vector_simp;
> (%o28) a*c+b . d
>
>
> Reconstruction of multiplicative and additive expressions:
>
>
> (%i29) vector_rebuild( vector(s*a+c,s*b+d), [s] );
> (%o29) vector(c,d)+s*vector(a,b)
>
>
> This conception uses as few as possible implicit simplification
> and allows to reconstruct results of multiplicative-additive
> computations in a readable form. E.g. a working example:
>
>
> (%i1) load("vectors.lisp")$
> (%i2) alias(vec, vector)$
> (%i3) display2d:false$
> (%i4) declare([p,q,r,s,u,v],scalar)$
> (%i5) plane1: vec(1,2,3)+p*vec(4,5,6)+q*vec(7,8,9);
> (%o5) q*vec(7,8,9)+p*vec(4,5,6)+vec(1,2,3)
> (%i6) plane2: vec(3,2,1)+r*vec(6,5,4)+s*vec(9,8,7)$
> (%i7) veq: rhs(plane1) = rhs(plane2);
> (%o7) q*vec(7,8,9)+p*vec(4,5,6)+vec(1,2,3) =
> s*vec(9,8,7)+r*vec(6,5,4)+vec(3,2,1)
> (%i8) map(disp, sys: extract_equations(veq))$
> 7*q+4*p+1 = 9*s+6*r+3
>
>
> 8*q+5*p+2 = 8*s+5*r+2
>
>
> 9*q+6*p+3 = 7*s+4*r+1
>
>
> (%i9) params: algsys(sys,[p,q,r,s]);
> (%o9) [[p = %r1,q = %r2,r = -1/3*(16*%r2+13*%r1+16),s =
> 1/3*(13*%r2+10*%r1+10)]]
> (%i10) params: params, %r1=u, %r2=v$
> (%i11) plane1, params;
> (%o11) v*vec(7,8,9)+u*vec(4,5,6)+vec(1,2,3)
> (%i12) plane2, params;
> (%o12)
> 1/3*(13*v+10*u+10)*vec(9,8,7)-1/3*(16*v+13*u+16)*vec(6,5,4)+vec(3,2,1)
> (%i13) vector_rebuild(plane2,[v,u]), params;
> (%o13) v*vec(7,8,9)+u*vec(4,5,6)+vec(1,2,3)
>
>
>
>
> Display properties:
>
>
> (%i1) load("vectors.lisp")$
> (%i2) alias(vec,vector)$
> (%i3) v: vec(1,2);
> [ 1 ]
> (%o3) [ ]
> [ 2 ]
> (%i4) [vectorp(v), matrixp(v), listp(v)];
> (%o4) [true, false, false]
> (%i5) vector_display2d:false$
> (%i6) w: apply(vec,[3,4]);
> (%o6) [3, 4]
> (%i7) [vectorp(w), matrixp(w), listp(w)];
> (%o7) [true, false, false]
>
>
> alternatively
> vector_display2d: col, row or text
> with mode col and row like above and text like
> (%i3) v: vec(1,2);
> (%o3) vector(1,2)
>
>
> Volker van Nek
>
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima