# More /.{I->-1} craziness

105 views

### AES

Dec 30, 2009, 4:17:55 AM12/30/09
to
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.)

### Bob Hanlon

Dec 31, 2009, 3:12:54 AM12/31/09
to

You appear to be comparing apples and oranges.

Head /@ {I, E, Pi, Infinity}

{Complex,Symbol,Symbol,DirectedInfinity}

FullForm /@ {I, E, Pi, Infinity}

{Complex[0,1],E,Pi,DirectedInfinity[1]}

Since rules are applied to the FullForm,,,

Bob Hanlon

---- AES <sie...@stanford.edu> wrote:

=============

### Alexander Elkins

Dec 31, 2009, 3:13:27 AM12/31/09
to
You'll get the same behavior for similar reasons if you try the following:

In[1]:= -1/2 /. 1/2 -> -1/2
Out[1]= -(1/2)

The reason is that what you see is not what is acted upon, for example:

In[2]:= FullForm[{1/-2,I,-I,1+I,1-I,1/-2+I/-3}]
Out[2]//FullForm=
List[Rational[-1,2],Complex[0,1],Complex[0,-1],Complex[1,1],Complex[1,-1],Co
mplex[Rational[-1,2],Rational[-1,3]]]

In other words -I is seen as Complex[0,-1] not -Complex[0,1], Complex[0,1]
does not match anything, so no replacement is performed leaving the input
unchanged. One way to change -I to -(-I) is as follows:

In[3]:= -I/.Complex[r_,i_]:>Complex[r,-i]
Out[3]= I

That also works in this more general case:

In[4]:= 1/-2+I/-3/.Complex[r_,i_]:>Complex[r,-i]
Out[4]= -(1/2)+I/3

Hope this helps...

"AES" <sie...@stanford.edu> wrote in message
news:hhf5s3\$h4o\$1...@smc.vnet.net...

### Richard Fateman

Dec 31, 2009, 3:13:38 AM12/31/09
to
AES 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
>
..snip..
>
These examples you give are perfectly consistent with a certain world
view which is that I is not a symbol, but a functional form,
Complex[0,1], and -I is a different form, Complex[0,-1].

The fact that this is not what you expect as a mathematician is simply

You might find these examples. some old, some new, confusing as well.
(in Mathematica 6.0)

Here are some puzzles for you. Guess what they return. (Answers below)
3 /. 3->4
3 /.3->4
3 /0.3->4 (which helps explain previous line)

3 / . 3 ->4

3 /. 3.0->4

3/.3.0->4
3.0/. 3.0->4

a. 3/. a->b
a.3 /. a->b

a .3 . 4 /. 3 -> c
a. 3 . 4 /. 3 -> c

3 /. 3->4 returns 4
3 /.3->4 returns 10.->4
3 /0.3->4 returns 10.->4 (which helps explain previous line)

3 / . 3 ->4 syntax error

3 /. 3.0->4 returns 3

3/.3.0->4 returns 0.->4
3.0/. 3.0->4 returns 4

a. 3/. a->b returns b.3
a.3 /. a->b returns 0.3*b

a .3 . 4 /. 3 -> c returns a 0.3.4
a. 3 . 4 /. 3 -> c returns a.c.4

and yes, I know the explanation for all of these.

Dec 31, 2009, 3:14:12 AM12/31/09
to
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".

### Valeri Astanoff

Dec 31, 2009, 3:14:45 AM12/31/09
to

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

### dh

Dec 31, 2009, 3:14:56 AM12/31/09
to
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

### Norbert P.

Dec 31, 2009, 3:15:53 AM12/31/09
to

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

### David Bailey

Dec 31, 2009, 3:16:16 AM12/31/09
to
I can't really see what point you are trying to make. One of the first
things you learn about replacement rules is that they operate
structurally, and the structure of -I (FullForm[-I]) is Complex[0,-1],
which clearly does not match FullForm[I], which is Complex[0,1] - end of
story!

Complex numbers are represented in this way internally for efficiency
for fairly obvious reasons when you consider the range of things you can
do with complex expressions.

Conjugate will give you a proper complex conjugate.

There is nothing special about I - there are lots of expressions that do
not transform as one might naively expect - again FullForm will reveal why:

1/Sqrt[x] /. Sqrt[x] -> Q

Exp[x] /. Exp -> Q

etc.

David Bailey
http://www.dbaileyconsultancy.co.uk

### Murray Eisenberg

Dec 31, 2009, 3:16:27 AM12/31/09
to
These "seemingly wildly inconsistent" results are explained, in large
part, by what has been posted in this thread earlier, and in particular
by from Daniel Lichtblau. Perhaps "at first surprising"
would be a much better description tan "seemingly wildly inconsistent".

Try these:

FullForm /@ {-I, -E, -Pi, -Infinity}
AtomQ /@ {-I, -E, -Pi, -Infinity}

To my mind, the only possible surprise here -- simply because I never
looked at it before, concerns -Infinity. But anything concerning
infinite quantities is bound to be so special that nothing about
handling of Infinity would really surprise me.

AES 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.)
>

--
Murray Eisenberg mur...@math.umass.edu
Mathematics & Statistics Dept.
Lederle Graduate Research Tower phone 413 549-1020 (H)
University of Massachusetts 413 545-2859 (W)
710 North Pleasant Street fax 413 545-1801
Amherst, MA 01003-9305

### Patrick Scheibe

Dec 31, 2009, 3:16:38 AM12/31/09
to
Hi,

just check the FullForm of the expressions and you'll see, that *none*
of the resulst are inconsistent.

Cheers
Patrick

### Leonid Shifrin

Dec 31, 2009, 3:17:44 AM12/31/09
to
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 <sie...@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]]

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

### Vince Virgilio

Dec 31, 2009, 3:19:23 AM12/31/09
to
On Dec 30, 4:17 am, AES <sieg...@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
>

I think 'I' compares better with simple real numbers than
transcendentals or infinities. I don't think you'd expect the
following to give 2 instead of -2.

In[52]:= -2 /. 2 -> -2

Out[52]= -2

But because of the constructive/structural nature of Mathematica, you
can make In[1] work as intended. Delay evaluation. Replace I before it
'goes atomic' (ref/AtomQ) as a Complex.

In[46]:= Hold[-I] /. HoldPattern@I -> -I

Out[46]= Hold[-(-1) I]

In[47]:= ReleaseHold@%

Out[47]= I

Or to change sign another way, again delay evaluation, where
necessary.

In[41]:= Hold[-I] /. -1 -> 1

Out[41]= Hold[1 I]

In[42]:= ReleaseHold@%

Out[42]= I

Nonetheless, this is hindsight. For the unititiated, I'd say I's
behavior doesn't follow the Principle of Least Surprise (doesn't
'please') [**]. Yet I don't think there's a silver bullet for this
problem. The only way I see to mitigate it is with continual
improvements to the documentation, prompted by users such as yourself.

Vince Virgilio

[*] Reminds me of C's Usual Arithmetic Conversions: http://tinyurl.com/y85j=
c2r
.

### DrMajorBob

Jan 1, 2010, 5:31:58 AM1/1/10
to
> But anything concerning
> infinite quantities is bound to be so special that nothing about
> handling of Infinity would really surprise me.

In short, if I may presume to paraphrase... you don't expect any rules to
apply. You'll determine the behavior of infinite quantities in each
setting you meet, independently.

I do the same thing myself, every time I write a Mathematica statement. I
neither trust the documentation, nor MY MEMORY of the documentation or
previous experience. It's common for me to push F1 on functions I've used
hundreds of times and try it again to see how it works, in case it changed
or I've missed something. If it doesn't do what documentation says or what
I remember, I count it as merely typical, and I try something else.

That approach is reliable, but sometimes tiring (in any language).

Bobby

On Thu, 31 Dec 2009 02:16:47 -0600, Murray Eisenberg
<mur...@math.umass.edu> wrote:

> These "seemingly wildly inconsistent" results are explained, in large
> part, by what has been posted in this thread earlier, and in particular
> by from Daniel Lichtblau. Perhaps "at first surprising"
> would be a much better description tan "seemingly wildly inconsistent".
>
> Try these:
>
> FullForm /@ {-I, -E, -Pi, -Infinity}
> AtomQ /@ {-I, -E, -Pi, -Infinity}
>
> To my mind, the only possible surprise here -- simply because I never
> looked at it before, concerns -Infinity. But anything concerning
> infinite quantities is bound to be so special that nothing about
> handling of Infinity would really surprise me.
>

> AES 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.)
>>
>

### Murray Eisenberg

Jan 1, 2010, 5:35:15 AM1/1/10
to
"What you see is not what is acted upon". That's a wonderful synopsis
of the situation! (Except that perhaps I would insert the word
"necessarily" before "what".)

I haven't searched the docs, but something like that needs to be stated,
explained, and exemplified some place, or places, in the Documentation
Center that is easily found.

Now that the printed "The Mathematica Book" is gone and replaced by a
non-linear web of documentation, finding where to expose such a
principle is unclear.

Alexander Elkins wrote:
>
> ... what you see is not what is acted upon, for example:

>
> In[2]:= FullForm[{1/-2,I,-I,1+I,1-I,1/-2+I/-3}]
> Out[2]//FullForm=
> List[Rational[-1,2],Complex[0,1],Complex[0,-1],Complex[1,1],Complex[1,-1],Co
> mplex[Rational[-1,2],Rational[-1,3]]]
>
> In other words -I is seen as Complex[0,-1] not -Complex[0,1], Complex[0,1]
> does not match anything, so no replacement is performed leaving the input
> unchanged.

--

### Murray Eisenberg

