Viktor,
yes to all. Thank you for your time and ideas concerning this topic. If you succeed in
extending listarith to matrix computations, I will code an accordingly new version of
"vector_facsum".
It seems to me that it can be compared to facsum, e.g.
(%i15) facsum(x*a+y*a+b*x+b*y,[a,b]);
(%o15) b (y + x) + a (y + x)
So this might be an appropriate name. Please excuse my bad English here.
Volker
Am 18 Nov 2008 um 11:35 hat Viktor T. Toth geschrieben:
> Volker,
>
> My concern is that rather than fixing whatever needs fixing in the existing
> vector/matrix code, we're introducing a new data type with its own rules and
> evaluations. Is this really necessary? Is the existing vector/matrix code so
> badly broken that it's not worth fixing? Is a new data type really helpful
> to the student, as opposed to making Maxima even more complicated and
> arcane, as we'd now have three distinct ways to represent the same vector,
> i.e., a list, a matrix, and an object of this new vector type?
>
> So far, the issues you raised don't seem that bad, since it seems to me that
> they can be addressed within the present implementation with a moderate
> effort. This includes displaying them in the desired form, evaluating or not
> evaluating them as desired, and providing functions such as the proposed
> vector_rebuild, which sounds like a neat idea to me (though perhaps a more
> appropriate name would be vector_factor or something along those lines,
> since you're really factoring out common coefficients.) And I think
> extending listarith to matrices is a good idea (I can't see the need for
> separate listarith/matrixarith flags), and probably isn't much of an effort
> to implement. If others don't tell us that this is a silly thing to do, I'm
> happy take a look at it myself to see how it could be done.
>
>
> Viktor
>
>
>
>
> -----Original Message-----
> From: van Nek [mailto:van.nek at arcor.de]
> Sent: Tuesday, November 18, 2008 11:10 AM
> To: Viktor T. Toth
> Cc: Maxima at math.utexas.edu
> Subject: Re: [Maxima] proposal about vectors
>
> 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
>