wxMaxima version: 13.4.0
Maxima version: 5.31.1
Maxima build date: 2013-09-24 09:49:12
Host type: i686-pc-mingw32
Lisp implementation type: GNU Common Lisp (GCL)
Lisp implementation version: GCL 2.6.8
(declare(a_1,nonscalar),declare(b_1,nonscalar),amat:matrix([a_1,b_1])
,bmat:matrix([b_1],[-a_1]),ldisp([amat,bmat,amat.bmat]))
Now the output gives 0 for amat.bmat which also shows the declare(..,nonscalar) did NOT work as it should because the answer one would desire in this case is a_1.b_1 - b_1.a_1
This is an example of the need to denote variables as non-commute. For example in my particular need to express symbolically a block matrix which has other matrices within it of arbitrary dimensions and we want to multiply this by another block matrix, assuming the dimensions of the ' inside ' matices are such that they are commensurate for multiplication, retaining the correct order since we want to assume in general the ' inside ' matrices do not commute .
Rupert Swarbrick
2014-05-05
Well, this is "by design". It might not be the behaviour you are after, of course.
To get the behaviour you need, the solution is to explicitly tell Maxima to use non-commutative multiplication inside matrix products. The relevant flag is matrix_element_mult
:
(%i19) amat:matrix([a_1,b_1]); (%o19) [ a_1 b_1 ] (%i20) bmat:matrix([b_1],[-a_1]); [ b_1 ] (%o20) [ ] [ - a_1 ] (%i21) ldisp([amat,bmat,amat.bmat]), matrix_element_mult="."; [ b_1 ] (%t21) [[ a_1 b_1 ], [ ], a_1 . b_1 - b_1 . a_1] [ - a_1 ] (%o21) [%t21] (%i22) ldisp([amat,bmat,amat.bmat]), matrix_element_mult="*"; [ b_1 ] (%t22) [[ a_1 b_1 ], [ ], 0] [ - a_1 ] (%o22) [%t22]
The default behaviour is matrix_element_mult = "*"
, which gave the zero you didn't want.
I agree that it feels slightly clunky to have to tell Maxima how to do multiplication. I guess another option for you would be to permanently bind matrix_element_mult
to "." and then to explicitly declare things scalar. I haven't checked, but I think that should work. (It sounds like it would quickly get very annoying though!)
Anyway, I'm closing this bug, because I think it's a case of the design not being quite what you were expecting, rather than an implementation bug. Obviously, feel free to re-open and explain what I've misunderstood about the report if I'm wrong.
Rupert Swarbrick
2014-05-05
dan hayes
2014-05-05
Ok thanks that exact did not work for me but very closely related did : matrix_element_mult:"" , I don't know what version of maxima you were using and why
matrix_element_mult="" did work in your case but not in mine.
On Monday, May 5, 2014 4:11 PM, Rupert Swarbrick rswarbrick@users.sf.net wrote:
* status: open --> closed
[bugs:#2729] declare(...,nonscalar) bug
Status: closed
Group: None
Created: Sat May 03, 2014 07:14 AM UTC by dan hayes
Last Updated: Mon May 05, 2014 09:11 PM UTC
Owner: nobody
wxMaxima version: 13.4.0
Maxima version: 5.31.1
Maxima build date: 2013-09-24 09:49:12
Host type: i686-pc-mingw32
Lisp implementation type: GNU Common Lisp (GCL)
Lisp implementation version: GCL 2.6.8
(declare(a_1,nonscalar),declare(b_1,nonscalar),amat:matrix([a_1,b_1])
,bmat:matrix([b_1],[-a_1]),ldisp([amat,bmat,amat.bmat]))
Now the output gives 0 for amat.bmat which also shows the declare(..,nonscalar) did NOT work as it should because the answer one would desire in this case is a_1.b_1 - b_1.a_1
This is an example of the need to denote variables as non-commute. For example in my particular need to express symbolically a block matrix which has other matrices within it of arbitrary dimensions and we want to multiply this by another block matrix, assuming the dimensions of the ' inside ' matices are such that they are commensurate for multiplication, retaining the correct order since we want to assume in general the ' inside ' matrices do not commute .
Sent from sourceforge.net because maxima-bugs@lists.sourceforge.net is subscribed to https://sourceforge.net/p/maxima/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
Maxima-bugs mailing list
Maxima-bugs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/maxima-bugs