Re: Re: Non-commutative algebra
- To: mathgroup at smc.vnet.net
- Subject: [mg13358] Re: [mg13280] Re: Non-commutative algebra
- From: Andrzej Kozlowski <andrzej at tuins.ac.jp>
- Date: Mon, 20 Jul 1998 02:50:13 -0400
- Sender: owner-wri-mathgroup at wolfram.com
Since I started this topic I feel I should add that I have now tried the
existing NCAlgebra package (by J. William Helton and Mark Stankus)
availabe from MathSource and find that it does provide a lot of the
functionality one might wish to be built into Mathematica. In
particular, one can declare certain variables to be non-commutative and
others to be commutative, and there are a number of non-commutative
analogues of built in commutative functions. Unfortunately the
package is poorly documented (basically only through a dvi file and
some examples in the form of Post Script files). Moreover, the biggest
problem I have found is having to be very careful to avoid interacting
with the built in functions which assume commutativity. Often it is not
clear which functions must be avoided. This is likely to be a problem
with any implementation of non-commutative algebra through an external
package. The only convenient mechanism would seem to be the one
mentioned by David Withoff as a possible direction of future
development: that is, one would want built in functions either to
switch to non-commutative algorithms when applied to non-commutative
expressions or at least do nothing, rather than mess up everything, as
they tend to do now. Andrzej
At 12:55 PM -0500 7/17/98, MJE wrote:
>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
Andrzej Kozlowski
Toyama International University
Toyama, JAPAN
http://sigma.tuins.ac.jp/