Jan 1, 2010, 5:35:26 AM1/1/10
to
OK, so what, in an earlier post today, I suggested needed to be said in
the docs is said there, although not in quite so direct a form ("What
you see is not what is acted upon", as stated by Alexander Elkins).

The issue, it seems, is how and when one finds such principles in the
docs. Presumably the Virtual Book that's part of the Documentation
Center would readily lead one to that tutorial. And it's there, to be
sure -- but not so easy to find:

Core Language > Patterns > Patterns for some Common Types of Expressions

Part of the difficulty in finding such things in the Documentation
Center may be the granularity of the documentation (as contrasted with
the now-defunct, printed "The Mathematica Book" -- if I may be permitted

Norbert P. wrote:
>
> ... 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. "

--

### Murray Eisenberg

Jan 1, 2010, 5:35:37 AM1/1/10
to
"One of the first things you learn...." Hmm... Where exactly in the
Documentation Center would one be expected to learn about replacement
rules -- and is that really one of the first things you learn there?

When I ask this, I try to place myself in the position of somebody who
has NOT come to Mathematica with a long experience of previous versions
and their associated documentation.

David Bailey wrote:
>
> .... One of the first

> things you learn about replacement rules is that they operate
> structurally, and the structure of -I (FullForm[-I]) is Complex[0,-1],
> which clearly does not match FullForm[I], which is Complex[0,1] - end of
> story!

--

### David Bailey

Jan 1, 2010, 5:36:20 AM1/1/10
to
Richard Fateman wrote:
> AES 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
>>
> ..snip..
> These examples you give are perfectly consistent with a certain world
> view which is that I is not a symbol, but a functional form,
> Complex[0,1], and -I is a different form, Complex[0,-1].
>
> The fact that this is not what you expect as a mathematician is simply

What you say is true, so I guess this is really a response to your smiley!

A comprehensive system like Mathematica clearly has to have operations
that are mathematically consistent, and others that operate at a
structural level. You could argue (I suppose) that the structural
operations (such as ReplaceAll) should be hidden away for Wolfram
programmers only, but in fact they are very useful, provided you use
them for the right purpose. Thus the expression:

Sin[x]+Cos[3 x] /. Sin[a_]->Cos[a]

makes no sense at all, but a very similar expression can make perfect
sense (if you know that abs(x) is suitably small):

Sin[x]+Cos[3 x] /. {Sin[a_]->a-a^3/6,Cos[a_]->1-a^2/2}

Mathematica would be quite inflexible if it only had 'valid' math
operations.

David Bailey
http://www.dbaileyconsultancy.co.uk

### DrMajorBob

Jan 1, 2010, 5:36:31 AM1/1/10
to
Of those examples, the one I find most amazing is

a .3.4/.3->c
FullForm@%

a 0.3.4
Times[a,Dot[0.3`,4]]

The result is bizarre, and it can't be entered at the keyboard.

Try entering 0.3.4 in an Input cell, and see what happens!

Bobby

On Thu, 31 Dec 2009 02:13:51 -0600, Richard Fateman
<fat...@cs.berkeley.edu> wrote:

> AES 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
>>

> ..snip..
>>
> These examples you give are perfectly consistent with a certain world
> view which is that I is not a symbol, but a functional form,
> Complex[0,1], and -I is a different form, Complex[0,-1].
>
> The fact that this is not what you expect as a mathematician is simply
>

### Richard Fateman

Jan 1, 2010, 5:39:00 AM1/1/10
to
Leonid Shifrin wrote:
...

>
> 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 agree.
That's why it can be fixed.

Here's a beginning of a short list for the "we're not just talking
syntactic replacement-- version of substitution":

If the user says -i --> i, then do Complex[a_,-b_] -> Complex[a,b].
If the user says x^2 --> y, then do x^(-2)-> 1/y also.

I assume this list can be enlarged somewhat, and could even be left
open-ended by user option of some sort. [e.g. should x^2--> y also
change x^3 to x*y? or to y^(3/2) or ....]

....

> It would perhaps be nice if such
> cases were more systematically documented, but they have nothing to do with
> bugs,

You are right if you mean "bug in Mathematica implementation of
intended design" (this is not such a bug).

But there is another concept:
"bug in Mathematica design, contrary to reasonable mathematical expectation"
(this IS such a bug).

### Noqsi

Jan 2, 2010, 5:04:15 AM1/2/10
to
On Jan 1, 3:39 am, Richard Fateman <fate...@cs.berkeley.edu> wrote:
> Leonid Shifrin wrote:
>
> ...
>
>
>
> > I think that there are not many more objects in Mathematica which are a=

s
> > tricky as <I> or Infinity in terms of pattern-matching.
>
> I agree.
> That's why it can be fixed.
>
> Here's a beginning of a short list for the "we're not just talking
> syntactic replacement-- version of substitution":
>
> If the user says -i --> i, then do Complex[a_,-b_] -> Complex[=

a,b].
> If the user says x^2 --> y, then do x^(-2)-> 1/y also.
>
> I assume this list can be enlarged somewhat, and could even be left
> open-ended by user option of some sort. [e.g. should x^2--> y also
> change x^3 to x*y? or to y^(3/2) or ....]

No! The language should not attempt to outsmart the user. What you're
proposing would be the nastiest sort of bug, changing simple,
predictable behavior into something that would play out in
incomprehensible ways. Syntactic replacement is very, very useful and
should not be polluted by attempts to read the user's mind.

The principle here has always been "You want to see what a rule will
really do? Look at FullForm." Perhaps the documentation should
highlight this better, but this behavior is NOT A BUG.

### Leonid Shifrin

Jan 2, 2010, 5:06:16 AM1/2/10
to
Regarding this issue, I think I entirely agree with what David Bailey and
other people said: I don't consider replacement rules as a mathematical tool
for end users, but rather as an inner layer of Mathematica, which is also
exposed for flexibility / convenience and intended primarily to be used by
the more advanced users. In this way, they can implement some missing
functionality themselves at their own risk without the need to wait for a
new Mathematica release. It is stated in the documentation that rule
substitution is purely syntax-based, and therefore not guaranteed to always
make sense.

I don't see how this by itself makes the design inconsistent: either you are
the end-user without advanced Mathematica skills and then you have to stick
to the built-in commands like Conjugate designed specifically to deal with
the problem (complex conjugation here), or you use the lower-level tools
like replacement rules but then you are on your own - the system will
blindly do the replacements according to the syntax of your rules, and it is
then your responsibility to use them correctly. What I would agree with is
that the documentation could have made this borderline more clear-cut. But I
don't think that this is a problem on the level of design.

Regards,
Leonid

On Fri, Jan 1, 2010 at 2:39 AM, Richard Fateman <fat...@cs.berkeley.edu>wrote:

> Leonid Shifrin wrote:
> ...
>
> >

> > 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 agree.
> That's why it can be fixed.
>
> Here's a beginning of a short list for the "we're not just talking
> syntactic replacement-- version of substitution":
>

> If the user says -i --> i, then do Complex[a_,-b_] -> Complex[a,b].

> If the user says x^2 --> y, then do x^(-2)-> 1/y also.
>
> I assume this list can be enlarged somewhat, and could even be left
> open-ended by user option of some sort. [e.g. should x^2--> y also
> change x^3 to x*y? or to y^(3/2) or ....]
>

> ....

>
> > It would perhaps be nice if such
> > cases were more systematically documented, but they have nothing to do
> with
> > bugs,
>

### Andrzej Kozlowski

Jan 2, 2010, 5:08:05 AM1/2/10
to

On 31 Dec 2009, at 17:18, Leonid Shifrin wrote:

> I think that there are not many more objects in Mathematica which are as
> tricky as <I> or Infinity in terms of pattern-matching.

Another obvious case that can be included is Rational, e.g.

Rational

Times

Times

AtomQ[2/3]

True

AtomQ[a/b]

False

Rational works essentially the same way as Complex.

It's perfectly consistent, fully justified, and certainly will never be changed.

Andrzej Kozlowski

### David Bailey

Jan 2, 2010, 5:08:49 AM1/2/10
to
Murray Eisenberg wrote:
> "One of the first things you learn...." Hmm... Where exactly in the
> Documentation Center would one be expected to learn about replacement
> rules -- and is that really one of the first things you learn there?
>
> When I ask this, I try to place myself in the position of somebody who
> has NOT come to Mathematica with a long experience of previous versions
> and their associated documentation.
>
> David Bailey wrote:
>> .... One of the first
>> things you learn about replacement rules is that they operate
>> structurally, and the structure of -I (FullForm[-I]) is Complex[0,-1],
>> which clearly does not match FullForm[I], which is Complex[0,1] - end of
>> story!
>
Murray,

I know what you mean - but AES is not exactly a Mathematica newbie! I
suppose what I meant to say, was that when I gave introductory
Mathematica courses, I covered the pitfalls of replacement rules on day one!

It seems to me that the documentation post-6.0 leaves a lot to be
desired, and with the constant tidal wave of new functionality arriving
in Mathematica, this is something that becomes ever more serious.

Incidentally, the main reason why I stopped giving courses and
concentrated on consultancy, was that I felt that nobody - certainly not
me - could really do justice to the functionality available.

David Bailey
http://www.dbaileyconsultancy.co.uk

### Vince Virgilio

Jan 3, 2010, 3:37:25 AM1/3/10
to
On Jan 2, 5:06 am, Leonid Shifrin <lsh...@gmail.com> wrote:
> Regarding this issue, I think I entirely agree with what David Bailey and
> other people said: I don't consider replacement rules as a mathematical tool
> for end users, but rather as an inner layer of Mathematica, which is also
> exposed for flexibility / convenience and intended primarily to be used by
> the more advanced users. [ . . . ]

SNIP

Leonid,

Replacement rules are as mathematical as 'Set' rules; to classify them
otherwise would mislead. The simple difference between the two types
of rules is that Replace is manual while Set is automatic. Both
provide the math concept of 'function', and both can apply to
structures that are non-mathematical. User discretion chooses between
them. 'More advanced users' likely will find more uses for manual rule
sets. On the other hand, they appear in Roman Maeder's introductory
books. (Was it "Introduction to Programming in Mathematica"?)

Vince Virgilio

### DrMajorBob

Jan 3, 2010, 3:37:57 AM1/3/10
to
I think the way we enter and understand InputForm is syntax; FullForm is
the way they're stored internally.

So Mathematica's pattern matching isn't what I'd call syntactical...
unless you mean "syntactical on a hidden (though discoverable) level".

Bobby

On Sat, 02 Jan 2010 04:06:32 -0600, Leonid Shifrin <lsh...@gmail.com>
wrote:

> Regarding this issue, I think I entirely agree with what David Bailey and
> other people said: I don't consider replacement rules as a mathematical
> tool
> for end users, but rather as an inner layer of Mathematica, which is also
> exposed for flexibility / convenience and intended primarily to be used
> by

>> > 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 agree.
>> That's why it can be fixed.
>>
>> Here's a beginning of a short list for the "we're not just talking
>> syntactic replacement-- version of substitution":
>>
>> If the user says -i --> i, then do Complex[a_,-b_] -> Complex[a,b].
>> If the user says x^2 --> y, then do x^(-2)-> 1/y also.
>>
>> I assume this list can be enlarged somewhat, and could even be left
>> open-ended by user option of some sort. [e.g. should x^2--> y also
>> change x^3 to x*y? or to y^(3/2) or ....]
>>
>> ....
>>

>> > It would perhaps be nice if such
>> > cases were more systematically documented, but they have nothing to do
>> with
>> > bugs,
>>

>> You are right if you mean "bug in Mathematica implementation of
>> intended design" (this is not such a bug).
>>
>> But there is another concept:
>> "bug in Mathematica design, contrary to reasonable mathematical
>> expectation"
>> (this IS such a bug).
>>
>>
>

### Leonid Shifrin

Jan 3, 2010, 3:38:43 AM1/3/10
to
On Sat, Jan 2, 2010 at 2:51 PM, DrMajorBob <btr...@austin.rr.com> wrote:

> I think the way we enter and understand InputForm is syntax; FullForm is
> the way they're stored internally.
>
> So Mathematica's pattern matching isn't what I'd call syntactical... unless
> you mean "syntactical on a hidden (though discoverable) level".
>

Yes Bobby,

That's exactly what I mean. When I talk about syntax, I mean FullForm, not
InputForm. Perhaps a more precise way of saying it would be to say that
pattern-matching is based on exact symbolic form (or structure) of the
expression (tree), without any "meaning" attached to any of its parts - this
is what I mean by syntax-based.

Regards,
Leonid

>>> > 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 agree.
>>> That's why it can be fixed.
>>>
>>> Here's a beginning of a short list for the "we're not just talking
>>> syntactic replacement-- version of substitution":
>>>
>>> If the user says -i --> i, then do Complex[a_,-b_] -> Complex[a,b].
>>> If the user says x^2 --> y, then do x^(-2)-> 1/y also.
>>>
>>> I assume this list can be enlarged somewhat, and could even be left
>>> open-ended by user option of some sort. [e.g. should x^2--> y also
>>> change x^3 to x*y? or to y^(3/2) or ....]
>>>
>>> ....
>>>

>>> > It would perhaps be nice if such
>>> > cases were more systematically documented, but they have nothing to do
>>> with
>>> > bugs,
>>>

### Leonid Shifrin

Jan 3, 2010, 3:38:32 AM1/3/10
to
Hi Richard,

Below I describe rather extensively my view on the issues you raised. Just
to make myself clear, it is not my intention to get involved in an endless
debate on these topics. I try to adhere to DRY (don't repeat yourself)
principle whenever I feel appropriate, so I detail my view on these subjects
below with the intention to do it only once. But I will certainly appreciate

On Sat, Jan 2, 2010 at 9:06 AM, R Fateman <fat...@cs.berkeley.edu> wrote:

> Leonid Shifrin wrote:
>
>> Regarding this issue, I think I entirely agree with what David Bailey and
>> other people said: I don't consider replacement rules as a mathematical tool
>> for end users, but rather as an inner layer of Mathematica, which is also
>> exposed for flexibility / convenience and intended primarily to be used by
>>
>

> Unfortunately many users or potential users are not as sophisticated in
> their understanding of the distinction between the underlying mechanisms of
> a syntax-driven
> transformation system. They simply take the marketing blurbs about "A
> system for doing mathematics" as a description suggesting that --hey, I do
> mathematics too. They don't really know what "syntax" means and they don't
> think they need to know, because syntax is not part of their mathematics
> education.
>

Well, if these people don't understand the importance of syntax for doing
any formal sicence, regardless of whether it is done by a human or a
computer, and somehow believe that some software is able to completely
automate this problem away without any further efforts on their side - too
bad for them and their current and future employers. Every tool used blindly
will eventually produce nonsense. Mathematica is a research tool. I view it
as a tool for explorations, tests, verifications and sometimes discoveries,
but not a substitute for domain knowledge, intuition, right questions to ask
and anticipation for possible correct answers.

I have a fair amount of research experience in Physics (mathematical and
theoretical), and while I was frustrated with Mathematica at times, it has
been overall incredibly helpful for the problems I have been working on. And
the reason that I was sure about the correctness of my results was that I
was doing many non-trivial checks such as alternative derivations, numerics
vs. analytical results, limiting cases, asymptotics, etc - this in the
first place, and my proficiency in Mathematica in the second. Also, I
probably have more diverse programming background than most professional
mathematicians and physicists - this is what I did (along with math) as a
kid before I started doing Physics, and this is what I do now for a living
after having quit Physics (I have some asm, Pascal, Fortran, C++ and a
substantial C experience and work currently as an enterprise Java / web
developer). So, hopefully I have both perspectives on Mathematica.

What I think is that your dissatisfaction with Mathematica is a result of
the clash of cultures. From a programmer / computer scientist viewpoint,
Mathematica probably has lots of what can look as "undefined behavior" or at
least as a violation of the principle of minimal surprise. But research in
(pure) science is done differently. Most physicists and mathematicians I
know are basic Mathematica users but are generally quite satisfied with
Mathematica. They don't care as much about what Mathematica does incorrectly
(no decent journal will accept Mathematica or any other CAS-based derivation
as a central part of any proof anyway - but this is not to say that they
are not annoyed by real bugs), as they care about what they *can* do with
Mathematica in principle. They may have some wrong beliefs, like believing
that Mathematica can not do lots of things it actually can do, or that it is
always dog slow with numerics, but they seldom run into problems of the kind
you often mention, simply because they by far don't have your level of
sophistication with Mathematica - so they have no way to come up with such
problems.

And I would argue that this kind of advanced Mathematica skills is more
characteristic of people working either in Computer Science or in the more
applied fields where some math is necessary, such as engineering or finance,
for instance (this is IMO because the research problems in pure science are
usually more unique and to a much lesser degree amenable to automation, thus
programming skills are not as relevant). I can also speak for myself: most
of the time, when I am using some advanced Mathematica (programming)
constructs, it is a programmer in me, not a scientist, who is the driving
force for it.

As far as I can tell, most software systems and programs exist to automate
(part of the) work which must otherwise be done by a human. The degree of
automation can be very different, but I have a feeling that for software
used in industry it is generally much higher (or at least that's the goal)
than for that used in research (I don't mean the software that say controlls
a particle accelerator etc - this I consider "industrial", even if used for
scientific purposes). In particular, many industrial software systems are
authorized to make lots of high - level decisions by themselves, with humans
often becoming operators who monitor the system's work and intervene only
in special circumstances. But for research software, I have a feeling that,
while automation is of course important, still most of high-level decisions
are left for a human - simply because it is much harder to automate
research, due to its very nature and requirement to be original. So I think
that it is inappropriate to subject Mathematica to requirements typical for
non-research software - hopefully it will never be intended to replace the
person who is using it, and will always remain a tool.

Arguably, a skilled mathematician or physicist has her own ways of checking
the correctness of the result. Mathematica is always a tool, not a magic box
that is guaranteed to always produce the right answer (given that lots of
times in research there are ambiguities in the questions asked). If one has
no means to ensure that the answer is correct, this means that he has at
most a single perspective of the problem he is solving. But if so, this
means that he does not really understand it, and this has nothing to do with
Mathematica.

>
> Now a person educated as a computer scientist would generally know a fair
> amount about syntax, and might be willing to use
> "A system that uses syntax-directed transformation rules for computation".
> In fact there are several such systems that have been
> designed, starting in the early 1960s. In deference to Steve C's
> reluctance to allow the names of other computer systems to appear
> in mathgroup, I won't name them. But at least 6 come to my mind.
> I still don't understand the reluctance of people to say "OK,
> mathematician-who-doesn't-know syntax" ... HERE's the substitution facility
> for YOU.
> and write the program. Or at least a first cut of one, so that it can be
> refined.

Unfortunately, I don't have comparable experiences with other CAS, so I
can't say anything useful here. One thing that I find remarkable about
Mathematica is the level of integration of different parts and the fact that
it still remains relatively simple system at its core, given the amount of
built-in functionality included in the kernel.

>
>
> In this way, they can implement some missing functionality themselves at
> their own risk without the need to wait for a new Mathematica release. It is
> stated in the documentation that rule substitution is purely syntax-based,
> and therefore not guaranteed to always make sense.
>

> It says that it won't always make sense? Hm. (I am traveling and don't
> have Mathematica with me, and can't check...) Doesn't make sense?!
> How could that be..

The last part is my interpretation. But the problems of using the correct
syntax and its correct interpretation exist in any formal science. In my
view, the syntax of Mathematica language is not really isomorphic to the
language of any specific domain of Mathematics, and should not be. It is
currently a number of very high-level commands targeted to occasional users
and performing well-defined standard mathematical operations, such as
solving equations or inequalities of some kind, etc. But IMO more
importantly in the long term, it is also a language - a building material,
optimized for creation of sub-languages for (mathematical) knowledge
representation and manipulations with mathematical objects. It is then
targeted at advanced users / progammers with both domain knowledge and
Mathematica skills who can correctly implement these sub-languages, adding
to the functionality available to the first target audience.

I would agree that there is currently a gap in between these two target
audiences, which would include for example some mathematicians without
advanced Mathematica skills who want to use Mathematica for their research,
and be able to push it to the limits. But I still don't think of this as a
design flaw. At the moment, this may be inconvenient, but evolutionary I
think this is a win - the system's generality makes it flexible enough to
evolve and smoothly integrate new functionality. The same generality is also
responsible for the occasional nonsense produced by a blind application of
replacement rules. But I think that in time, the corresponding "intermediate
layer" of Mathematica will emerge with enough functionality to allow these
people do their work without immersing themselves in complexities of
Mathematica's inner workings, and that will close the gap (already now, lots
of extra functionality is available through add-on packages). As David Park
said recently, we are still the early users.

> It must make sense to SOME people. Maybe even me or you. So now there are
> more levels.
> The high-priest, keeper of the mysterium(us?). The second level priest who
> understands syntax but for whom some transformations "don't make sense",a
> person who not a true syntax-geek. Perhaps this is the typical programmer
> who learns some Mathematica....
> The third level, maybe a skilled mathematician? The fourth level, some
> novice, unsophisticated student learning math; and maybe down the ladder
> further ?
>

I stick to my view of replacement rules as being aimed primarily at advanced
users, or at least as a tool that should be used with much care. I wish the
documentation was more clear about it. The fact that the functional and
procedural layers are built on top of the rule-based engine speaks for
itself - these layers are more managable by non-experts and less error-prone
to use (apart from efficiency gains). When beginners get excited by
replacement rules and start using them left and right, this very often leads
to trouble (I recall myself some while ago :)). Imagine for example a web
framework written say in Lisp, with some high-level API (or DSL) exposed to
basic users. Say, the inner workings of the framework are documented for the
benefits of the more advanced users. Imagine then that a basic user of the
framework learns a few basic things about Lisp and starts to use Lisp to do
what the API or DSL is supposed to be used for, trying to combine his own
Lisp functions with the calls to the API. I suppose you wouldn't be
surprised if our hypothetical user would frequently end up with something
different from what he intended.

Also, I agree with David Park here. When we learn math at school, we spend
several years to learn the subtleties of essentially a very similar
activity: when we do math, a lot of "pattern-matching" is happening in our
head when we decide which identities or equations to use. I have no reason
to think that the syntax of Mathematica *core* language must be designed to
be extremely easy to learn, given the level of generality required for it.
Besides, the core language is actually not so difficult to learn either. I
think that part of the problem is that most Mathematica introductions are
too pragmatic in a sense - they want to get you up to speed in solving field
- specific problems as quickly as possible and as a result omit a proper
discussion of the fundamental language structures (I tried to do it
differently in my book). Even worse, field-specific elements are often mixed
with parts of Mathematica language, which I find very confusing.

Pragmatically and in the short run, this seems to be a right thing to do
given that most (potential) Mathematica users at present are not high-school
students but professionals with no spare time to properly learn Mathematica
(perhaps, this will change). But for would-be long-term Mathematica users,
learning Mathematica this way is learning it the hard way.

Best regards and happy 2010,
Leonid

### David Bailey

Jan 3, 2010, 3:39:47 AM1/3/10
to
Would you really want to use a system which had been arbitrarily hacked
by well meaning individuals to create exceptions that suited their taste?

Perhaps the documentation should make it clearer which operations are
supposed to always perform mathematically valid operations, and which
are meant to operate on the structure of expressions, oblivious to their
meaning. I think this is an important distinction. If you pass an
expression to Integrate (say), you expect to get the integral of that
expression back as a result (possibly in symbolic form still involving
an integral sign) - anything else is a bug. However, other operations -
such as ReplaceAll - are not *defined* mathematically, they are defined
structurally, and as I pointed out earlier, can be used to produce
explicitly invalid expression transformations.

Are you really saying that Mathematica doesn't need structural
operations? If it does, why pick on ReplaceAll?

David Bailey
http://www.dbaileyconsultancy.co.uk

### R Fateman

Jan 3, 2010, 3:40:09 AM1/3/10
to
Leonid Shifrin wrote:
> Regarding this issue, I think I entirely agree with what David Bailey
> and other people said: I don't consider replacement rules as a
> mathematical tool for end users, but rather as an inner layer of
> Mathematica, which is also exposed for flexibility / convenience and
> intended primarily to be used by the more advanced users.

Unfortunately many users or potential users are not as sophisticated in
their understanding of the distinction between the underlying mechanisms
of a syntax-driven
transformation system. They simply take the marketing blurbs about "A
system for doing mathematics" as a description suggesting that --hey, I
do mathematics too. They don't really know what "syntax" means and they
don't think they need to know, because syntax is not part of their
mathematics education.

Now a person educated as a computer scientist would generally know a

fair amount about syntax, and might be willing to use
"A system that uses syntax-directed transformation rules for
computation". In fact there are several such systems that have been
designed, starting in the early 1960s. In deference to Steve C's
reluctance to allow the names of other computer systems to appear
in mathgroup, I won't name them. But at least 6 come to my mind.

I still don't understand the reluctance of people to say "OK,
mathematician-who-doesn't-know syntax" ... HERE's the substitution
facility for YOU.
and write the program. Or at least a first cut of one, so that it can
be refined.

In this way, they can implement some missing functionality themselves at

their own risk without the need to wait for a new Mathematica release.
It is stated in the documentation that rule substitution is purely
syntax-based, and therefore not guaranteed to always make sense.

It says that it won't always make sense? Hm. (I am traveling and don't
have Mathematica with me, and can't check...) Doesn't make sense?!

How could that be.. It must make sense to SOME people. Maybe even me or

you. So now there are more levels.
The high-priest, keeper of the mysterium(us?). The second level priest
who understands syntax but for whom some transformations "don't make
sense",a person who not a true syntax-geek. Perhaps this is the typical
programmer who learns some Mathematica....
The third level, maybe a skilled mathematician? The fourth level, some
novice, unsophisticated student learning math; and maybe down the

RJF

### Murray Eisenberg

Jan 3, 2010, 3:40:20 AM1/3/10
to
David,

Wow: you covered quite a bit that first day!

Happy New Year,
Murray

David Bailey wrote:
>
> ... when I gave introductory

> Mathematica courses, I covered the pitfalls of replacement rules on day one!

--

### Andrzej Kozlowski

Jan 4, 2010, 5:59:16 AM1/4/10
to

On 3 Jan 2010, at 17:41, Leonid Shifrin wrote:

> Hi Richard,
>
> Below I describe rather extensively my view on the issues you raised. J=
ust
> to make myself clear, it is not my intention to get involved in an endles=

s
> debate on these topics. I try to adhere to DRY (don't repeat yourself)

> principle whenever I feel appropriate, so I detail my view on these subje=
cts
> below with the intention to do it only once. But I will certainly appreci=
ate
>
> On Sat, Jan 2, 2010 at 9:06 AM, R Fateman <fat...@cs.berkeley.edu> wrote=
:
>
>> Leonid Shifrin wrote:
>>
>>> Regarding this issue, I think I entirely agree with what David Bailey a=
nd
>>> other people said: I don't consider replacement rules as a mathematical=
tool
>>> for end users, but rather as an inner layer of Mathematica, which is al=
so
>>> exposed for flexibility / convenience and intended primarily to be used=

by
>>>
>>
>> Unfortunately many users or potential users are not as sophisticated in

>> their understanding of the distinction between the underlying mechanisms=

of
>> a syntax-driven
>> transformation system. They simply take the marketing blurbs about "A

>> system for doing mathematics" as a description suggesting that --hey, I=
do
>> mathematics too. They don't really know what "syntax" means and they do=

n't
>> think they need to know, because syntax is not part of their mathematics
>> education.
>>
>

> Well, if these people don't understand the importance of syntax for doing
> any formal sicence, regardless of whether it is done by a human or a
> computer, and somehow believe that some software is able to completely

> automate this problem away without any further efforts on their side - =
too
> bad for them and their current and future employers. Every tool used blin=
dly
> will eventually produce nonsense. Mathematica is a research tool. I view =
it
> as a tool for explorations, tests, verifications and sometimes discoverie=
s,
> but not a substitute for domain knowledge, intuition, right questions to =

> and anticipation for possible correct answers.

I would add this: if someone does not know what syntax is he should take some time off and read almost any introductory on mathematical logic. Need not be written by anyone who has anything to do with computer science and can be in fact pretty old.
The first example form my shelf: Yuri Manin "Lecture on Mathematical Logic" vol 1., Chapter I, Section 2, Language of propositions: alphabet, syntax and interpretation. (1974, in Russian but there is no shortage of equivalent English texts).

### Andrzej Kozlowski

Jan 4, 2010, 5:59:28 AM1/4/10
to

I think certain special cases of Set rules and replacement rules are "mathematical". Certainly in mathematics you often evaluate functions and expressions, and this can be done in Mathematica by defining a functions as

f[x_]:=expr

and then evaluating f[a]. That's just an evaluation and something that mathematicians of course do all the time. The local version of this is, of course,
expr/.x->a
and that's essentially the same thing. But what is not in general "mathematical" is

f[some_pattern] := expr

or

expr/.some_pattern -> something

This kind of thing is rare in mathematics, and in fact, except for the
already discussed "function" case, I can't think of any "mathematical"
example. What is very common in mathematics is the sort of thing that
PolynomialReduce is for, which looks like "semantic substitution" but is
actually replacing a given expression by simpler one which is equivalent
to it by some equivalence relation. I think its not a great exaggeration
to say that most of applied mathematics consists of evaluation and most
of pure mathematics of studying the effect of various equivalence
relations on certain expressions. Neither has much in common with
general syntactic substitution.

Andrzej Kozlowski

### Leonid Shifrin

Jan 4, 2010, 6:00:36 AM1/4/10
to
Hi Vince,

> Replacement rules are as mathematical as 'Set' rules; to classify them
> otherwise would mislead. The simple difference between the two types
> of rules is that Replace is manual while Set is automatic. Both
> provide the math concept of 'function', and both can apply to
> structures that are non-mathematical. User discretion chooses between
> them.

>From the formal viewpoint, I must agree. But my impression is that 'Set'
rules and local rules with Replace are usually used in different
circumstances. The most common use case for 'Set' rules is arguably when a
user defines and "calls" her own function(s), since the rule substitution is
used in Mathematica to emulate the semantics of function calls. Most of
occasional users are routinely doing that using the simplest patterns like
_, and having no idea that they are using rules. And as long as their
arguments' patterns are not much more complicated, this will work fine.

Using local rules requires more sophistication, since the cases where you
might want to do that rather than define a function through 'Set' will most
likely require more complex patterns for which the transformation you want
to perform will only make sense in a specific context. Or may be you want
for some reason to avoid the full evaluation procedure. Perhaps there are
other reasons as well, but all of them seem to be aimed at doing something
that can not be easily done by taking a number of built-in functions and
just using them together - that's why I think it requires a deeper
familiarity with Mathematica. The problem is that it is much easier to look
up the Help and write a complex pattern / replacement rule, than to learn to
consistently do that correctly. With the calls to functions ('Set' rules),
things seem to be more straightforward.

> 'More advanced users' likely will find more uses for manual rule
> sets. On the other hand, they appear in Roman Maeder's introductory
> books. (Was it "Introduction to Programming in Mathematica"?)
>

Perhaps a person who can read Maeder's book and fully understand it should
no longer be afraid of using rules. But it's not an easy read - you have to
read between the lines. I have lost count of the number of times I re-read
some parts of it, and almost every time I found things that escaped me
previously (may be the reason is just me being stupid - I don't know).
Perhaps "Zen of Mathematica programming" would be a better title for it. I
think that the word "Introduction" in the title is somewhat misleading
(although it is certainly an introduction - Zen again. I am a big fan of all
his books, by the way).

Regards,
Leonid

### David Bailey

Jan 4, 2010, 6:02:53 AM1/4/10
to
Murray Eisenberg wrote:
> David,
>
> Wow: you covered quite a bit that first day!
>
> Happy New Year,
> Murray
>
> David Bailey wrote:
>> ... when I gave introductory
>> Mathematica courses, I covered the pitfalls of replacement rules on day one!
>
Well I like ReplaceAll to substitute variables in expressions, rather
than starting with assignments like

x=42

People invariably forget they have made top-level assigments to
variables like that, and get into difficulties a few minutes later. Of
course, that led into a discussion of what you could and couldn't do
with ReplaceAll.

If you start them with assignments, many students do everything with them!

David Bailey
http://www.dbaileyconsultancy.co.uk

### Fred Klingener

Jan 4, 2010, 6:01:54 AM1/4/10
to
On Jan 3, 3:37 am, DrMajorBob <btre...@austin.rr.com> wrote:
> I think the way we enter and understand InputForm is syntax; FullForm is
> the way they're stored internally.
>
> So Mathematica's pattern matching isn't what I'd call syntactical...
> unless you mean "syntactical on a hidden (though discoverable) level".
>
> Bobby
...

I studied the doc center entries for a few things like Replace,
ReplaceAll, etc. as well as tutorial/ApplyingTransformationRules, and
I was unable to find a single entry that might give what we're calling
an "unsophisticated user" a hint that the lhs to be acted on is
anything other than that displayed on the notebook screen.

I wouldn't describe myself as "unsophisticated," but my expectations
are conditioned and contaminated by almost 50 years of technical
computing. As a result, I've been a slow learner of the grand
structure of Mathematica, and I've spent my share of time astonished
by the way Mathematica works and confused by the lack of rewards to be
gained by RTFM.

A mention in the docs of replacement happening on Bobby's "syntactical
on a hidden (though discoverable) level" would be sufficiently
frightening to drive some users back to the hand calculator, but
further mention that that hidden level can be discovered even by an
"unsophisticated user" as the output of //FullForm would be like
sharing the secret handshake.

First line in tutorial/Applying TransformationRules:

expr/.lhs->rhs apply a transformation rule to FullForm[expr]

unless you don't want to share the secret handshake.

Cheers,
Fred

### Vince Virgilio

Jan 5, 2010, 1:42:42 AM1/5/10
to
Fred,

On Jan 4, 6:01 am, Fred Klingener <gigabitbuc...@BrockEng.com> wrote:

SNIP

> further mention that that hidden level can be discovered even by an
> "unsophisticated user" as the output of //FullForm would be like
> sharing the secret handshake.
>
> First line in tutorial/Applying TransformationRules:
>
> expr/.lhs->rhs apply a transformation rule to FullForm[expr]

SNIP

True.

However, for what it's worth, FullForm appears straightforwardly in
the Doc Center:

In Doc Center . . .
First section is "Core Language"
First bullet is "Language Overview"
First documented command is "FullForm"

Then a one-liner for ReplaceAll occurs a few lines down. Yes, as you
say, the one-liner needs an edit.

I think this doc structure qualifies Mathematica as sufficiently
"discoverable" [*].

Vince Virgilio

[*] I.e. 3rd bullet, second section, at:
http://accu.org/index.php/journals/1572

### Richard Fateman

Jan 5, 2010, 1:43:28 AM1/5/10
to

Are you describing Mathematica here? It seems to me that it is an

>
> Perhaps the documentation should make it clearer which operations are
> supposed to always perform mathematically valid operations, and which
> are meant to operate on the structure of expressions, oblivious to their
> meaning.

You assume that people read the documentation. This is provably false.

I think this is an important distinction. If you pass an
> expression to Integrate (say), you expect to get the integral of that
> expression back as a result (possibly in symbolic form still involving
> an integral sign) - anything else is a bug.

Or an error message like "division by zero" or "out of memory".

However, other operations -
> such as ReplaceAll - are not *defined* mathematically, they are defined
> structurally, and as I pointed out earlier, can be used to produce
> explicitly invalid expression transformations.
>

This is obviously not the view of the person who initially posted this
question.

> Are you really saying that Mathematica doesn't need structural
> operations?

No.
Just that people want other kinds of operations for substitution. This
should be obvious from the subject line, I -> -I etc.

If it does, why pick on ReplaceAll?

Because this is enshrined in the syntax of the user language, and
APPEARS (falsely, as it turns out) to be a mathematical operation.
RJF

### Richard Fateman

Jan 5, 2010, 1:43:39 AM1/5/10
to
Does it bear repeating?

In f[x_]:= ... the x_ is a pattern.

The reality in Mathematica programming is that this is NOT a function
definition, but a replacement rule. Contrary to Andrzej's opinion,
this is not "mathematical" but is made up of exactly the same stuff as
Rules, with pattern matching and replacement.

It is a useful shorthand illusion that you are defining a function.
But it is an illusion. Wolfram, in his earlier SMP, called these
Projections, but I guess that was just to confusing.

Here's a pattern-driven rule that describes how to replace f[something]:
f[x_]:=x+1

In contrast,
Mathematica DOES have functions. To define the (I think appx. same)
function as f above, you can do this:

f=#1+1&

and for people who wonder what this is, you can try it out and/or read
the manual.

And as for when/if these are exactly the same, I think there would have
to be some examination of the role of free and bound variables, the
effect of "return" and other issues that, by and large, also cause
confusion in the Mathematica context, since some ideas borrowed from
well-understood programming concepts were not quite understood by the
initial implementors of Mathematica. I don't know if they have been
patched correctly in the current system.

RJF

Andrzej Kozlowski wrote:
> On 3 Jan 2010, at 17:40, Vince Virgilio wrote:

>.....

I think its not a great exaggeration
> to say that most of applied mathematics consists of evaluation and most
> of pure mathematics of studying the effect of various equivalence
> relations on certain expressions. Neither has much in common with
> general syntactic substitution.

If you believe this then it seems that syntactic substitution would
really be a weak tool in so much of applied mathematics, and you should
be seeking a better tool.

RJF

### David Bailey

Jan 5, 2010, 1:47:23 AM1/5/10
to
If you can, get hold of one of those brick-like Mathematica books -
preferably version 5. The organisation of the book helps quite a bit -
there is a flow to it that you never find with the help system, plus you
can put book markers in it, etc. Failing that, you could print off the
virtual book. Graphics has changed a bit since version 5, but almost all
of the underlying concepts are unchanged.

Flow is important. For example, I encountered someone who wanted to
execute a program contained in more than one notebook. If he had read
through the book, roughly in order, he would almost certainly have
realised that the two notebooks would typically use the same kernel.
However, because he had not mastered the frontend/kernel concept, he
browsed the help system until he came across SelectionMove and
SelectionEvaluate.... The end result was not pretty!

David Bailey
http://www.dbaileyconsultancy.co.uk

### E. Martin-Serrano

Jan 5, 2010, 1:48:43 AM1/5/10
to
Hi,

It is well known that there are many books about syntax (and semantics) and
programming languages available in English. (of course, most of you know
that). But, for others interested in the subject, the following are good
sources to find any reference.

Lambda Calculus: http://en.wikipedia.org/wiki/Lambda_calculus (Close to the
Mathematica underlaying form.)

BNF grammars : http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form (The
simplest form; only context-free syntax)

Affix-grammars: http://en.wikipedia.org/wiki/Affix_grammar (Augmented BNF to
include context sensitive syntax and semantics)

Two-Level grammars: http://en.wikipedia.org/wiki/Two-level_grammar
(Meta-grammars and hyper-grammars togheter o more sophisticated form of
Affix Grammrs used to describe Algol 68)

Petri nets: http://en.wikipedia.org/wiki/Petri_net (enriched finite state
machine grammars to include devices to trigger state transitions)

Phrase structured grammars: http://en.wikipedia.org/wiki/Chomsky_hierarchy
(seminal work in the field)

And many others.

E. Martin-Serrano

-----Original Message-----
From: Andrzej Kozlowski [mailto:ak...@mimuw.edu.pl]
Sent: Monday, January 04, 2010 11:58 AM
Subject: Re: Re: More /.{I->-1} craziness

On 3 Jan 2010, at 17:41, Leonid Shifrin wrote:

> Hi Richard,
>
> Below I describe rather extensively my view on the issues you raised. J=
ust
> to make myself clear, it is not my intention to get involved in an endles=
s
> debate on these topics. I try to adhere to DRY (don't repeat yourself)
> principle whenever I feel appropriate, so I detail my view on these subje=
cts
> below with the intention to do it only once. But I will certainly appreci=
ate
>
> On Sat, Jan 2, 2010 at 9:06 AM, R Fateman <fat...@cs.berkeley.edu> wrote=
:
>

>> Leonid Shifrin wrote:
>>
>>> Regarding this issue, I think I entirely agree with what David Bailey a=
nd
>>> other people said: I don't consider replacement rules as a mathematical=
tool
>>> for end users, but rather as an inner layer of Mathematica, which is al=
so
>>> exposed for flexibility / convenience and intended primarily to be used=

by
>>>
>>

### Vince Virgilio

Jan 6, 2010, 5:56:45 AM1/6/10
to
On Jan 5, 1:43 am, Richard Fateman <fate...@cs.berkeley.edu> wrote:

SNIP

> Are you describing Mathematica here? It seems to me that it is an

SNIP

Please explain why that is an exception.

'a' and 'b' can be anything, not necessarily numbers. Hence a + b*I
can be anything as well (say, notebookA + notebookB * I). Not so for
3, 4, and 3 + 4*I.

Vince Virgilio

### DrMajorBob

Jan 6, 2010, 5:58:28 AM1/6/10
to
Unlike "The Mathematica Book", we don't read "Doc Center" in order, or
even, really, notice that there IS an order.

Bobby

On Tue, 05 Jan 2010 00:43:00 -0600, Vince Virgilio <blue...@gmail.com>
wrote:

> Fred,
>
>
> On Jan 4, 6:01 am, Fred Klingener <gigabitbuc...@BrockEng.com> wrote:
>
> SNIP
>

>> further mention that that hidden level can be discovered even by an
>> "unsophisticated user" as the output of //FullForm would be like
>> sharing the secret handshake.
>>
>> First line in tutorial/Applying TransformationRules:
>>
>> expr/.lhs->rhs apply a transformation rule to FullForm[expr]
>

> SNIP
>
> True.
>
> However, for what it's worth, FullForm appears straightforwardly in
> the Doc Center:
>
> In Doc Center . . .
> First section is "Core Language"
> First bullet is "Language Overview"
> First link is "Symbolic Expressions"
> First documented command is "FullForm"
>
> Then a one-liner for ReplaceAll occurs a few lines down. Yes, as you
> say, the one-liner needs an edit.
>
> I think this doc structure qualifies Mathematica as sufficiently
> "discoverable" [*].
>
> Vince Virgilio
>
> [*] I.e. 3rd bullet, second section, at:
> http://accu.org/index.php/journals/1572
>

### David Park

Jan 6, 2010, 5:59:02 AM1/6/10
to
I don't think that it is correct to expect that a mathematical object has a
Head. Mathematica only gives us various representations of objects and
different representations have different Heads. Thus

3 + 4 I, ComplexPolar[5, ArcTan[4/3]] (in Presentations), 5 E^(I
ArcTan[4/3]), Complex[3,4]

all represent the same mathematical object but all have different Heads.
(Plus, ComplexPolar, Times, Complex).

What might be confusing is that Complex is a NUMBER and not a symbolic
expression. WRI could improve the Help for Complex by changing the first
note to:

"You can enter a complex number in the form x + I y, where x and y are
Integer, Real, Rational or Complex numbers."

"Expressions such as Complex[a,b] with Symbols are not meaningful and are
left unevaluated. Symbolic complex expressions contain Complex numbers only
as subparts."

And then, among the first examples, they might show:

"Complex expressions may contain Complex numbers as subparts and can be
manipulated with routines such as Conjugate and ComplexExpand."

x + I y
% // FullForm
ComplexExpand[Conjugate[%]]
% // FullForm

x + I y
Plus[x,Times[Complex[0,1],y]]
x - I y
Plus[x,Times[Complex[0,-1],y]]

Very few users would use Complex numbers in isolation without combining them
in symbolic expressions. So why not stand users up and point them in the
right direction instead of just saying that the Help is 'formally correct'?

For those who use Help, of course.

From: Richard Fateman [mailto:fat...@cs.berkeley.edu]

[SNIP]

Are you describing Mathematica here? It seems to me that it is an

[SNIP]

You assume that people read the documentation. This is provably false.

RJF

### Richard Fateman

Jan 6, 2010, 5:59:28 AM1/6/10
to
I think it is interesting that the same issue came up in the design of
another computer algebra system, years ago.
That is, which objects are "atomic" and which are decomposable for
purposes of substitution. And further,
of those which are decomposable, how much cleverness should be applied
during substitution

For example, Exp[I x] -Exp[- I x] /. Exp[I x] -> s should probably
result in s-1/s.
In Mathematica, one gets s-E^(-Ix).

can either
(1) Make this come out s-1/s
or
(2) Argue that Mathematica already does the right thing, blame the user,
blame the documentation, blame the nature of mathematics, claim that it
is impossible to "read the user's mind" etc.

To me, the question is simply, by what programming technique can we make
Mathematica do the truly expected thing.
In this case, and I believe in every other case, a transformation of the
rules will help. In particular, using the rule
x-> -I Log[s] instead of Exp[x I] -> s.

Is it possible that Mathematica could make this change? How could it
possibly make such a transformation? (hint. Solve for variable s)

For another example,
x/5 /. 1/5->Fifth results in Fifth x but
3/5 /. 1/5 -> Fifth is unchanged.

Is it possible that Mathematica could do this consistently? Maybe it
could notice the rule is Rational[1, ...] -> <something> and decide
that
constitutes some possible point of dispute as to what to do
syntactically, and produce another rule, say Rational[a_,5]->a*Fifth

I think there are only a few other cases. The only one that comes to
mind is complex numbers. Suggestions?
(The suggestion that this program must not be written because it is

Checking for these possible transformations could be done by a program
in a relatively short time. Call it BetterRules.
Then instead of X /. Y one could do X /. BetterRules[Y]. A more
appropriate name or alternate syntax could be arranged.

All that is needed is a further elaboration of BetterRules, not more
argument. It is possible to look at the (free, open) source code of
decades-old programs. (email me for the name; Steve C might censor this
note if I wrote it here. :)

David Park wrote:
> I don't think that it is correct to expect that a mathematical object has a
> Head. Mathematica only gives us various representations of objects and
> different representations have different Heads. Thus
>
> 3 + 4 I, ComplexPolar[5, ArcTan[4/3]] (in Presentations), 5 E^(I
> ArcTan[4/3]), Complex[3,4]
>
> all represent the same mathematical object but all have different Heads.
> (Plus, ComplexPolar, Times, Complex).
>

I'm not sure what you mean. I expect that all Mathematica objects have
Heads, which are kind of like types in other languages.

> What might be confusing is that Complex is a NUMBER and not a symbolic
> expression.

A number is a symbolic expression too. Just a simple one that is
"atomic". Calling a complex number "atomic" and non-decomposable
is a hack that can be useful and can be detrimental.

> WRI could improve the Help for Complex by changing the first
> note to:
>
> "You can enter a complex number in the form x + I y, where x and y are
> Integer, Real, Rational or Complex numbers."
>
> "Expressions such as Complex[a,b] with Symbols are not meaningful and are
> left unevaluated.

The user who types this in to Mathematica
clearly has in mind something meaningful. It seems to me that it has
the same meaning as a+b*I,
and perhaps Mathematica should just produce that, instead of the
unevaluated Complex.
It would probably require no explanation, which is a plus.

> Symbolic complex expressions contain Complex numbers only
> as subparts."
>

This does not define "symbolic complex expression" , "contain"
"subpart" or "Complex number" [with capital].

> And then, among the first examples, they might show:
>
> "Complex expressions may contain Complex numbers as subparts and can be
> manipulated with routines such as Conjugate and ComplexExpand."
>
> x + I y
> % // FullForm
> ComplexExpand[Conjugate[%]]
> % // FullForm
>
> x + I y
> Plus[x,Times[Complex[0,1],y]]
> x - I y
> Plus[x,Times[Complex[0,-1],y]]
>
> Very few users would use Complex numbers in isolation without combining them
> in symbolic expressions.

I don't know. doing arithmetic on complex numbers is done by Fortran,
and Fortran doesn't have symbolic ANYTHING.

> So why not stand users up and point them in the
> right direction instead of just saying that the Help is 'formally correct'?
>
> For those who use Help, of course.
>

What I would say is

Because of the disparity in internal representations (see below) ,
for replacements on parts of complex expressions, don't use /. ...
use /. BetterRules[ ...]

or use transformation or selection programs such as Conjugate, Im, Re, ...

<< advanced section on internal representation of complex numbers>>

Mathematica has a special form for imaginary and complex constants that
provides certain efficiencies, but at the cost of two representations
for items that would be expected to be more similar.
I is Complex[0,1] internally.
3/4+4.2 I is simplified to Complex[3/4,4.2]. The parts of Complex
must be explicit Numbers.
x+4*I is simplified to Plus [x, Times[4, Complex[0,1]]].

etc

examples.

### DrMajorBob

Jan 7, 2010, 2:28:52 AM1/7/10
to
Some good points, David. When help says "You can enter a complex number in
the form x + I y", it is seriously misleading, without the qualification

x + I y is NOT a number (of any kind) when a and b are undefined, and
neither is Complex[x, y]:

NumericQ@Complex[x, y]

False

If they ARE defined, the result isn't necessarily complex (or even
sensible):

Complex[0, I]
N@%

Complex[0, I]

Complex[0., 0. + 1. I]

What the heck is that?

Complex[0.`, 0.` + 1.` I] // Simplify

Complex[0., 0. + 1. I]

Bobby

On Wed, 06 Jan 2010 04:59:15 -0600, David Park <djm...@comcast.net> wrote:

> I don't think that it is correct to expect that a mathematical object
> has a
> Head. Mathematica only gives us various representations of objects and
> different representations have different Heads. Thus
>
> 3 + 4 I, ComplexPolar[5, ArcTan[4/3]] (in Presentations), 5 E^(I
> ArcTan[4/3]), Complex[3,4]
>
> all represent the same mathematical object but all have different Heads.
> (Plus, ComplexPolar, Times, Complex).
>

> What might be confusing is that Complex is a NUMBER and not a symbolic

> expression. WRI could improve the Help for Complex by changing the first

> note to:
>
> "You can enter a complex number in the form x + I y, where x and y are
> Integer, Real, Rational or Complex numbers."
>
> "Expressions such as Complex[a,b] with Symbols are not meaningful and are

> left unevaluated. Symbolic complex expressions contain Complex numbers
> only
> as subparts."
>

> And then, among the first examples, they might show:
>
> "Complex expressions may contain Complex numbers as subparts and can be
> manipulated with routines such as Conjugate and ComplexExpand."
>
> x + I y
> % // FullForm
> ComplexExpand[Conjugate[%]]
> % // FullForm
>
> x + I y
> Plus[x,Times[Complex[0,1],y]]
> x - I y
> Plus[x,Times[Complex[0,-1],y]]
>
> Very few users would use Complex numbers in isolation without combining
> them

> in symbolic expressions. So why not stand users up and point them in the

> right direction instead of just saying that the Help is 'formally
> correct'?
>
> For those who use Help, of course.
>
>

> David Park
> djm...@comcast.net
> http://home.comcast.net/~djmpark/
>
>
> From: Richard Fateman [mailto:fat...@cs.berkeley.edu]
>
> [SNIP]
>
> Are you describing Mathematica here? It seems to me that it is an
>
> [SNIP]
>
> You assume that people read the documentation. This is provably false.
>
> RJF
>
>
>

### Bill Rowe

Jan 7, 2010, 2:32:23 AM1/7/10
to
On 1/6/10 at 5:59 AM, fat...@cs.berkeley.edu (Richard Fateman)
wrote:

>For example, Exp[I x] -Exp[- I x] /. Exp[I x] -> s should
>probably result in s-1/s. In Mathematica, one gets s-E^(-Ix).

>can either (1) Make this come out s-1/s
>or
>(2) Argue that Mathematica already does the right thing, blame the
>user, blame the documentation, blame the nature of mathematics,
>claim that it is impossible to "read the user's mind" etc.

The argument isn't that Mathematica does the "right" thing.
"Right" is quite subjective here. The result Mathematic does
return for this example is clearly mathematically correct even
if it is not the desired result.

The real choice is either

(1) understand how Mathematica is designed and make use of that
to get the result you want or

(2) find another software package that works more like what you want.

Arguing Mathematic does either the "wrong thing" or the "right
thing" here is pointless.

>To me, the question is simply, by what programming technique
>can we make Mathematica do the truly expected thing. In this
>case, and I
>believe in every other case, a transformation of the rules will
>help. In particular, using the rule
>x-> -I Log[s] instead of Exp[x I] -> s.

>Is it possible that Mathematica could make this change? How could
>it possibly make such a transformation? (hint. Solve for variable s)

=46or me, I never want Mathematica designed in a way where it
tries to guess or otherwise divine my intention and do something
other than what I specifically told it to do via my input. I
totally detest any software that does that. Which is one of the
main reasons a greatly dislike Microsoft Word.

>For another example, x/5 /. 1/5->Fifth results in Fifth x but
>3/5 /. 1/5 -> Fifth is unchanged.

>Is it possible that Mathematica could do this consistently?

What is inconsistent here?

Mathematica internally evaluates 1/5 as Rational[1,5], x/5 as
Times[x, Rational[1,5]] and 3/5 as Rational[3,5]. In every case
Rational[1,5] is being replaced with Fifth. Mathematica behaves
in a consistent manner even though this is clearly not
immediately apparent to a new user.

Again, the choice is either understand this behavior and live
with it or find different software. There isn't any other
productive choice.

Any software package that comes close to approximating the
capability Mathematica offers has to make some set of design
decisions. It simply is not possible to make those decisions in
a manner that will please all potential users or not cause some
level of confusion to a new user. This level of capability will
always require significant learning on the part of any user to master.

So, the real choice is learn and understand the way Mathematica
works and live with it or find another software package more to
your likely. There is no other productive choice.

### Noqsi

Jan 7, 2010, 2:32:47 AM1/7/10
to
On Jan 6, 3:59 am, Richard Fateman <fate...@cs.berkeley.edu> wrote:

>
> For example, Exp[I x] -Exp[- I x] /. Exp[I x] -> s should p=
robably

> result in s-1/s.
> In Mathematica, one gets s-E^(-Ix).

You're confusing two different kinds of "substitution". It is
extremely important to preserve the distinction.

>
> can either
> (1) Make this come out s-1/s
> or
> (2) Argue that Mathematica already does the right thing, blame the user,
> blame the documentation, blame the nature of mathematics, claim that it
> is impossible to "read the user's mind" etc.

Or blame those who don't understand critical distinctions and want to
erase them.

>
> To me, the question is simply, by what programming technique can we make
> Mathematica do the truly expected thing.

Well, in this case it does what anybody who understands how Replace
works and what it's good for expects. If that's not the "truly
expected thing", I don't know what is.

> In this case, and I believe in every other case, a transformation of the
> rules will help. In particular, using the rule
> x-> -I Log[s] instead of Exp[x I] -> s.

Mathematica has a tool that can do what you want here:

Reduce[a == Exp[I x] - Exp[-I x] && Exp[I x] == s, {a}, {x}]
s != 0 && a == (-1 + s^2)/s

It's a bit fussier than perhaps you'd like, but that's mathematics for
you ;-)

### Vince Virgilio

Jan 7, 2010, 2:33:43 AM1/7/10
to
On Jan 6, 5:59 am, Richard Fateman <fate...@cs.berkeley.edu> wrote:

SNIP

>
> What I would say is
>
> Because of the disparity in internal representations (see below) ,
> for replacements on parts of complex expressions, don't use /. ...
> use /. BetterRules[ ...]
>

This expects too much from ReplaceAll.

> or use transformation or selection programs such as Conjugate, Im, Re, .. .
>

Yes. Not unlike something Andrzej said elsewhere about
PolynomialReduce (others said similar as well).

SNIP

Vince Virgilio

(
Incidentally, my FullForm of x+4*I differs from yours, if I read yours
correctly:

In[1]:= x+4I//FullForm
Out[1]//FullForm= Plus[Complex[0,4],x]
)

### David Bailey

Jan 7, 2010, 2:34:06 AM1/7/10
to
Richard Fateman wrote:
> I think it is interesting that the same issue came up in the design of
> another computer algebra system, years ago.
> That is, which objects are "atomic" and which are decomposable for
> purposes of substitution. And further,
> of those which are decomposable, how much cleverness should be applied
> during substitution
>
> For example, Exp[I x] -Exp[- I x] /. Exp[I x] -> s should probably
> result in s-1/s.
> In Mathematica, one gets s-E^(-Ix).
>
> can either
> (1) Make this come out s-1/s
> or
> (2) Argue that Mathematica already does the right thing, blame the user,
> blame the documentation, blame the nature of mathematics, claim that it
> is impossible to "read the user's mind" etc.
>
> To me, the question is simply, by what programming technique can we make
> Mathematica do the truly expected thing.

Notice that using the transformation rule Exp[I x] -> s (or f[x]->s in
general) in the way you require, involves inverting it to produce
x->g[s] for some g. In general g may not be unique, which is why the
following code generates a warning, but essentially does what you want
to do:

Solve[Eliminate[{ans == Exp[I x] - Exp[-I x], Exp[I x] == s}, {x}], ans]

Reduce (rather than Eliminate) yields a more mathematically precise
answer, but the result is considerably more clumsy.

Note also that ReplaceAll *can* be used to do mathematical operations
without complications provided the LHS of each rule is a variable (but
not a constant such as I, Pi, etc).

David Bailey
http://www.dbaileyconsultancy.co.uk

### Richard Fateman

Jan 8, 2010, 4:15:23 AM1/8/10
to
Noqsi wrote:

>
> Mathematica has a tool that can do what you want here:
>
> Reduce[a == Exp[I x] - Exp[-I x] && Exp[I x] == s, {a}, {x}]
> s != 0 && a == (-1 + s^2)/s
>
> It's a bit fussier than perhaps you'd like, but that's mathematics for
> you ;-)
>

Reduce is a really neat program in Mathematica, one that I especially
admire since it was improved to work on more than polynomials.
Unfortunately, it won't work for I->-I, maybe because that is based on a
decision involving constants represented differently from expressions
that construct them. (David Bailey already pointed this out. Do people
get instantaneous unfiltered feed from this newsgroup??)

but also..
Bill Rowe said ...

"Again, the choice is either understand this behavior and live
with it or find different software. There isn't any other
productive choice."

Well, reporting something as a bug and hoping it will be fixed is
another choice.
And writing a version of the facility that does the right thing is
another choice. (Any takers?)

Either of these could be "productive".

Are Mathematica design decisions sacred or something?

RJF

### Bill Rowe

Jan 10, 2010, 3:28:30 AM1/10/10
to
On 1/8/10 at 4:15 AM, fat...@cs.berkeley.edu (Richard Fateman)
wrote:

>Bill Rowe said ...

>"Again, the choice is either understand this behavior and live with
>it or find different software. There isn't any other productive
>choice."

>Well, reporting something as a bug and hoping it will be fixed is
>another choice.

Reporting a behavior that works as designed as a bug and hoping
it will be "fixed" seems very unproductive to me. What is there
to "fix" if the program performs as designed?

>And writing a version of the facility that does the
>right thing is another choice. (Any takers?)

It seems to me, the effort to do this for replacement rules and
ensure the result doesn't cause other problems is far greater
than the effort needed to understand the current design and use
it to get your desired result.

>Either of these could be "productive".

This is highly debatable.

>Are Mathematica design decisions sacred or something?

Of course Mathematica design decisions are not sacred. But it is
highly desirable new versions of Mathematica run code written
for earlier versions. Altering design decisions almost certainly
means the new version will not run some code written for earlier
versions. So, altering design decisions is not something that
should be done lightly.

I don't believe the existence of users who have not yet taken
the time to understand the current design is sufficient cause to
change the current design. Nor do I think you have made a strong
enough case to warrant a design change in this case.

But on this second point, I am not the one who needs to be
convinced. It is someone at WRI who could actually implement a
change and their management.

### Noqsi

Jan 10, 2010, 3:29:12 AM1/10/10
to
On Jan 8, 2:15 am, Richard Fateman <fate...@cs.berkeley.edu> wrote:
> Noqsi wrote:
>
> > Mathematica has a tool that can do what you want here:
>
> > Reduce[a == Exp[I x] - Exp[-I x] && Exp[I x] == s, {a}, {x}]
> > s != 0 && a == (-1 + s^2)/s
>
> > It's a bit fussier than perhaps you'd like, but that's mathematics for
> > you ;-)
>
> Reduce is a really neat program in Mathematica, one that I especially
> admire since it was improved to work on more than polynomials.
> Unfortunately, it won't work for I->-I, maybe because that is based on a
> decision involving constants represented differently from expressions
> that construct them.

