Prev: Persistent assumption
Next: Financial Data - Currencies
From: ADL on 31 Dec 2009 03:14 The reason is this: In[1]:= I // FullForm Out[1]//FullForm= Complex[0,1] In[2]:= 1 + I // FullForm Out[2]//FullForm= Complex[1,1] So, "I" is simply a way to write down quickly the expression Complex [0,1], while E and Pi directly represent the numbers E and Pi, without any intermediate transformation. Consequently, one should write: In[3]:= 1 - 2 I /. Complex[x_, y_] -> Complex[x, -y] Out[3]= 1+2*I As far as I understand, in Mathematica, the transformation rules for complex numbers should be always entered explicitly involving the whole complex plane Complex[x_,y_]. The difference between symbols representing real numbers (E, Pi, ...) and the complex I may be confusing: while this behavior is clearly stated ("Numbers containing I are converted to the type Complex.") and described in the section "Possible Issues", it is not explained immediately and the only way to reveal it is using FullForm. Perhaps, it should be reported in the "Basic examples". ADL On Dec 30, 10:17 am, AES <sieg...(a)stanford.edu> wrote: > The more I play with these I->-I substitution rules, the more seemingly > wildly inconsistent results emerge. For example: > > In[1]:= -I/.I->-I > > Out[1]= -I > > In[3]:= -E/.E->-E > > Out[3]= << The Esc e e Esc symbol >> > > In[4]:= -Pi/.Pi->-Pi > > Out[4]= \[Pi] > > In[5]:= -Infinity/.Infinity->-Infinity > > Out[5]= -\[Infinity] > > (In/Out[2] is removed because it was an irrelevant cell.)
From: Valeri Astanoff on 31 Dec 2009 03:14 On 30 d=E9c, 10:17, AES <sieg...(a)stanford.edu> wrote: > The more I play with these I->-I substitution rules, the more seemingly > wildly inconsistent results emerge. For example: > > In[1]:= -I/.I->-I > > Out[1]= -I > > In[3]:= -E/.E->-E > > Out[3]= << The Esc e e Esc symbol >> > > In[4]:= -Pi/.Pi->-Pi > > Out[4]= \[Pi] > > In[5]:= -Infinity/.Infinity->-Infinity > > Out[5]= -\[Infinity] > > (In/Out[2] is removed because it was an irrelevant cell.) Good day, Caveat substitutor ! That's not full craziness : what we see is *not* what we get because pattern recognition is not based on mathematical equivalence but on structure equivalence (given by FullForm). Imho, when applying a rule lhs -> rhs it's a risky practice to use the same symbol in 'lhs' and 'rhs', because, very often, there is no easy way to check what has been done. Anyway, for occasional users, you're right : it's crazy! -- Valeri Astanoff
From: dh on 31 Dec 2009 03:14 Hi, no magic here, the pattern matcher is working on the full form, not the displayed one. You can see the full form using: "FullForm". The full form of -I is: Complex[0,-1] and that of I: Complex[0,1]. This explains why I does not match -I. I do not see a problem with E and Pi. For Infinity the full form is:DirectedInfinity[1] and for -Infinity: DirectedInfinity[-1]. Daniel On 30 Dez., 10:17, AES <sieg...(a)stanford.edu> wrote: > The more I play with these I->-I substitution rules, the more seemingly > wildly inconsistent results emerge. For example: > > In[1]:= -I/.I->-I > > Out[1]= -I > > In[3]:= -E/.E->-E > > Out[3]= << The Esc e e Esc symbol >> > > In[4]:= -Pi/.Pi->-Pi > > Out[4]= \[Pi] > > In[5]:= -Infinity/.Infinity->-Infinity > > Out[5]= -\[Infinity] > > (In/Out[2] is removed because it was an irrelevant cell.)
From: Norbert P. on 31 Dec 2009 03:15 On Dec 30, 1:17 am, AES <sieg...(a)stanford.edu> wrote: > The more I play with these I->-I substitution rules, the more seemingly > wildly inconsistent results emerge. For example: > > In[1]:= -I/.I->-I > > Out[1]= -I > > In[3]:= -E/.E->-E > > Out[3]= << The Esc e e Esc symbol >> > > In[4]:= -Pi/.Pi->-Pi > > Out[4]= \[Pi] > > In[5]:= -Infinity/.Infinity->-Infinity > > Out[5]= -\[Infinity] > > (In/Out[2] is removed because it was an irrelevant cell.) It might seem inconsistent, but as you can read in tutorial/ PatternsForSomeCommonTypesOfExpression: "Especially for some common kinds of expressions, the standard output format used by Mathematica is not particularly close to the full internal form. But it is the internal form that you must use in setting up patterns. " So when you look at the expressions you give: In[1]:= FullForm/@{I,-I,E,-E,Pi,-Pi,Infinity,-Infinity} Out[1]= {Complex[0,1],Complex[0,-1],E,Times[-1,E],Pi,Times [-1,Pi],DirectedInfinity[1],DirectedInfinity[-1]} Hope that helps, Norbert
From: Leonid Shifrin on 31 Dec 2009 03:17
Since other instances of this issue has been just discussed extensively in a previous long thread, I will only add a slightly different viewpoint. Namely, what can be done to make the rules work. On Wed, Dec 30, 2009 at 12:15 PM, AES <siegman(a)stanford.edu> wrote: > The more I play with these I->-I substitution rules, the more seemingly > wildly inconsistent results emerge. For example: > > In[1]:= -I/.I->-I > > Out[1]= -I > Complex numbers (<I> included) have a pattern Complex[a,b]. The pattern you try assumes that - I is internally represented as -Complex[0,1], while it is in fact Complex[0,-1]. Now, <I> is a locked symbol (one of the very few) with special properties. In particular, from the following it is obvious that once the input <I> is processed, some evaluation takes place, since \[ImaginaryI] gets replaced by Complex[0,1]. In[41]:= FullForm[I] Out[41]//FullForm= Complex[0,1] In[44]:= Hold[I]//FullForm Out[44]//FullForm= Hold[\[ImaginaryI]] Your rule will work with a following (admittedly inconvenient) modification: In[23]:= With[{I = Complex[0, 1]}, Unevaluated[-I] /. I :> -I] Out[23]= I Alternatively you can use: In[39]:= Unevaluated[-I] /. HoldPattern[I] -> -I Out[39]= I In the latter case, we forbid <I> to evaluate in both the original expression and the pattern, and then it works. My point is that this is not a bug (in this particular case). Pattern-matching is based on syntax, not on semantics, so to use it correctly one should have a pretty good idea of the internal representation of participating expressions in Mathematica, as well as on possible evaluations that may take place. This is certainly not intuitive, but I think the cases you list represent exceptions rather than a rule, and are (for I and Infinity) related to a rather special nature of the objects represented by these symbols. > > In[3]:= -E/.E->-E > > Out[3]= << The Esc e e Esc symbol >> > This one works fine for me: In[6]:= -E/.E->-E Out[6]= E > > In[4]:= -Pi/.Pi->-Pi > > Out[4]= \[Pi] > This seems ok > > In[5]:= -Infinity/.Infinity->-Infinity > > Out[5]= -\[Infinity] > The same story here as for the case with <I>. Again, you can see the origin of this puzzle by looking at the FullForm before and after the evaluation: In[33]:= Hold[-Infinity]//FullForm Out[33]//FullForm= Hold[Times[-1,Infinity]] In[45]:= Infinity//FullForm Out[45]//FullForm= DirectedInfinity[1] You see that once we allow Infinity to evaluate, it becomes DirectedInfinity[1], while -Infinity becomes DirectedInfinity[-1]. And the possible solution which leads to "expected" pattern-matching: In[38]:= Unevaluated[-Infinity] /. HoldPattern[Infinity] -> -Infinity Out[38]= \[Infinity] I think that there are not many more objects in Mathematica which are as tricky as <I> or Infinity in terms of pattern-matching. I also think that this is the case where the overall consistency of design requires that the user gets (accidentally) exposed to some internals like above (because here the line between internals and exposed to the user interface becomes very blurred, given that a lot of Mathematica is written in Mathematica), which are not as simple or intuitive as the general Mathematica functionality intentionally exposed to the end user. It would perhaps be nice if such cases were more systematically documented, but they have nothing to do with bugs, as Daniel Lichtblau and many others already explained. Hope this helps. Regards, Leonid > > (In/Out[2] is removed because it was an irrelevant cell.) > > |