Re: Pattern Matching Bug ??

*To*: mathgroup at yoda.physics.unc.edu*Subject*: Re: Pattern Matching Bug ??*From*: withoff*Date*: Fri, 19 Feb 93 11:03:37 CST

> I tried to replace expressions of the type > E^(I x) > with the more convenient (for me at least) > Cos[x] + I Sin[x] > using the rule > /. E^(I x_) -> Cos[x] + I Sin[x] > > This works fine until one has an expression like > E ^(-I x) > > In this case, the above replacement rule doesn't match anymore. I assume > this is due to the internal representation of I (which is Complex[0,1] for > I and Complex[0,-1] for -I). > I consider this behavior a bug. Any comments ? > > If you write -I > this is mathematically (-1) * I. So the pattern matching should replace I > appropriately as it does do for e.g. -x. > The situation is even a bit worse: > > Enter: > E^(I (-x)) // FullForm > and you get: > Power[E, Times[Complex[0, -1], x]] > > i.e. it pulls the -1 into the internal definition of I and makes I > therefore unacessible to pattern matching as soon as you have a (-1) > somewhere in your exponent. This happens before patterns are tested for: > E^(I (-x)) /. I->newI > gives you > E^(-I x) > but it works for other symbols just fine: > E^(y (-x)) /. y->newy > results in > E^-(newy x) > as expected. > > -I should be rather represented as Times[-1,Complex[0,1]] > internally as it is done for -x (Times[-1,x]). > > Markus Ruppel The following pattern will cover the cases you mentioned: In[1]:= Exp[-I x] /. {Exp[z_Complex x] -> Exp[x Re[z]] (Cos[x Im[z]] + I Sin[x Im[z]])} Out[1]= Cos[x] - I Sin[x] or you can use the function ComplexToTrig: In[2]:= << Algebra`Trigonometry` In[3]:= ComplexToTrig[Exp[-I x]] Out[3]= Cos[x] - I Sin[x] Regarding the issue of whether or not the way the pattern matcher handles complex numbers is a bug, I'd be the first (well, maybe the second) to admit it if something in Mathematica was a bug -- Mathematica has plenty of bugs -- but I'm not sure this is one of them. A complex number like 3+4*I is an atomic object, just like Pi or 17 or 2.85 or 5/11, and the fact that us human mathematicians choose to represent complex numbers using sums and products of their real and imaginary parts is fairly arbitrary. In this sense, the way complex numbers usually appear in print or on a computer screen is a distraction. It is sometimes convenient, for example, to represent integers as products of their prime factors. That is, we might want to write 126 as 2*3*3*7, and thefore expect 126 to match the pattern 3*x_ with x bound to 2*3*7. Similarly, we might want to consider complex numbers in polar form, so 3+4*I would match 5*x_ with x bound to Exp[I*Arctan[3,4]]. We could even make complex numbers print in polar form by default: In[31]:= Format[z_Complex] := Abs[z] Exp["I" Arg[z]] In[32]:= 3 + 4 I I ArcTan[3, 4] Out[32]= 5 E This does not, however, change the matching behavior suggested by the displayed form of the number: In[33]:= MatchQ[%, 5*x_] Out[33]= False Having the pattern I*z_ match the expression -I with z bound to -1 is conceptually the same as having I*z_ match the integer 2 with z bound to -2*I, or 3*z_ match the integer 12 with z bound to 4. This is an interesting feature, and I have occasionally wanted it myself, but I don't think the fact that it isn't there is a bug, and I'm not entirely sure it is either practical or desirable. The pattern matcher does support something like this in a very limited way (one special case) through the OneIdentity attribute. The pattern 3*x_., for example, will match the integer 3 with x bound to 1, since the pattern matcher effectly treats 3 in this case as 3*1: In[34]:= 3 /. {3*x_. -> {x}} Out[34]= {1} Dave Withoff Wolfram Research

**ComplexExpand**

**Re: Pattern Matching Bug ??**

**commutators?**

**Re: Pattern Matching Bug ??**