It's more that I==-I makes no sense.

> (David Bailey already pointed this out. Do people
> get instantaneous unfiltered feed from this newsgroup??)

No.

>
> but also..

> Bill Rowe said ...
> "Again, the choice is either understand this behavior and live
> with it or find different software. There isn't any other
> productive choice."
>
> Well, reporting something as a bug and hoping it will be fixed is
> another choice.

But nobody with sense thinks it's a bug.

Remember that nearly all of the expressions evaluated by Mathematica
are also generated by Mathematica, not by human users. Reading human
intent into such expressions would be a grave mistake. Fundamental
facilities like Replace have to perform predictably and regularly to
make it possible for the developers of Mathematica to avoid creating
bugs.

> And writing a version of the facility that does the right thing is
> another choice. (Any takers?)

You cannot even define with adequate rigor what you mean by the "right
thing". How, *in general*, should Mathematica make *mathematical*
sense of a command to replace a constant with a different constant?

>
> Either of these could be "productive".
>

> Are Mathematica design decisions sacred or something?

The design of fundamental functionality like Replace is severely
constrained by the architecture of the system. Balsa wood is a useful
material, but you cannot use it to make the base structure of a
skyscraper.

### Richard Fateman

Jan 11, 2010, 5:27:23 AM1/11/10
to
Bill Rowe wrote:
> On 1/8/10 at 4:15 AM, fat...@cs.berkeley.edu (Richard Fateman)
> wrote:
>
>> Bill Rowe said ...
>> "Again, the choice is either understand this behavior and live with
>> it or find different software. There isn't any other productive
>> choice."
>
>> Well, reporting something as a bug and hoping it will be fixed is
>> another choice.
>
> Reporting a behavior that works as designed as a bug and hoping
> it will be "fixed" seems very unproductive to me.

