Am 18 Nov 2008 um 7:32 hat Viktor T. Toth geschrieben:
> 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.
Viktor,
you are certainly right, it will be a lot of work. I hope I am not too naiv about it. But what I
achieved so far is it double worth! In my daily work I am very close to this stadium of
learning where students come to know the first vectors and to them Maxima output should
look like you would write it on a paper.
I can really understand that to you this is only a very slight difference, but believe me, it is
not. To learning students these small differences can be deep gaps. It is very natural, that
learning students a priori do not have the mathematical structures in theirs brains that we
are used to have.
I believe that my current code combined with a nice one-column-matrix-like output in
wxMaxima will be a great step for education. I hope that Andrej is willing to introduce a new
data type there.
> 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 :-)
I had written a sudoku solver with Maxima that solves every sudoku in a second. I did this
just to finish this time wasting topic.
> 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?
Correct.
> 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?
It is not only preventing the automatic simplification, more crucial is the possibility to
reconstruct the expression after a computation to get it back into a form u+r*v+s*w.
That's what I called vector_rebuild.
Compare it to the manipulations expand and factor in both ways. This is nearly the same.
3*(x+y) <---> 3*x+3*y
vector(1,2)+ t*vector(3,4) <---> vector(3*t+1, 4*t+2)
A CAS should offer both ways.
A flag that prevents automatic evaluation might in fact solve the problem. But listarith:false
does only act on lists. So something like matrixarith:false might help in case of column
vectors. Then vector_rebuild could locally set matrixarith:true to simplify the expression and
reconstruct it inside of the matrixarith:false-environment. Should be possible.
I have no idea how complicate it might be to install such a flag.
> 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.
It is OK by me to throw an error, if a type of expression is not defined. From the
paedagogical point of view this is anyway the best.
> 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.
I also use Maxima for programming and a lot of times I used this "feature".
I don't see any needs to replace the existing code. The development of vectors can be done
absolutely parallel to the existing code. When it's finished some day it can replace the
existing vector code but there is no need to replace list arithmetrics. If there will be a data
type vector then there will be no need anymore to use lists as vectors. On the other hand
you will also be able use these useful operations on lists just as lists without any confusion.
So I don't believe, the development of vectors will break anything. That's the advantage of
introducing a new data type. There are only a very few points of intersection concerning the
simplifier. To achieve the simplifications
vector(a,b) - vector(a,b) --> vector(0,0)
0 * vector(a,b) --> vector(0,0)
vector(a,b) * t --> t * vector(a,b)
I wrote small patches for some simp-functions. Until it is not double checked that these
patches do no harm I plan to put a copy of these patched functions into the vector file so
that they are only in use when this file is loaded (combined with an according warning).
Viktor,
but if the above mentioned flag could be a way out, I would welcome this. Please let me
know if you have any idea how to install such a flag.
Volker
>
> 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
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima