105 views

Skip to first unread message

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:

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

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:

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

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

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

>

>

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

your fault.:)

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

.......answers.........

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[1]:= I // FullForm

Out[1]//FullForm= Complex[0,1]

In[2]:= 1 + I // FullForm

Out[2]//FullForm= Complex[1,1]

So, "I" is simply a way to write down quickly the expression Complex

[0,1], while E and Pi directly represent the numbers E and Pi, without

any intermediate transformation.

Consequently, one should write:

In[3]:= 1 - 2 I /. Complex[x_, y_] -> Complex[x, -y]

Out[3]= 1+2*I

As far as I understand, in Mathematica, the transformation rules for

complex numbers should be always entered explicitly involving the

whole complex plane Complex[x_,y_].

The difference between symbols representing real numbers (E, Pi, ...)

and the complex I may be confusing: while this behavior is clearly

stated ("Numbers containing I are converted to the type Complex.") and

described in the section "Possible Issues", it is not explained

immediately and the only way to reveal it is using FullForm. Perhaps,

it should be reported in the "Basic examples".

ADL

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

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

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

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

Dec 31, 2009, 3:16:16 AM12/31/09

to

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

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".

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

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

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.

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

Your rule will work with a following (admittedly inconvenient) modification:

In[23]:= With[{I = Complex[0, 1]}, Unevaluated[-I] /. I :> -I]

Out[23]= I

Alternatively you can use:

In[39]:= Unevaluated[-I] /. HoldPattern[I] -> -I

Out[39]= I

In the latter case, we forbid <I> to evaluate in both the original

expression and the pattern, and then it works. My point is that this is not

a bug (in this particular case). Pattern-matching is based on syntax, not on

semantics, so to use it correctly one should have a pretty good idea of the

internal representation of participating expressions in Mathematica, as well

as on possible evaluations that may take place. This is certainly not

intuitive, but I think the cases you list represent exceptions rather than a

rule, and are (for I and Infinity) related to a rather special nature of the

objects represented by these symbols.

>

> In[3]:= -E/.E->-E

>

> Out[3]= << The Esc e e Esc symbol >>

>

This one works fine for me:

In[6]:= -E/.E->-E

Out[6]= E

>

> In[4]:= -Pi/.Pi->-Pi

>

> Out[4]= \[Pi]

>

This seems ok

>

> In[5]:= -Infinity/.Infinity->-Infinity

>

> Out[5]= -\[Infinity]

>

The same story here as for the case with <I>. Again, you can see the origin

of this puzzle by looking at the FullForm before and after the evaluation:

In[33]:= Hold[-Infinity]//FullForm

Out[33]//FullForm= Hold[Times[-1,Infinity]]

In[45]:= Infinity//FullForm

Out[45]//FullForm= DirectedInfinity[1]

You see that once we allow Infinity to evaluate, it becomes

DirectedInfinity[1], while -Infinity becomes DirectedInfinity[-1]. And the

possible solution which leads to "expected" pattern-matching:

In[38]:= Unevaluated[-Infinity] /. HoldPattern[Infinity] -> -Infinity

Out[38]= \[Infinity]

I think that there are not many more objects in Mathematica which are as

tricky as <I> or Infinity in terms of pattern-matching. I also think that

this is the case where the overall consistency of design requires that the

user gets (accidentally) exposed to some internals like above (because here

the line between internals and exposed to the user interface becomes very

blurred, given that a lot of Mathematica is written in Mathematica), which

are not as simple or intuitive as the general Mathematica functionality

intentionally exposed to the end user. It would perhaps be nice if such

cases were more systematically documented, but they have nothing to do with

bugs, as Daniel Lichtblau and many others already explained.

Hope this helps.

Regards,

Leonid

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

>

> 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

.

[**] http://en.wikipedia.org/wiki/Principle_of_least_astonishment

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.

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

>>

>

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

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.

--

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

to beat a dead horse).

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. "

--

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?

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!

--

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

> your fault.:)

> 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

> your fault.:)

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

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

> your fault.:)

>

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

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.

>

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 ....]

> 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[=> 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":

>

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.

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.

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,

>

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.

Head[2/3]

Rational

Head[Unevaluated[2/3]]

Times

Head[a/b]

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

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,> "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!

>

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

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. [ . . . ]> 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

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

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.

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

>>

>>

>

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,

>>>

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

your feedback.

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

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

>

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

Jan 3, 2010, 3:39:47 AM1/3/10

to

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

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.

> 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

ladder further ?

RJF

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!

--

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

> your feedback.

>

> 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

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

ask

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

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

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

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

>

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

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 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".

>

...

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

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

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

to

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

exception that Head[a+b*I] is Plus, but Head[3+4I] is Complex.

>

> 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

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

Jan 5, 2010, 1:47:23 AM1/5/10

to

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

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

> your feedback.

>

> 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

>>> the more advanced users.

>>>

>>

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

> exception that Head[a+b*I] is Plus, but Head[3+4I] is Complex.

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

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.

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

>

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

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

exception that Head[a+b*I] is Plus, but Head[3+4I] is Complex.

[SNIP]

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

RJF

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

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

instead.

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

wrong, has already been offered.)

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.

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

you added below.

the form x + I y", it is seriously misleading, without the qualification

you added below.

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

> exception that Head[a+b*I] is Plus, but Head[3+4I] is Complex.

>

> [SNIP]

>

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

>

> RJF

>

>

>

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:

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.

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 ;-)

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]

)

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.

> 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

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

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:

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.

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.

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

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.

> 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

designed additional facility.

RJF

Jan 11, 2010, 5:27:35 AM1/11/10

to

Noqsi wrote:

>

>

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

>

>

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

Instead of protesting, I suggest you think about what someone might

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

>

>

Jan 11, 2010, 6:53:56 PM1/11/10