When one first reports a behavior that one believes is a bug, the
natural hope is that it will be fixed. To think otherwise is kind of
pessimistic, perhaps depressing. That's probably what motivated the
original poster (not me.)

> What is there
> to "fix" if the program performs as designed?

1. There are many many changes, some incompatible, to programs that
worked as designed in earlier versions of Mathematica. The design was
apparently deemed unsatisfactory.
2. All programs perform as programmed. Absent any different design
document, one could say that all programs operate as designed. After
all, the performance of the program is completely designed by the
program text, and it operates entirely according to the design.
This is the Peewee Herman argument ("I meant to do that").

>
>> And writing a version of the facility that does the
>> right thing is another choice. (Any takers?)
>
> It seems to me, the effort to do this for replacement rules and
> ensure the result doesn't cause other problems is far greater
> than the effort needed to understand the current design and use
> it to get your desired result.

You don't seem to understand "version of the facility". No one would be
forced to use such a version, and therefore one could always use the
original version so as to be compatible with previous design (mistakes,
features, whatever).

>
>> Either of these could be "productive".
>
> This is highly debatable.

Apparently :)

>
>> Are Mathematica design decisions sacred or something?
>
> Of course Mathematica design decisions are not sacred.

Yet you say proposing changes would be "unproductive", quoting from your
message above.

