[Date Index]
[Thread Index]
[Author Index]
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
Prev by Date:
**ComplexExpand**
Next by Date:
**Re: Pattern Matching Bug ??**
Previous by thread:
**commutators?**
Next by thread:
**Re: Pattern Matching Bug ??**
| |