Re: Re: Non-commutative algebra
- To: mathgroup at smc.vnet.net
- Subject: [mg13344] Re: [mg13280] Re: Non-commutative algebra
- From: MJE <evans.nospam at gte.net>
- Date: Mon, 20 Jul 1998 02:50:00 -0400
- Organization: None
- References: <6ocuue$he8@smc.vnet.net> <199807170718.DAA06696@smc.vnet.net.>
- Sender: owner-wri-mathgroup at wolfram.com
Apropos of this topic -
It's OK to say that we should not remove attributes from fundemantal ops
like Plus and Times. I agree, though for experimental purposes, I like
the flexibility. Thanks for giving us that.
However there is one obvious and common case where the Orderless
attribute doesn't apply, namely matrix math. The operation of
multiplying matrices must not have the Orderless attribute.
Try writing out some matrix equations in Mathematica and asking the
program to simplify or otherwise rearrange them. Unless you have
actually constructed the matrices symbolically, it won't work. In
other words, Mathematica does not allow any kind of shorthand for
matrix math. You have to write out {{a[1,1],a[1,2]},{a[2,1],a[2,2]}}
and can't just put A.
There is one, and only one definition for a new symbol like "A": it is,
by decree of Wolfram Research (:-/), a complex number. It can't be a
real number, an integer, or -- a matrix.
In the field of control theory, the whole point of using matrix math is
the shorthand notation, thus:
x-dot = A.x + B.u (system state equation)
y = C.x + D.u (system output equation)
where
x = the n x 1 state vector for
an nth-order system
u = the m x 1 input vector for
a system with m inputs
y = the p x 1 output vector for
a system with p outputs
A = the n x n system (or plant) matrix for an
nth-order system
B = the n x m input matrix for an
nth-order system with m inputs
C = the p x n output matrix for an
nth-order system with p outputs
D = the p x m feed forward matrix for a
system with p outputs and m inputs
In the past I tried to tinker with some Kalman filtering equations in
Mathematica but got nowhere fast. The Kalman theory is derived from
pure symbolic matrix mathematics. The dimensions of the matrices are
irrelevant to the theory, but the fact that they are matrices is
central.
Sometimes you know the values of m,n,p but even in that case, in
Mathematica you still have to write out the full matrices by hand. At
other times, you want to leave m,n,p undefined.
I would say that WRI should take the task of writing the rule base for
symbolic matrix math with the Orderless attribute removed. That's not
a job for the users. I think that this example alone answers David
Withoff's proposition:
> A separate question is whether or not functions such as Expand could or
> should somehow be modified, probably by invoking separate algorithms,
> to handle operations in other algebras. That is an interesting
> question, and one that many people have considered.
Yes, they should invoke separate algorithms for symbols declared as
matrices, once we can make such declarations.
Best regards to the developers,
Mark
___________
Daniel Lichtblau wrote:
>
> > ...Wolfram Research Inc. strongly disapproves of clearing any Attributes or
> > otherwise modifying low level built-in functions, such as Times, Plus etc.,
> > and in particular removing their Orderless attribute. If you do this terrible
> > things may happen to your programs...
>
> and cause cancer in laboratory mice
>
> > ...either immediately or in the future. It is not made clear why we are
> > actually given the opportunity to engage in such unhygienic behaviour, but
> > perhaps it is just to provide a little excitement for those who like
> > living dangerously.
>
> That's about correct.
>
> In some sense the situation is thus: Mathematica supports several
> attributes, and modification thereof can be useful. Mathematica also is
> implemented largely in terms of itself (even the functions written in C
> call Mathematica). Hence modification of default attributes of
> low-level functionsmay be dangerous.
>
> So why do we allow this? Well, one can argue that actually we do not. As
> you saw, removing Orderless for Times is only partially supported. Way
> back someone apparently decided it should not be supported at all, and
> until version 3 it was not. Whether this was a good change (to support
> non-commutative Times in this way) is unclear. We did it mostly for
> purposes of logical consistency, and not because we wanted people to
> actually use it (silly us). Generally it is safe for quick localized
> applications that rely on structural rather than mathematical
> transformations, for example the one you showed. Were you instead to
> Collect with respect to some product you might not have such good
> results, because Collect will rely on Times internally.
>
> Daniel Lichtblau
> Wolfram Research
___________
David Withoff wrote:
>
> > Recently I was showing some computations in non-commutative algebra to
> > my students. This is very easy to do in Mathematica 3.0. Basically all
> > you need to do is to Clear the attribute Orderless in Times and use
> > Mathematica as usual. However, my university (for various reasons)
> > still has Mmma 2.2 installed on all the computers in the class where I
> > teach, so after making my notebook using 3.0 I tried the same
> > computations in 2.2. To my surprise the answers came out wrong! I soon
> > realized that Expand in Mathematica 2.2 has commutativity "built in"
> > quite independently from the Orderless attribute of Times. To see this
> > all you need to do is to evaluate:
>
> I always cringe when I hear of modifying important characteristics of
> basic functions. This rarely has the desired effect. Most functions
> like Expand make basic assumptions about operations such as
> multiplication and addition, in all versions of Mathematica. This is a
> reflection of the fact that most of the underlying algorithms rely on
> those assumptions. If you consider algorithms that are designed for
> use with conventional multiplication and addition, it is rarely the
> case that the same algorithms will continue to work even if the meaning
> of multiplication is changed, and sometimes the algorithms won't even
> be mathematically meaningful. Also, in the cases where an algorithm
> can be constructed that will work for arbitrary properties of
> multiplication and addition, it is rare that such an algorithm will be
> as efficient as an algorithm that has been optimized for use with a
> particular algebra.
>
> A separate question is whether or not functions such as Expand could or
> should somehow be modified, probably by invoking separate algorithms,
> to handle operations in other algebras. That is an interesting
> question, and one that many people have considered.
>
> In current versions of Mathematica, however, the best way to do this
> sort of thing is to program it yourself using other functions. The
> approach you mentioned in
>
> > (Fortunately by using Distribute I was able to define my own Expand in
> > 2.2 which does not assume commutativity, so this problem no longer has
> > a practical significance for me, it's just a matter of wanting to
> > understand what happened).
>
> is one way to do that. There are quite a few other ways, and there are
> also several packages on MathSource that provide for operations over
> non-commuting algebras.
>
> Dave Withoff
> Wolfram Research
- References:
- Re: Non-commutative algebra
- From: Daniel Lichtblau <danl>
- Re: Non-commutative algebra