But it is
> highly desirable new versions of Mathematica run code written
> for earlier versions.

Of course, but that is not enforced by WRI. Why should you enforce it?
Your view would make it impossible to improve anything e.g. new
integration results, which would be incompatible with previous versions,
which might (for example) depend on certainly integration problems NOT
being done by the Integrate program.

> Altering design decisions almost certainly
> means the new version will not run some code written for earlier
> versions.

Not necessarily. Sometimes the change will return all results that were
previously computed, but will provide functionality over a new domain
too, as Integrate.

One could have a situation in which all code written for the previous
version (that worked) will continue to work.

A possible incompatibility would be one where previously the code said
"error, cannot compute this" and now it returns an answer.

While it may have its place in the world of software, being compatible
with all previous design decisions (and bugs!) is not a very attractive
plan for a software system such as Mathematica.

> So, altering design decisions is not something that
> should be done lightly.

That's why it should be discussed! Not dismissed out of hand.

>
> I don't believe the existence of users who have not yet taken
> the time to understand the current design is sufficient cause to
> change the current design.

Again, you insist that I am proposing changing the current design.
1. I think the current design is wrong. (or woefully underdocumented)
2. I think a better facility can be designed and implemented.

> Nor do I think you have made a strong
> enough case to warrant a design change in this case.

There are certainly arguments that this particular rule/replacement
facility "works" for writing certain low-level programs and that any
change which would alter the results or slow down the computation should
be avoided, at least for these pre-existing programs. There are
also clear arguments that a different facility should be presented
to the (less sophisticated) user, e.g. original poster.

>
> But on this second point, I am not the one who needs to be
> convinced. It is someone at WRI who could actually implement a
> change and their management.

I disagree. All you have to do is use your experience, skill, and
imagination, to think about what a GOOD substitution facility should do
as to not confuse someone who merely knows mathematics, and does not
have an interest in learning the subtleties of FullForm, Reduce,
Eliminate, .... Your ideas could then be implemented in a newly

RJF

### Richard Fateman

Jan 11, 2010, 5:27:35 AM1/11/10
to
Noqsi wrote:
>
>
> It's more that I==-I makes no sense.

That's not what anyone said. I -> -I means change the sign of all
imaginary quantities.

Rules do not necessarily represent value-preserving transformations.

Sometimes people write epsilon^2 -> 0 By which they do NOT mean
epsilon^2==0 and hence epsilon==0. What they mean is to discard
powers of epsilon greater than one. This rule, by the way, also
would not work, but epsilon^N_ ->0 with the condition N>1 might...
A better way might be to compute a Series in epsilon.

>

>> Well, reporting something as a bug and hoping it will be fixed is
>> another choice.
>
> But nobody with sense thinks it's a bug.

I'm rubber you're glue. Everything you say sticks to you.

>
> Remember that nearly all of the expressions evaluated by Mathematica
> are also generated by Mathematica, not by human users. Reading human
> intent into such expressions would be a grave mistake. Fundamental
> facilities like Replace have to perform predictably and regularly to
> make it possible for the developers of Mathematica to avoid creating
> bugs.

You totally miss the point. If a human writes a rule I->-I, then the
system can try to figure it out. Mathematica itself presumably would
not automagically write such a rule, and so it would not be an issue.
How to fix it for HumansOnly? Suggest to humans that they use
BetterRules[I->-I] which would perhaps produce a different rule, e.g.
Complex[a_,b_]->Complex[a,-b]. No big deal.

>
>> And writing a version of the facility that does the right thing is
>> another choice. (Any takers?)
>
> You cannot even define with adequate rigor what you mean by the "right
> thing".

I think I can. I'm just being generous to people like you who might
have suggestions about what you might like.

How, *in general*, should Mathematica make *mathematical*
> sense of a command to replace a constant with a different constant?

want, for even 60 seconds. As I pointed out above, rules are not used
solely for value-preserving transformations, and so replacing 1 by 2 can
make perfect sense. Note that Mathematica is perfectly happy to do
f[1]/. 1->2. {by the way, f[1]/.1->2 results in the fairly nonsensical
10.f[1]->2, but that's a parsing problem.}

>
>> Either of these could be "productive".
>>
>> Are Mathematica design decisions sacred or something?
>
> The design of fundamental functionality like Replace is severely
> constrained by the architecture of the system. Balsa wood is a useful
> material, but you cannot use it to make the base structure of a
> skyscraper.

A more apt analogy may be that if a system is built with one size and
shape of rectangular Lego bricks, you can make large stable rectangular
structures, but it is impossible to construct (say) a smooth sloping
ramp. Introducing another Lego shape can vastly expand the types of
structures that can be easily built. People who insist on the perfection
and purity of the original Lego brick can continue to use only those
bricks, and their buildings will be just fine, as long as they need not
comply with ADA. (They can't build wheelchair ramps for their disabled
Lego-persons.)

RJF

>
>