Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

More /.{I->-1} craziness

110 views
Skip to first unread message

AES

unread,
Dec 30, 2009, 4:17:55 AM12/30/09
to
The more I play with these I->-I substitution rules, the more seemingly
wildly inconsistent results emerge. For example:

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

Out[1]= -I

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

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

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

Out[4]= \[Pi]

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

Out[5]= -\[Infinity]

(In/Out[2] is removed because it was an irrelevant cell.)

Bob Hanlon

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

You appear to be comparing apples and oranges.

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

{Complex,Symbol,Symbol,DirectedInfinity}

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

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

Since rules are applied to the FullForm,,,


Bob Hanlon

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

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

Alexander Elkins

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

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

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

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

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

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

That also works in this more general case:

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

Hope this helps...

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

Richard Fateman

unread,
Dec 31, 2009, 3:13:38 AM12/31/09
to
AES wrote:
> The more I play with these I->-I substitution rules, the more seemingly
> wildly inconsistent results emerge. For example:
>
> In[1]:= -I/.I->-I
>
> Out[1]= -I
>
..snip..
>
These examples you give are perfectly consistent with a certain world
view which is that I is not a symbol, but a functional form,
Complex[0,1], and -I is a different form, Complex[0,-1].

The fact that this is not what you expect as a mathematician is simply
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.

ADL

unread,
Dec 31, 2009, 3:14:12 AM12/31/09
to
The reason is this:
In[1]:= I // FullForm
Out[1]//FullForm= Complex[0,1]

In[2]:= 1 + I // FullForm
Out[2]//FullForm= Complex[1,1]

So, "I" is simply a way to write down quickly the expression Complex
[0,1], while E and Pi directly represent the numbers E and Pi, without
any intermediate transformation.

Consequently, one should write:
In[3]:= 1 - 2 I /. Complex[x_, y_] -> Complex[x, -y]
Out[3]= 1+2*I

As far as I understand, in Mathematica, the transformation rules for
complex numbers should be always entered explicitly involving the
whole complex plane Complex[x_,y_].

The difference between symbols representing real numbers (E, Pi, ...)
and the complex I may be confusing: while this behavior is clearly
stated ("Numbers containing I are converted to the type Complex.") and
described in the section "Possible Issues", it is not explained
immediately and the only way to reveal it is using FullForm. Perhaps,
it should be reported in the "Basic examples".

ADL

Valeri Astanoff

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

Good day,

Caveat substitutor !

That's not full craziness : what we see is *not*
what we get because pattern recognition is not
based on mathematical equivalence but on
structure equivalence (given by FullForm).

Imho, when applying a rule lhs -> rhs
it's a risky practice to use the same symbol
in 'lhs' and 'rhs', because, very often, there is
no easy way to check what has been done.

Anyway, for occasional users, you're right : it's crazy!

--
Valeri Astanoff

dh

unread,
Dec 31, 2009, 3:14:56 AM12/31/09
to
Hi,
no magic here, the pattern matcher is working on the full form, not
the displayed one. You can see the full form using: "FullForm".
The full form of -I is: Complex[0,-1] and that of I: Complex[0,1].
This explains why I does not match -I.
I do not see a problem with E and Pi.
For Infinity the full form is:DirectedInfinity[1] and for -Infinity:
DirectedInfinity[-1].
Daniel

Norbert P.

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

It might seem inconsistent, but as you can read in tutorial/
PatternsForSomeCommonTypesOfExpression:
"Especially for some common kinds of expressions, the standard
output format used by Mathematica is not particularly close to the
full internal form. But it is the internal form that you must use in
setting up patterns. "

So when you look at the expressions you give:
In[1]:= FullForm/@{I,-I,E,-E,Pi,-Pi,Infinity,-Infinity}
Out[1]= {Complex[0,1],Complex[0,-1],E,Times[-1,E],Pi,Times
[-1,Pi],DirectedInfinity[1],DirectedInfinity[-1]}

Hope that helps,
Norbert

David Bailey

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

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

Conjugate will give you a proper complex conjugate.

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

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

Exp[x] /. Exp -> Q

etc.

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

Murray Eisenberg

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

Try these:

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

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

AES wrote:
> The more I play with these I->-I substitution rules, the more seemingly
> wildly inconsistent results emerge. For example:
>
> In[1]:= -I/.I->-I
>
> Out[1]= -I
>
> In[3]:= -E/.E->-E
>
> Out[3]= << The Esc e e Esc symbol >>
>
> In[4]:= -Pi/.Pi->-Pi
>
> Out[4]= \[Pi]
>
> In[5]:= -Infinity/.Infinity->-Infinity
>
> Out[5]= -\[Infinity]
>
> (In/Out[2] is removed because it was an irrelevant cell.)
>

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

Patrick Scheibe

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

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

Cheers
Patrick

Leonid Shifrin

unread,
Dec 31, 2009, 3:17:44 AM12/31/09
to
Since other instances of this issue has been just discussed extensively in
a previous long thread, I will only add a slightly different viewpoint.
Namely, what can be done to make the rules work.

On Wed, Dec 30, 2009 at 12:15 PM, AES <sie...@stanford.edu> wrote:

> The more I play with these I->-I substitution rules, the more seemingly
> wildly inconsistent results emerge. For example:
>
> In[1]:= -I/.I->-I
>
> Out[1]= -I
>

Complex numbers (<I> included) have a pattern Complex[a,b]. The pattern you
try assumes that - I is internally represented as -Complex[0,1], while it is
in fact Complex[0,-1]. Now, <I> is a locked symbol (one of the very few)
with special properties. In particular, from the following it is obvious
that once the input <I> is processed, some evaluation takes place, since
\[ImaginaryI] gets replaced by Complex[0,1].

In[41]:= FullForm[I]
Out[41]//FullForm= Complex[0,1]

In[44]:= Hold[I]//FullForm
Out[44]//FullForm= Hold[\[ImaginaryI]]


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

Vince Virgilio

unread,
Dec 31, 2009, 3:19:23 AM12/31/09
to
On Dec 30, 4:17 am, AES <sieg...@stanford.edu> wrote:
> The more I play with these I->-I substitution rules, the more seemingly
> wildly inconsistent results emerge. For example:
>
> In[1]:= -I/.I->-I
>
> Out[1]= -I
>

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

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

Out[52]= -2


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

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

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

In[47]:= ReleaseHold@%

Out[47]= I


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

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

Out[41]= Hold[1 I]

In[42]:= ReleaseHold@%

Out[42]= I

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

Vince Virgilio


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

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

DrMajorBob

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

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

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

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

Bobby

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

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

> AES wrote:
>> The more I play with these I->-I substitution rules, the more seemingly
>> wildly inconsistent results emerge. For example:
>>
>> In[1]:= -I/.I->-I
>>
>> Out[1]= -I
>>

>> In[3]:= -E/.E->-E
>>
>> Out[3]= << The Esc e e Esc symbol >>
>>

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

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

>> (In/Out[2] is removed because it was an irrelevant cell.)
>>
>


--
DrMaj...@yahoo.com

Murray Eisenberg

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

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

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

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


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

--

Murray Eisenberg

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

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

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

Part of the difficulty in finding such things in the Documentation
Center may be the granularity of the documentation (as contrasted with
the now-defunct, printed "The Mathematica Book" -- if I may be permitted
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. "

--

Murray Eisenberg

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

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

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

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

--

David Bailey

unread,
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.:)

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

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

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

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

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


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

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

DrMajorBob

unread,
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.:)
>


--
DrMaj...@yahoo.com

Richard Fateman

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

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


I agree.
That's why it can be fixed.

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

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

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

....

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

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

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

Noqsi

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

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

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

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

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

Leonid Shifrin

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

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

Regards,
Leonid

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

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


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

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

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


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

> ....


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

Andrzej Kozlowski

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

David Bailey

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

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

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

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


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

Vince Virgilio

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

SNIP

Leonid,

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

Vince Virgilio

DrMajorBob

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

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

Bobby

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

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

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

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

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

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


--
DrMaj...@yahoo.com

Leonid Shifrin

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

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

Yes Bobby,

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

Regards,
Leonid

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

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

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

Leonid Shifrin

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

David Bailey

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

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

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

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


R Fateman

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

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

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

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

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

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

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

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

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

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

RJF

Murray Eisenberg

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

Wow: you covered quite a bit that first day!

Happy New Year,
Murray

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

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

--

Andrzej Kozlowski

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

Andrzej Kozlowski

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

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

f[x_]:=expr

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

f[some_pattern] := expr

or

expr/.some_pattern -> something

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

Andrzej Kozlowski

Leonid Shifrin

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


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


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

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


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

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

Regards,
Leonid

David Bailey

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

x=42

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

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

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

Fred Klingener

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

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

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

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

First line in tutorial/Applying TransformationRules:

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

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

Cheers,
Fred

Vince Virgilio

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

Richard Fateman

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

Richard Fateman

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

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

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

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

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

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

f=#1+1&

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

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

RJF


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

>.....


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

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

RJF

David Bailey

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

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


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

E. Martin-Serrano

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

Vince Virgilio

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

DrMajorBob

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

Bobby

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

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

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

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


--
DrMaj...@yahoo.com

David Park

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

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

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

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

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

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

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

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

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

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

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

For those who use Help, of course.


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

Richard Fateman

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

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

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

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

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

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

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

DrMajorBob

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

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


--
DrMaj...@yahoo.com

Bill Rowe

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

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

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

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

The real choice is either

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

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

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

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

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

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

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

>Is it possible that Mathematica could do this consistently?

What is inconsistent here?

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

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

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

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


Noqsi

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

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


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

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

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

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

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

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

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

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

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

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


Vince Virgilio

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

SNIP

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

This expects too much from ReplaceAll.

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

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

SNIP

Vince Virgilio

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

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

David Bailey

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

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

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

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

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

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

Richard Fateman

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

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

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

but also..
Bill Rowe said ...


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

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

Either of these could be "productive".

Are Mathematica design decisions sacred or something?

RJF

Bill Rowe

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

>Bill Rowe said ...


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

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

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

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

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

>Either of these could be "productive".

This is highly debatable.

>Are Mathematica design decisions sacred or something?

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

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

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


Noqsi

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

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

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

No.

>
> but also..


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

But nobody with sense thinks it's a bug.

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

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

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

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

> Are Mathematica design decisions sacred or something?

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


Richard Fateman

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

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

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

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


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

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


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

Apparently :)

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

RJF

Richard Fateman

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

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

Rules do not necessarily represent value-preserving transformations.

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

>

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

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


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

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


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

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

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

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

>
>

DrMajorBob

unread,
Jan 11, 2010, 6:53:56 PM1/11/10
to
WRI has blithely broken user code in the past, so Bill's argument that
they shouldn't in THIS case rings hollow.

Bobby

On Mon, 11 Jan 2010 04:27:30 -0600, Richard Fateman
<fat...@cs.berkeley.edu> wrote:

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

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

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

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

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

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

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

> Apparently :)


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

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

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

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

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

> Not necessarily. Sometimes the change will return all results that were
> previously computed, but will provide functionality over a new domain
> too, as Integrate.
>
> One could have a situation in which all code written for the previous
> version (that worked) will continue to work.
>
> A possible incompatibility would be one where previously the code said
> "error, cannot compute this" and now it returns an answer.
>
> While it may have its place in the world of software, being compatible
> with all previous design decisions (and bugs!) is not a very attractive
> plan for a software system such as Mathematica.
>
>
>
>

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

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

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

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

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

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

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

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


--
DrMaj...@yahoo.com

DrMajorBob

unread,
Jan 12, 2010, 4:49:41 AM1/12/10
to
I never said the change was a good idea. I've said some of us learned from
the thread, so it was worth (some) discussion.

And I DID say that WRI has broken plenty of user code in the past.

Ask David Park about colors changing their Head... or anybody (virtually
everyone) who had graphics output as side-effects in every one of their
notebooks.

Anybody who used Show was probably forced to reexamine that code.

Et cetera.

Bobby

On Mon, 11 Jan 2010 19:38:12 -0600, Andrzej Kozlowski <ak...@mimuw.edu.pl>
wrote:

> The obvious argument against doing this is that there is no evidence at
> all that there is a demand would actually justify any effort in this
> direction.
>
> So far I have noticed just two voices in favor, the person who once
> wrote a Mathematica parser that has never been used by anyone (as far as
> I can tell), you and that seems to be all. Even the OP, after his post
> was answer, did not, as far as I can tell, support the idea of adding
> new facilities to Mathematica so that he would not need to learn about
> FullForm.
> On the other hand, I have seen quite many people writing that they see
> no need for anything of this kind (I am not adding myself to their
> number).
>
> Obviously no well run company would ever embark on spending resources on
> something that may end up being never (or almost never) used.
>
> Andrzej Kozlowski


>
>
> On 12 Jan 2010, at 08:54, DrMajorBob wrote:
>
>> WRI has blithely broken user code in the past, so Bill's argument that
>> they shouldn't in THIS case rings hollow.
>>
>> Bobby
>>
>> On Mon, 11 Jan 2010 04:27:30 -0600, Richard Fateman
>> <fat...@cs.berkeley.edu> wrote:
>>
>>> Bill Rowe wrote:

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

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

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

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

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

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

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

>>> Apparently :)


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

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

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

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

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

>>> Not necessarily. Sometimes the change will return all results that were
>>> previously computed, but will provide functionality over a new domain
>>> too, as Integrate.
>>>
>>> One could have a situation in which all code written for the previous
>>> version (that worked) will continue to work.
>>>
>>> A possible incompatibility would be one where previously the code said
>>> "error, cannot compute this" and now it returns an answer.
>>>
>>> While it may have its place in the world of software, being compatible
>>> with all previous design decisions (and bugs!) is not a very attractive
>>> plan for a software system such as Mathematica.
>>>
>>>
>>>
>>>

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

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

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

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

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

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

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

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


--
DrMaj...@yahoo.com

Bill Rowe

unread,
Jan 12, 2010, 4:49:52 AM1/12/10
to
On 1/11/10 at 6:54 PM, btr...@austin.rr.com (DrMajorBob) wrote:

>WRI has blithely broken user code in the past, so Bill's argument
>that they shouldn't in THIS case rings hollow.

My point wasn't that WRI should not do things that break
existing code. But rather, they should not do this without good
reason. For example, the change in the way graphics works
between version 5 and 6 certainly caused broke some existing
code. But I believe the enhanced capabilities for graphics
provided by version 6 more than justified the effect on existing code.

OTOH making a change simply so that some subset of new users is
less confused and provides no other benefit would not be
sufficient reason for WRI to break existing code. On the
contrary, I would argue the need not to break existing code out
weighs the need to make Mathematica more intuitive for some
subset of users.

But, as you point out WRI has broken code in the past and will
certainly do so in the future. In order to grow Mathematica with
more functionality, it is inevitable some changes will break
existing code. Additionally, my opinion as to what justifies
breaking existing code is just that, my opinion. And that has
essentially no impact on what WRI does in the future.


Andrzej Kozlowski

unread,
Jan 12, 2010, 4:50:47 AM1/12/10
to
> (I am not adding myself to their number).


Oops. I meant "I am now adding myself to their number".


On 12 Jan 2010, at 10:38, Andrzej Kozlowski wrote:

> The obvious argument against doing this is that there is no evidence
at all that there is a demand would actually justify any effort in this
direction.
>
> So far I have noticed just two voices in favor, the person who once
wrote a Mathematica parser that has never been used by anyone (as far as
I can tell), you and that seems to be all. Even the OP, after his post
was answer, did not, as far as I can tell, support the idea of adding
new facilities to Mathematica so that he would not need to learn about
FullForm.
> On the other hand, I have seen quite many people writing that they see
no need for anything of this kind (I am not adding myself to their
number).
>
> Obviously no well run company would ever embark on spending resources
on something that may end up being never (or almost never) used.
>
> Andrzej Kozlowski
>
>

> On 12 Jan 2010, at 08:54, DrMajorBob wrote:
>
>> WRI has blithely broken user code in the past, so Bill's argument
that
>> they shouldn't in THIS case rings hollow.
>>

>> Bobby
>>
>> On Mon, 11 Jan 2010 04:27:30 -0600, Richard Fateman
>> <fat...@cs.berkeley.edu> wrote:
>>
>>> Bill Rowe wrote:

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

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

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

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

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

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

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

>>> Apparently :)


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

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

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

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

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

>>> Not necessarily. Sometimes the change will return all results that
were
>>> previously computed, but will provide functionality over a new
domain
>>> too, as Integrate.
>>>
>>> One could have a situation in which all code written for the
previous
>>> version (that worked) will continue to work.
>>>
>>> A possible incompatibility would be one where previously the code
said
>>> "error, cannot compute this" and now it returns an answer.
>>>
>>> While it may have its place in the world of software, being
compatible
>>> with all previous design decisions (and bugs!) is not a very
attractive
>>> plan for a software system such as Mathematica.
>>>
>>>
>>>
>>>

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

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

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

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

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

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

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

Andrzej Kozlowski

unread,
Jan 12, 2010, 4:51:52 AM1/12/10
to
The obvious argument against doing this is that there is no evidence at
all that there is a demand would actually justify any effort in this
direction.

So far I have noticed just two voices in favor, the person who once
wrote a Mathematica parser that has never been used by anyone (as far as
I can tell), you and that seems to be all. Even the OP, after his post
was answer, did not, as far as I can tell, support the idea of adding
new facilities to Mathematica so that he would not need to learn about
FullForm.
On the other hand, I have seen quite many people writing that they see
no need for anything of this kind (I am not adding myself to their
number).

Obviously no well run company would ever embark on spending resources on
something that may end up being never (or almost never) used.

Andrzej Kozlowski


On 12 Jan 2010, at 08:54, DrMajorBob wrote:

> WRI has blithely broken user code in the past, so Bill's argument that

> they shouldn't in THIS case rings hollow.
>
> Bobby
>
> On Mon, 11 Jan 2010 04:27:30 -0600, Richard Fateman
> <fat...@cs.berkeley.edu> wrote:
>
>> Bill Rowe wrote:

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

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

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

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

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

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

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

>> Apparently :)


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

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

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

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

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

>> Not necessarily. Sometimes the change will return all results that
were
>> previously computed, but will provide functionality over a new domain
>> too, as Integrate.
>>
>> One could have a situation in which all code written for the previous
>> version (that worked) will continue to work.
>>
>> A possible incompatibility would be one where previously the code
said
>> "error, cannot compute this" and now it returns an answer.
>>
>> While it may have its place in the world of software, being
compatible
>> with all previous design decisions (and bugs!) is not a very
attractive
>> plan for a software system such as Mathematica.
>>
>>
>>
>>

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

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

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

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

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

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

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

Bill Rowe

unread,
Jan 12, 2010, 4:52:27 AM1/12/10
to
On 1/11/10 at 5:27 AM, fat...@cs.berkeley.edu (Richard Fateman)
wrote:

>Bill Rowe wrote:

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

Which is very reasonably when what is reported as a bug is
indeed a bug. But it is not reasonable to expect something
reported as a bug to be changed when it is not a bug. Nor is it
reasonable to expect WRI to intuit your meaning of bug when it
differs from the standard accepted difference. That is, the
behavior being discussed is simply not a bug. It is exactly the
behavior the documentation indicates should occur.

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

What??? I have no access to the source code. And if I have any
significant influence over WRI, I am not aware of it. In short,
I've no capability to enforce my view of how Mathematica should
be designed on anyone.

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

Let me just respond here by clearly stating the above is not
representative of my view at all.

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

That type of change sounds more like a change in the method of
computation not a change of design.

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

You clearly state here you think the design "is wrong" and can
be better. If you are not suggesting changing the design what
are you suggesting? Leaving a design you feel is incorrect and
somehow patching it?

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

Well if you think *I* am the one who needs convincing your
prospects for seeing this change are very slim indeed.

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

You appear to be suggesting Mathematica should be written to
enable someone to do mathematics without understanding much in
the way in which Mathematica works. While I can there are those
who want something to just work without additional effort on
their part, I don't see this as happening with anything as
powerful and complex as Mathematica. Someone who "merely knows"
mathematics and has no interest in FullForm, Reduce, Eliminate,
ReplacementRule etc would be well advised to do mathematics by
hand and not use Mathematica at all. It simply is not reasonable
to expect good results from a tool if you are unwilling to learn
how to use the tool.


Richard Fateman

unread,
Jan 13, 2010, 5:55:28 AM1/13/10
to
Andrzej Kozlowski wrote:
> The obvious argument against doing this is that there is no evidence at
> all that there is a demand would actually justify any effort in this
> direction.

1. It is interesting that a response to this message from DrMajorBob
appears in my newsreader approximately one minutes before the message
itself. So either AK and DMB either have early access to the newgroup
or (more probably) are corresponding separately.

2. If you wishes to characterize complaints on the newsgroup as "no
evidence at all" then quite a few suggestions should be ignored.

>
> So far I have noticed just two voices in favor, the person who once
> wrote a Mathematica parser that has never been used by anyone (as far as
> I can tell),

Talking about "no evidence". What could I hypothesize about you, based
on no evidence? I'm afraid SteveC would (correctly) censor it!

For your information, the lisp program MockMMA (are we allowed to
mention this here??) has been used by a few people for system building
projects of various sorts. From a Google search, a note back in 2001 says
"It's used in Tilu http://torte.cs.berkeley.edu:8010/tilu .
There are about 40 people who have downloaded copies and told
me they did so; one person apparently used it as the basis for
an NSF small business grant".
{Tilu, after running about 250,000 queries, over a few years, was shut
down.}


> you and that seems to be all. Even the OP, after his post
> was answer, did not, as far as I can tell, support the idea of adding
> new facilities to Mathematica so that he would not need to learn about
> FullForm.

As far as YOU can tell.

> On the other hand, I have seen quite many people writing that they see
> no need for anything of this kind (I am not adding myself to their
> number).

Many? Really? On the other hand, you are not counting the ones who wrote
to me off the newsgroup, in favor of the idea.


>
> Obviously no well run company would ever embark on spending resources on
> something that may end up being never (or almost never) used.

I did not know that you were an expert on business practices. Would you
therefore recommend that airlines stop carrying lifeboats on Boeing
747s? They've almost never been used (perhaps never? I think crashes
into deep ocean water result in 100% fatalities).

David Park

unread,
Jan 13, 2010, 5:55:42 AM1/13/10
to
I thought WRI messed up because whereas previously all NAMED colors had the
head RGBColor, in Version 5 some had that head and others had the Head
GrayLevel. But in Version 6 WRI instituted a much more comprehensive color
scheme and I think most users are happy with that.

Richard Fateman

unread,
Jan 13, 2010, 5:56:20 AM1/13/10
to
Bill Rowe wrote:
> On 1/11/10 at 5:27 AM, fat...@cs.berkeley.edu (Richard Fateman)
> wrote:
>
>> Bill Rowe wrote:
>
>>> 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.
>
> Which is very reasonably when what is reported as a bug is
> indeed a bug. But it is not reasonable to expect something
> reported as a bug to be changed when it is not a bug.

It seems to be inevitable that people will, with such a complex system
as Mathematica, have differences of opinion as to whether some behavior
constitutes a bug or not. When WRI declares "this is a feature not a
bug", that does not necessarily change peoples' opinions. In fact,
WRI has, from time to time, changed its opinion on what is a feature or
a bug.


> Nor is it
> reasonable to expect WRI to intuit your meaning of bug when it
> differs from the standard accepted difference. That is, the
> behavior being discussed is simply not a bug. It is exactly the
> behavior the documentation indicates should occur.

Especially when the documentation is vague or lacking on what should
occur, the difference between a feature and a bug is elusive.

>
>>> 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?
>
> What??? I have no access to the source code. And if I have any
> significant influence over WRI, I am not aware of it. In short,
> I've no capability to enforce my view of how Mathematica should
> be designed on anyone.

I did not ever suppose that you could actually enforce "compatibility
with all past mistakes"; WRI does not enforce it either. I was
attempting to state, in a shorthand way, the idea that -- I can
understand if WRI wants to be compatible with past mistakes because of
an existing code base, and they will presumably act in what they
perceive as their own best interests in this regard. Having you act as
another voice asking them, or reminding them, to enforce this line of
reasoning, (especially given your own admitted lack of influence :) is
pointless, and your arguments about what is good or bad should be based
on better criteria which would presumably be "what would make
Mathematica the best system for your own work [or your estimation of
what other people do with it]".

For example, if you have a substantial amount of code written for
Mathematica, you might be able to say such a change would break X% of my
code. (You would have to have an implementation of the proposed change
to make this judgment -- but that has been supplied now.). My guess is
that X%=0%. On the other hand, the implementation given will slightly
slow down ReplaceAll if it were used all the time, and so, as I have now
repeatedly suggested, a user-oriented "BetterRules" could be provided.

>
>> 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.
>
> Let me just respond here by clearly stating the above is not
> representative of my view at all.
>
>>> 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.
>
> That type of change sounds more like a change in the method of
> computation not a change of design.

I don't know why a change in the method of computation which results in
different answers for some inputs would be more (or less) acceptable in
the view of "compatibility with previous behavior" than a change of
design which results in different answers. Maybe you are arguing
something about simultaneously altering the documentation or some such
thing?


>
>>> 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.
>
> You clearly state here you think the design "is wrong" and can
> be better.

> If you are not suggesting changing the design what
> are you suggesting?

I think you are being too defensive. If I say that a neighborhood
restaurant has a poor wine list and could be better, there are several
solutions. e.g. going elsewhere. not drinking wine there. bringing my
own wine. making recommendations for different wine.


> Leaving a design you feel is incorrect and
> somehow patching it?

Patching "it"? Yes, providing another similar but (in my view) more
user-friendly facility. Of course some people seem to hold the view
that revising ReplaceAll would be a mistake (I can understand that view),
but that ReplaceAll is perfect and it is the user's problem if it
doesn't do what she expects (I am less sympathetic to that view).
and some people seem to think that a different version of ReplaceAll and
friends is an abomination and must not be allowed. (I am surprised by
this view.)
... snip...

>
> You appear to be suggesting Mathematica should be written to
> enable someone to do mathematics without understanding much in
> the way in which Mathematica works.

Yes. One of the goals of the people who have been developing software
for "symbolic mathematical computation" starting in the 1960s, was that,
to the largest extent possible, the newly discovered and implemented
algorithmic underpinnings of constructive mathematics should be merged
with the natural notations and usage of practicing mathematicians,
scientists, engineers, etc, so these computer systems could be used most
widely and most effectively.

> While I can there are those
> who want something to just work without additional effort on
> their part,

Yes.

I don't see this as happening with anything as
> powerful and complex as Mathematica.

It is a particular conceit of Stephen Wolfram that he has invented a new
and improved notation and method for designating computation, and that
if only everyone learned it, mathematics and perhaps all of science
would be so much better for it. And I see it echoed here --

why don't we have all high school students learn Mathematica?

(Uh, answer: maybe Mathematica is (a) unnecessary, (b) unnecessarily
complex, (c) not as powerful as you think, (d) the complexity is not
required to provide the power, (e) Have you really examined all the
history of introducing computing to lower grades in school? (f) Even if
we agree that "algorithms and/or computing" is a good thing to know, is
Mathematica the tool?)

> Someone who "merely knows"
> mathematics and has no interest in FullForm, Reduce, Eliminate,
> ReplacementRule etc would be well advised to do mathematics by
> hand and not use Mathematica at all.

You know, there are a few alternatives other than doing mathematics "by
hand" va. Mathematica that do not require knowledge of these items,
and I hope you and other readers of this note consider that your
comment it is an example of your "drinking the {wolfram} kool aid".

Is the choice "learn internals of Mathematica" or "don't use computers"?

Please think about this.

> It simply is not reasonable
> to expect good results from a tool if you are unwilling to learn
> how to use the tool.

One of the attributes of computer software is that it is almost
infinitely malleable. When a particular design of a software tool
turns out to be ill-suited to a particular task, it is worth considering
whether a better alternative or additional tool can be designed. Even if
you have learned to use the existing tool, that does not mean you are
constrained to use it to the exclusion of others, nor that you are
forbidden from designing another, or suggesting that other people help
design other tools.

RJF

DrMajorBob

unread,
Jan 14, 2010, 5:46:18 AM1/14/10
to
I'm less concerned about the way ReplaceAll works than Richard, and I can
see downsides to some of the suggested behavior.

It's entirely possible that I might want to substitute I -> -I in the
current manner -- leaving instances of -I alone.

Changing ReplaceAll as suggested might close off that option (and similar
options in other pattern replacement situations).

HOWEVER, I'm sympathetic with Richard's frustration about how critique and
suggestions are received, as if it were heresy at witch-burning time.

Bobby

On Wed, 13 Jan 2010 04:56:20 -0600, Richard Fateman
<fat...@cs.berkeley.edu> wrote:

> Bill Rowe wrote:
>> On 1/11/10 at 5:27 AM, fat...@cs.berkeley.edu (Richard Fateman)
>> wrote:
>>
>>> Bill Rowe wrote:
>>
>>>> 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.
>>
>> Which is very reasonably when what is reported as a bug is
>> indeed a bug. But it is not reasonable to expect something
>> reported as a bug to be changed when it is not a bug.
>

> It seems to be inevitable that people will, with such a complex system
> as Mathematica, have differences of opinion as to whether some behavior
> constitutes a bug or not. When WRI declares "this is a feature not a
> bug", that does not necessarily change peoples' opinions. In fact,
> WRI has, from time to time, changed its opinion on what is a feature or

> a bug.
>
>
>> Nor is it
>> reasonable to expect WRI to intuit your meaning of bug when it
>> differs from the standard accepted difference. That is, the
>> behavior being discussed is simply not a bug. It is exactly the
>> behavior the documentation indicates should occur.
>

> Especially when the documentation is vague or lacking on what should
> occur, the difference between a feature and a bug is elusive.
>
>>

>>>> 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?
>>
>> What??? I have no access to the source code. And if I have any
>> significant influence over WRI, I am not aware of it. In short,
>> I've no capability to enforce my view of how Mathematica should
>> be designed on anyone.
>

> I did not ever suppose that you could actually enforce "compatibility
> with all past mistakes"; WRI does not enforce it either. I was
> attempting to state, in a shorthand way, the idea that -- I can
> understand if WRI wants to be compatible with past mistakes because of
> an existing code base, and they will presumably act in what they
> perceive as their own best interests in this regard. Having you act as
> another voice asking them, or reminding them, to enforce this line of
> reasoning, (especially given your own admitted lack of influence :) is
> pointless, and your arguments about what is good or bad should be based
> on better criteria which would presumably be "what would make
> Mathematica the best system for your own work [or your estimation of
> what other people do with it]".
>
> For example, if you have a substantial amount of code written for
> Mathematica, you might be able to say such a change would break X% of my
> code. (You would have to have an implementation of the proposed change
> to make this judgment -- but that has been supplied now.). My guess is
> that X%=0%. On the other hand, the implementation given will slightly
> slow down ReplaceAll if it were used all the time, and so, as I have now
> repeatedly suggested, a user-oriented "BetterRules" could be provided.
>
>>

>>> 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.
>>
>> Let me just respond here by clearly stating the above is not
>> representative of my view at all.
>>
>>>> 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.
>>
>> That type of change sounds more like a change in the method of
>> computation not a change of design.
>

> I don't know why a change in the method of computation which results in
> different answers for some inputs would be more (or less) acceptable in
> the view of "compatibility with previous behavior" than a change of
> design which results in different answers. Maybe you are arguing
> something about simultaneously altering the documentation or some such
> thing?
>>

>>>> 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.
>>
>> You clearly state here you think the design "is wrong" and can
>> be better.
>
>> If you are not suggesting changing the design what
>> are you suggesting?
>

> I think you are being too defensive. If I say that a neighborhood
> restaurant has a poor wine list and could be better, there are several
> solutions. e.g. going elsewhere. not drinking wine there. bringing my
> own wine. making recommendations for different wine.
>
>
>
>

>> Leaving a design you feel is incorrect and
>> somehow patching it?
>

> Patching "it"? Yes, providing another similar but (in my view) more
> user-friendly facility. Of course some people seem to hold the view
> that revising ReplaceAll would be a mistake (I can understand that view),
> but that ReplaceAll is perfect and it is the user's problem if it
> doesn't do what she expects (I am less sympathetic to that view).
> and some people seem to think that a different version of ReplaceAll and
> friends is an abomination and must not be allowed. (I am surprised by
> this view.)
> ... snip...
>
>>

>> You appear to be suggesting Mathematica should be written to
>> enable someone to do mathematics without understanding much in
>> the way in which Mathematica works.
>

> Yes. One of the goals of the people who have been developing software
> for "symbolic mathematical computation" starting in the 1960s, was that,
> to the largest extent possible, the newly discovered and implemented
> algorithmic underpinnings of constructive mathematics should be merged
> with the natural notations and usage of practicing mathematicians,
> scientists, engineers, etc, so these computer systems could be used most
> widely and most effectively.
>

>> While I can there are those
>> who want something to just work without additional effort on
>> their part,
>

> Yes.


>
> I don't see this as happening with anything as
>> powerful and complex as Mathematica.
>

> It is a particular conceit of Stephen Wolfram that he has invented a new
> and improved notation and method for designating computation, and that
> if only everyone learned it, mathematics and perhaps all of science
> would be so much better for it. And I see it echoed here --
>
> why don't we have all high school students learn Mathematica?
>
> (Uh, answer: maybe Mathematica is (a) unnecessary, (b) unnecessarily
> complex, (c) not as powerful as you think, (d) the complexity is not
> required to provide the power, (e) Have you really examined all the
> history of introducing computing to lower grades in school? (f) Even if
> we agree that "algorithms and/or computing" is a good thing to know, is
> Mathematica the tool?)
>
>
>
>
>

>> Someone who "merely knows"
>> mathematics and has no interest in FullForm, Reduce, Eliminate,
>> ReplacementRule etc would be well advised to do mathematics by
>> hand and not use Mathematica at all.
>

> You know, there are a few alternatives other than doing mathematics "by
> hand" va. Mathematica that do not require knowledge of these items,
> and I hope you and other readers of this note consider that your
> comment it is an example of your "drinking the {wolfram} kool aid".
>
> Is the choice "learn internals of Mathematica" or "don't use computers"?
>
> Please think about this.
>
>
>

>> It simply is not reasonable
>> to expect good results from a tool if you are unwilling to learn
>> how to use the tool.
>

> One of the attributes of computer software is that it is almost
> infinitely malleable. When a particular design of a software tool
> turns out to be ill-suited to a particular task, it is worth considering
> whether a better alternative or additional tool can be designed. Even if
> you have learned to use the existing tool, that does not mean you are
> constrained to use it to the exclusion of others, nor that you are
> forbidden from designing another, or suggesting that other people help
> design other tools.
>
> RJF
>


--
DrMaj...@yahoo.com

Andrzej Kozlowski

unread,
Jan 14, 2010, 5:47:57 AM1/14/10
to

On 13 Jan 2010, at 10:55, Richard Fateman wrote:

>>
>> So far I have noticed just two voices in favor, the person who once
>> wrote a Mathematica parser that has never been used by anyone (as far as
>> I can tell),
>

> Talking about "no evidence".

Well, then, what about this:

On 9 Feb 2004, at 16:17, Richard Fateman wrote:
>
> As far as MockMMA, I really don't
> care if people use it. I take pieces of it and use them when
> I need a rational function package or a parser.


Doesn't that sound like some evidence?

>
> Many? Really? On the other hand, you are not counting the ones who wrote
> to me off the newsgroup, in favor of the idea.

It must be a rein of terror that makes them keep it so secret.

> Would you
> therefore recommend that airlines stop carrying lifeboats on Boeing
> 747s? They've almost never been used (perhaps never? I think crashes
> into deep ocean water result in 100% fatalities).

Oh, I see, lifeboats. I am sure if you could get FAA on your side there would still be some hope that all your efforts may not be wasted.

Andrzej Kozlowski

Bill Rowe

unread,
Jan 14, 2010, 5:49:07 AM1/14/10
to
On 1/13/10 at 5:56 AM, fat...@cs.berkeley.edu (Richard Fateman)
wrote:

>Bill Rowe wrote:
>>On 1/11/10 at 5:27 AM, fat...@cs.berkeley.edu (Richard Fateman)
>>wrote:

>>>When one first reports a behavior that one believes is a bug, the


>>>natural hope is that it will be fixed.

>>Which is very reasonably when what is reported as a bug is indeed a
>>bug. But it is not reasonable to expect something reported as a bug
>>to be changed when it is not a bug.

>It seems to be inevitable that people will, with such a complex
>system as Mathematica, have differences of opinion as to whether
>some behavior constitutes a bug or not. When WRI declares "this is
>a feature not a bug", that does not necessarily change peoples'
>opinions. In fact, WRI has, from time to time, changed its opinion
>on what is a feature or a bug.

Certainly it is true a declaration from WRI might have little or
no effect on someone's opinion. And it is certainly true there
will be those who have different opinions as to what a bug is.
But in the final analysis, it only matters what WRI defines as a
bug in Mathematica. I don't expect WRI to change Mathematica to
fix a "bug" if the behavior being changed is not a bug from
their perspective. And in this thread, it seems very clear the
behavior of ReplaceAll with respect to complex values is not a bug.

>>Nor is it reasonable to expect WRI to intuit your meaning of bug
>>when it differs from the standard accepted difference. That is, the
>>behavior being discussed is simply not a bug. It is exactly the
>>behavior the documentation indicates should occur.

>Especially when the documentation is vague or lacking on what should
>occur, the difference between a feature and a bug is elusive.

No disagreement here.

>>You appear to be suggesting Mathematica should be written to enable
>>someone to do mathematics without understanding much in the way in
>>which Mathematica works.

>Yes. One of the goals of the people who have been developing
>software for "symbolic mathematical computation" starting in the
>1960s, was that, to the largest extent possible, the newly
>discovered and implemented algorithmic underpinnings of constructive
>mathematics should be merged with the natural notations and usage of
>practicing mathematicians, scientists, engineers, etc, so these
>computer systems could be used most widely and most effectively.

>>While I can there are those who want something to just work without
>>additional effort on their part,

>Yes.

>>I don't see this as happening with anything as powerful and complex as
>>Mathematica.

>It is a particular conceit of Stephen Wolfram that he has invented a
>new and improved notation and method for designating computation,
>and that if only everyone learned it, mathematics and perhaps all of
>science would be so much better for it. And I see it echoed here --

I've no specific knowledge of Steven Wolfram's views regarding
what you write above, but this totally misses my point. I make
no claim as to whether notation used in Mathematica is superior
or inferior to notation used in mathematics or that anyone will
be bettered by learning Mathematica notation.

But to use Mathematica efficiently and effectively, it is
essential to learn the notation used in Mathematica. Failure to
do so severely limits what you can do with Mathematica. The
point is effective use of any software tool requires
understanding that tool. This point has absolutely nothing to
say about whether the tool that is Mathematica is better or not
for some particular use. Nor does it say someone who has learned
to use Mathematica is in anyway "better" than someone who has not.

>why don't we have all high school students learn Mathematica?

>(Uh, answer: maybe Mathematica is (a) unnecessary,

Clearly true to a large extent since mathematics has been done
long before any version of Mathematica existed.

>(b) unnecessarily complex,

Given the complexity of mathematics and what Mathematica is
designed to do, I don't see Mathematica as "unnecessarily complex.

>(c) not as powerful as you think,

Since I've yet to fully master all of the capability in
Mathematica (and probably never will), it seems clear
Mathematica isn't significantly less powerful than I think.

>(d) the complexity is not required to provide the power,

Possibly true, but I very much doubt that it is true.

>(e) Have you really examined all the history of introducing computing
>to lower grades in school?

No, I have not. But my knowledge of the history of introducing
computing in to lower school grades is not germane to this
thread. In fact, the whole question of why Mathematica is not
widely used in high school really has little to do with this
thread. Given funding made available to high schools, the cost
of a Mathematica license almost certainly puts Mathematica out
of reach regardless of complexity and capability.

>(f) Even if we agree that "algorithms and/or computing" is a good thing
>to know, is Mathematica the tool?)

There may be better tools than Mathematica. But that is beside
the point. Making efficient/effective use of Mathematica entails
more than just a passing knowledge of algorithms and computing.
A lack of knowledge in these areas will severely limit what can
be done with Mathematica.

>>Someone who "merely knows" mathematics and has no interest in
>>FullForm, Reduce, Eliminate, ReplacementRule etc would be well
>>advised to do mathematics by hand and not use Mathematica at all.

>You know, there are a few alternatives other than doing mathematics
>"by hand" va. Mathematica that do not require knowledge of these
>items, and I hope you and other readers of this note consider that
>your comment it is an example of your "drinking the {wolfram} kool
>aid".

>Is the choice "learn internals of Mathematica" or "don't use
>computers"?

No. The advise is if you want to master the use of Mathematica
as a problem solving tool, you need to learn something about the
design of Mathematica. If you are unwilling to do that, you
would be well advised to use a different tool. This in no way
says Mathematica is essential to solving a particular problem. I
do not have the view it is the "Mathematica way" or the highway.
I do have the view effective problems solving using Mathematica
requires more than just a knowledge of mathematics.

Note, the point I am expressing here is applicable to any CAS
not just Mathematica.

>>It simply is not reasonable to expect good results from a tool if
>>you are unwilling to learn how to use the tool.

>One of the attributes of computer software is that it is almost
>infinitely malleable. When a particular design of a software tool
>turns out to be ill-suited to a particular task, it is worth
>considering whether a better alternative or additional tool can be
>designed. Even if you have learned to use the existing tool, that
>does not mean you are constrained to use it to the exclusion of
>others, nor that you are forbidden from designing another, or
>suggesting that other people help design other tools.

I've no disagreement with the above. But none of what you say
here changes the need to learn how to use a tool in order to
make effective use of that tool to obtain good results.


AES

unread,
Jan 15, 2010, 3:19:47 AM1/15/10
to
In article <hhhmhl$o48$1...@smc.vnet.net>,
Valeri Astanoff <asta...@gmail.com> wrote:

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

Thank you -- that's really my primary point.

And I'd add: it's damaging (to users, and to Mathematica).

As for writing rules, I'd not even try writing something compound, like
a + b or especially something like 1 + I, on the lhs, because I'd have
no intuition as to how this would work (how spaces would be handled,
etc.)

But a single character on the lhs? It works correctly AFAIK for every
other single-character in the alphabet. Why shouldn't one expect it to
work for I?

AES

unread,
Jan 15, 2010, 3:19:58 AM1/15/10
to
In article <hhhmkr$o7g$1...@smc.vnet.net>,
Murray Eisenberg <mur...@math.umass.edu> wrote:

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

Agreed -- I'd also be extremely cautious in that limit. But I behaving
differently (AFAIK) from every other single-character symbol in the
alphabet? (esp. E and Pi)

AES

unread,
Jan 15, 2010, 3:20:09 AM1/15/10
to
In article <hhhmn8$o9t$1...@smc.vnet.net>,
Leonid Shifrin <lsh...@gmail.com> wrote:

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

In other words, the vast majority of college students, working engineers
and scientists, and generally anyone with less than an MS degree in
Math, should stay miles away from Mathematica.

At least that's what these words imply to me . . .

AES

unread,
Jan 15, 2010, 3:20:20 AM1/15/10
to
In article <hhhmn8$o9t$1...@smc.vnet.net>,
Leonid Shifrin <lsh...@gmail.com> wrote:

> 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

Thanks for shared reaction on documentation (though I don't think that
problem will be solved soon).

I'm not sure I ever called this a bug -- but in any case "product
defect" is a characterization I'll stick with.

AES

unread,
Jan 15, 2010, 3:20:31 AM1/15/10
to
In article <hhpl28$9lf$1...@smc.vnet.net>,
Leonid Shifrin <lsh...@gmail.com> wrote:

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


But on the other hand, innumerable software apps of all varieties and at
all levels down to the most elementary (e.g., nearly all word
processors, text editors, graphics programs, spreadsheet programs, email
programs, and so on) include "Find and Replace" capabilities.

These capabilities frequently have varied options:
"Find Next" "Replace and Find" "As Word"
"Start at Top" "Replace All" "In Selection Only"
and so on. Many have optional GREP abilities.

So:

1) Most any computer user at even a very elementary level knows about
these tools, rather expects to have them available, and expects them to
function as they in fact do function.

2) In particular, they operate (visibly!) on what you see -- not some
arcane internal representation.

3) So, if such a novice user goes to Mathematica, it's only to be
expected that this user will thnik that Mathematica's ReplaceAll should
function in a similar fashion (and, helpfully, Mathematic's /. operator
most of the time does function in that way) (sarcasm mode in that
parens).

4) So why can't Mathematica also have a TextReplace[ ] function, or
something similar, that would function in that way _on what the user
sees or has typed (or copied and pasted) into a selected cell_.

Given such a function my input would be Find " I " and replace it
with " (-I) ".

AES

unread,
Jan 15, 2010, 3:20:42 AM1/15/10
to
In article <hhhme6$o0s$1...@smc.vnet.net>, Bob Hanlon <han...@cox.net>
wrote:

> 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

Responses to this and many other similar responses in this thread:

1) The problem is not explaining _why_ or _how_ this behavior
happens; the problem is that Mathematica has been constructed
_so that it happens_ -- and it's a damaging and unfortunate
and undesirable (and, at base, unnecessary?) way for Mathematica to
respond.

In other words, it's not necessarily a "bug" -- I don't have an opinion,
or even qualifications to have an opinion, on that point -- but it's
certainly a product defect..

2) Quote from the primary Help for I:

"The symbol I needs to be evaluated to become a complex number:"

Huh? What? "The **symbol** I ...?"

How many ordinary users of Mathematica do you think would view I, E and
Pi as symbols that all happen to represent a number -- but that all
function as symbols until you call for a numerical output?

Put another way, how many users do you think would automatically know or
expect, from their pre-Mathematica eduction that I, E and Pi would be
handled in this different (inconsistent) way in Mathematica?

David Park

unread,
Jan 16, 2010, 6:08:29 AM1/16/10
to
No, they should learn Mathematica early.

But they won't do that until Mathematica is nearly universal in the
technical community and is considered to be a must have, must learn
application.

And that won't happen until anyone who has Mathematica is able write
literate active dynamic notebooks that can be read by anyone following the
free Acrobat Reader model.

And once that happens, many more users will write their papers as
Mathematica notebooks, and many more people will read them and be persuaded
to buy and use Mathematica themselves.

Then, students will buy and learn Mathematica and when they get to college
they will know the basics and such simple things as how and how not to use
replacement rules.


From: AES [mailto:sie...@stanford.edu]

In article <hhhmn8$o9t$1...@smc.vnet.net>,

Murray Eisenberg

unread,
Jan 16, 2010, 6:09:05 AM1/16/10
to
The actual (i.e., FullForm) representation of I is Complex[0,1] whereas
the actual (i.e., FullForm) representation of E is and of Pi is Pi.

But it's not even an issue of what happens to a single-character symbol.
As discussed in previous posts, the FullForm of 2 Pi I, e.g., is
Times[Complex[0,2],Pi] -- and, more generally, the FullForm of 2 k I is
Times[Complex[0,2],k].

The issue is not whether something is or is not a single letter. The
issue is whether something has a FullForm whose head is Complex.

That's the way it is. You don't like it. By now everybody knows you
don't like it. But that's the way it is. What's the point of
complaining about it again and again and again and again???

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

Daniel Lichtblau

unread,
Jan 16, 2010, 6:09:38 AM1/16/10
to

"[W]ork for me" (let's try to use correct grammar here).

In[1]:= D[Sin[x], x] /. D -> f
Out[1]= Cos[x]

In[3]:= Exp[I*Pi] /. Pi -> E
Out[3]= -1

In[4]:= Exp[I*Pi] /. I -> E
Out[4]= -1

In[5]:= N[Pi] /. N -> P
Out[5]= 3.14159

In[14]:= Cos[x] + O[x]^2 /. O -> P
Out[14]= SeriesData[x, 0, {1}, 0, 2, 1]

Daniel Lichtblau
Wolfram Research

David Park

unread,
Jan 16, 2010, 6:09:49 AM1/16/10
to
I don't use them but what about displayed LaTeX documents? Can you replace
by typing in what you see? What about a YouTube file? Can you replace one
person with another by using two pictures?

If I type in 2 * 3 * 4 and then try to use 2 -> 5, can I claim that I typed
2 in and I should bloody well be able to replace it? Mathematica is a CAS
and MANY things are processed on input and no longer appear in the for they
were entered. It isn't just Complex[a,b].

It's easy to do calculations in Mathematica. You insist on using a method
that doesn't work because it ignores the fact that Mathematica processes
numbers on input. It's a waste of time. There are more interesting places to
'improve' Mathematica. For example, primed and double primed characters are
commonly used in textbooks and papers, but Mathematica does not make it easy
to use them. (I do provide an easy method to use them in Presentations.)
There are many convenient things that can be done, but I -> -I is just a
dead horse.


From: AES [mailto:sie...@stanford.edu]


In article <hhpl28$9lf$1...@smc.vnet.net>,

AES

unread,
Jan 16, 2010, 6:10:12 AM1/16/10
to
> In article <hhpl28$9lf$1...@smc.vnet.net>,
> Leonid Shifrin <lsh...@gmail.com> wrote:
>
> >
> > 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.


And one or two other responses in this thread have suggested that users
should be given advanced training in the functioning and fine details of
ReplaceAll before they even begin to use Mathematica.

This latter proposal strikes me as a really crazy proposition, and
essentially impossible in the real world.

Suppose an instructor of EE or physics undergraduates in an already
crammed and time-limited introductory network analysis or mechanics
course starts by going through some simple phasor analyses of linear
electric circuits or coupled mechanical systems with one or two
resonances "by hand".

Then, as take-home exercises, the students are asked to analyze and plot
some 3 or 4 or 5-resonance cases using Mathematica and Manipulate (which
can be a very pleasant as well as educational experience) �� but to do
this the students first have to have a training course on Mathematica at
the level suggested above? Not gonna happen.

Or, as a broader approach, suppose that training in Mathematica at this
level is going to be expected or required (before or after admission) of
all incoming college students who might go into any Mathematica-using
field of study, before they can take meaningful courses in that field?
Not gonna happen.

In any case, waking up this morning after reading 60 or 70 posts in this
thread last night I realized that in 20+ years of using Mathematica I've
always had a mental model of ReplaceAll as being essentially an
**editing** tool, rather than a "mathematical" tool (whatever
interpretation you might give to mathematical in that phrase).

When I typed in f = expr /. rule, I expected that rule would be applied
to expr as I originally typed it in -- or, better, to expr as
Mathematica played it back to me in an Output cell when I typed it in
earlier (very hard to argue with this latter interpretation, is it
not?). Only then would that edited version of expr be evaluated and
assigned to f.

Isn't this more or less how the Find and Replace All capabilities
function in every other ordinary software program known to man?

(And isn't it how the construct /. almost always in fact functions,
regardless of what internal shenanigans Mathematica goes through in
processing it?)

And as a final query: Is there a formal name in Mathematica for the
string of characters that one types in and then sees in an Input cell
before (and after) one hits the Enter key? Referring both to this
character string and to the internal representation of this input string
inside Mathematica as an "expression" -- in fact, the same expression --
is certainly a recipe for confusion, in debate and in understanding.

DrMajorBob

unread,
Jan 16, 2010, 6:10:24 AM1/16/10
to
> These capabilities frequently have varied options:
> "Find Next" "Replace and Find" "As Word"
> "Start at Top" "Replace All" "In Selection Only"
> and so on. Many have optional GREP abilities.
>
> So:
>
> 1) Most any computer user at even a very elementary level knows about
> these tools, rather expects to have them available, and expects them to
> function as they in fact do function.

Agreed. WRI's help facility, also, has long suffered (IMHO) from an
unusual concept of what "search" means.

Find within a notebook works more or less as above, but Replace and
ReplaceAll do not. They do a more complicated job, admittedly, but not in
what I'd call a WYSIWYG manner.

A Replace function that works on Graphics internals is hard to imagine
without viewing it in terms of FullForm (or other internal
representation), but the internals of Graphics are not well-documented or
static. I frequently have to actually LOOK at the voluminous FullForm of a
graphic, in order to discover what can be changed.

Bobby

On Fri, 15 Jan 2010 02:20:47 -0600, AES <sie...@stanford.edu> wrote:

> In article <hhpl28$9lf$1...@smc.vnet.net>,
> Leonid Shifrin <lsh...@gmail.com> wrote:
>
>>
>> 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.
>
>

> But on the other hand, innumerable software apps of all varieties and at
> all levels down to the most elementary (e.g., nearly all word
> processors, text editors, graphics programs, spreadsheet programs, email
> programs, and so on) include "Find and Replace" capabilities.
>
> These capabilities frequently have varied options:
> "Find Next" "Replace and Find" "As Word"
> "Start at Top" "Replace All" "In Selection Only"
> and so on. Many have optional GREP abilities.
>
> So:
>
> 1) Most any computer user at even a very elementary level knows about
> these tools, rather expects to have them available, and expects them to
> function as they in fact do function.
>
> 2) In particular, they operate (visibly!) on what you see -- not some
> arcane internal representation.
>
> 3) So, if such a novice user goes to Mathematica, it's only to be
> expected that this user will thnik that Mathematica's ReplaceAll should
> function in a similar fashion (and, helpfully, Mathematic's /. operator
> most of the time does function in that way) (sarcasm mode in that
> parens).
>
> 4) So why can't Mathematica also have a TextReplace[ ] function, or
> something similar, that would function in that way _on what the user
> sees or has typed (or copied and pasted) into a selected cell_.
>
> Given such a function my input would be Find " I " and replace it
> with " (-I) ".
>


--
DrMaj...@yahoo.com

Bill Rowe

unread,
Jan 16, 2010, 6:12:27 AM1/16/10
to
On 1/15/10 at 3:20 AM, sie...@stanford.edu (AES) wrote:

>In article <hhhmkr$o7g$1...@smc.vnet.net>,
>Murray Eisenberg <mur...@math.umass.edu> wrote:

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

>Agreed -- I'd also be extremely cautious in that limit. But I
>behaving differently (AFAIK) from every other single-character
>symbol in the alphabet? (esp. E and Pi)

E and Pi are things with real values. I is a complex. Most other
single-character symbols will typically be things with no
assigned value. These are three distinctly different cases. So,
turn the question around. Why should three distinctly different
cases behave the same?

One can make arguments for or against this particular design
characteristic of Mathematica. But in terms of getting work
done, such discussions are essentially pointless. The most
efficient way to get things done now with Mathematica is simply
to understand how it works and make use of it rather than trying
to force Mathematica to work in a manner different than the way
it was designed.


David Park

unread,
Jan 16, 2010, 6:13:35 AM1/16/10
to
There is a perfectly simple explanation why it doesn't work for I. It's like
saying that because I can calculate a determinant for 2 x 2 and 3 x 3
matrices by adding the products on the diagonals I should be able to do the
same thing with any order matrix and students will be confused if they have
to do otherwise. No, they can just learn how to do it. It's part of their
education. And maybe they shouldn't be taught the limited method in the
first place.

Mathematica represents complex NUMBERS as atomic expressions, Complex[n1,n2]
where n1 and n2 are NUMBERS. It seems to me to be a pretty reasonable design
decision. It makes sense to think of complex numbers as entities in their
own right. Then they used I as a input shortcut, and displayed complex
numbers with \[ImaginaryI] to conform to standard notation. Maybe WRI should
not have allowed I for input or ImaginaryI on display. If everyone had to
type Complex[a,b], and saw it on output, they might not have to learn the
difference between input, display and internal representation. If WRI did
that, I'm sure there would be many more complaints and you would be near the
head of the line.

The other choice would be to do away with the Complex representation
altogether. Then complex NUMBERS would be represented as Plus expressions
and would no longer be number entities in their own right. I don't know what
all the implications of that would be in the Mathematica handling of complex
expressions, but I don't think it would be good. Mathematica would have to
continually parse expressions to recognize complex numbers. For example, how
would Mathematica know to simplify (3+4I)/(1-5I)? It should be able to
simplify it just as easily as 4/2.

When students get to the point where they are treating complex numbers and
functions they can just learn the difference between input and internal
representation. If they can't understand that, I don't see how they can
understand much about complex algebra. And they should long ago have learned
that it is worth while having convenient input forms and output displays.

So don't teach them I -> -I. Teach them Complex[a_,b_] -> Complex[a,-b], or
Conjugate and ComplexExpand. Teach them about complex NUMBERS. It's not that
difficult.


From: AES [mailto:sie...@stanford.edu]


Vince Virgilio

unread,
Jan 16, 2010, 6:13:57 AM1/16/10
to
On Jan 15, 3:20 am, AES <sieg...@stanford.edu> wrote:
> In article <hhpl28$9l...@smc.vnet.net>,
> Leonid Shifrin <lsh...@gmail.com> wrote:
>
>
>
> > I stick to my view of replacement rules as being aimed primarily at adv=

anced
> > users, or at least as a tool that should be used with much care.
>
> But on the other hand, innumerable software apps of all varieties and at
> all levels down to the most elementary (e.g., nearly all word
> processors, text editors, graphics programs, spreadsheet programs, email
> programs, and so on) include "Find and Replace" capabilities.
>
> These capabilities frequently have varied options:
> "Find Next" "Replace and Find" "As Word"
> "Start at Top" "Replace All" "In Selection Only"
> and so on. Many have optional GREP abilities.
>

SNIP

AES,

Nice observation, but it opens a can of worms and potentially quite a
tangent.

I think MS Word's Autocorrect feature throws a wrench in this argument
(Mac who?). Keywords such as '...' or \alpha readily disappear into
their Unicode glyphs. Such "usual (non-arithmetic) conversions"
complicate use of Find/Replace, *requiring closer attention by the
user*. Stronger, I couldn't immediately figure out how to search for
the converted alpha glyph in Word. Mathematica has its own set of
similar complications and cautions.

It's never easy.

Vince Virgilio

(As others have said, there are more expressive and transparent ways
to conjugate an expression, i.e. Conjugate.)

David Park

unread,
Jan 17, 2010, 7:12:17 AM1/17/10
to
Students will never be learning Mathematica early and be reasonably
proficient with it before they get to college? I beg to disagree. It will
happen because as a tool for studying, developing and communicating
technical material Mathematica is orders of magnitude better than existing
practice. Students who don't learn it, and institutions that don't exploit
it will just fall too far behind.

The education problem is a difficult problem to be solved, but it can be
solved and it will be solved one way or another.

Tony, I wish I could convince you to take a more positive approach to
Mathematica. It is not a perfect instrument but through the ages masterworks
have been produced with imperfect instruments. It's shortcomings are not
nearly as important as what you CAN do with it. Nor is it a static
instrument.

The problem for all of us is to keep learning how to use it. It does pay
off.

From: AES [mailto:sie...@stanford.edu]

And one or two other responses in this thread have suggested that users
should be given advanced training in the functioning and fine details of
ReplaceAll before they even begin to use Mathematica.

This latter proposal strikes me as a really crazy proposition, and
essentially impossible in the real world.

Suppose an instructor of EE or physics undergraduates in an already
crammed and time-limited introductory network analysis or mechanics
course starts by going through some simple phasor analyses of linear
electric circuits or coupled mechanical systems with one or two
resonances "by hand".

Then, as take-home exercises, the students are asked to analyze and plot
some 3 or 4 or 5-resonance cases using Mathematica and Manipulate (which

can be a very pleasant as well as educational experience) -- but to do

Richard Fateman

unread,
Jan 17, 2010, 7:13:23 AM1/17/10
to
(con brio, musical notation for With Vigor).

With[{I=-I}, 3+4 I] returns 3-4 I, so clearly this could be used, as
someone mentioned waay back in this thread. Or can it?

Let us try v=3+4I; With[{I=-I},v] returns 3+4I.

oops. and

With[{1/5=OneFifth}, 3/5]

which gives an error message, that says that you can't use 1/5 as a
local variable because it is not a symbol.

It is true that Head[1/5] is Rational, and hence 1/5 is not a symbol.
But Head[I] is Complex, and is not a symbol either, and so should
not be allowed. I suppose one could argue that error message is just
wrong. (but if you care, the explanation is below.)

But here is another one, in which we use E and Pi, each of which is a
Symbol.

With[{E = Pi}, E^x + Exp[x] + E + Cos[E]]

returns

-1 + E^x + Pi + Pi^x

Look at it carefully and see if you agree.

But if we do it in 2 steps,
v= E^x + Exp[x] + E + Cos[E]; With[{E=Pi},v]
then we get.. E + 2*E^x + Cos[E]

Now here's an explanation -- "With" is just a different implementation
of Module with more efficient local variables, and that last expression
is really something like this (we make up local variable name 1234 ..)

Module[{E$1234=Pi}, E$1234^x+Exp[x]+E$1234+Cos[E$1234]]
hence Exp[x] is unchanged..

The second version with v= ...


Module[{E$1235=Pi}, E^x+Exp[x]+E+Cos[E]]

so NOTHING is changed. (returning to I=-I, the name I$1236 is a symbol...)

Anyway, the point here is that even if you think the smoke has cleared,
you might be mistaken.

I think that Mathematica is too complicated to explain accurately to
novices or it should be taught in high school.

On the other hand, pointing out that there are computer programs that
can do parts of symbolic mathematics generally (e.g. algebra, geometry,
trigonometry, calculus) is probably worth mentioning to students who are
keen to understand math, computing, and their relationship.

I heartily disagree with the sentiment that computer algebra or for that
matter, programming, has to be nearly so complicated. To quote
Spiderman (or is it his Uncle Ben??),

"With [sic?!] great power comes great responsibility".

He didn't say "With great power comes great complexity".

RJF

Leonid Shifrin

unread,
Jan 17, 2010, 7:31:08 AM1/17/10
to
Hi Tony,

I feel obliged to reply since your interpretation of those parts of my posts
which you keep citing is not quite what I meant, but I hope that this is my
last post in this thread.

On Sat, Jan 16, 2010 at 3:11 AM, AES <sie...@stanford.edu> wrote:

> > In article <hhpl28$9lf$1...@smc.vnet.net>,


> > Leonid Shifrin <lsh...@gmail.com> wrote:
> >
> > >
> > > 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.
>
>

> And one or two other responses in this thread have suggested that users
> should be given advanced training in the functioning and fine details of
> ReplaceAll before they even begin to use Mathematica.
>
> This latter proposal strikes me as a really crazy proposition, and
> essentially impossible in the real world.
>

I think that the notion of the real world is a moving target, and besides
continuously changing. I don't think most of research and engineering in the
near future will be done like it is now. In particular, the conventional
research process may learn a thing or two from the modern software
development techniques, in terms of making the generated knowledge more
universally accessible and useful to a wider audience than just experts in
that particular field with many years of experience in it. I expect that
tools allowing automation and synthesis will in the near future play no less
important role than tools for specialization.

IMO, in lots of fields more than enough of specialized knowledge has been
generated already. At least in the fields I've been working, the annual
number of new articles increased dramatically since the seventies or
eighties, but very few of these papers can compare in quality with an
average good paper from that period. I think that at least partially this
is a problem of communication between different sub-domains which became
very specialized - resembles to me the Babel tower somewhat. But to
efficiently combine specialized knowledge, you need some common denominator.
I view Mathematica as one of the candidates for tools to be widely used in
this spirit.

So, addressing specifically your statements: indeed, viewed as a tool for
specialization, learning Mathematica on a decent level may seem too much
of a burden since most specific problems require only a fraction of its
power. But I think that in the near future ultra-specialization will be
generally no longer enough for people to stay competitive in whatever they
will be doing, exactly due to the large amounts of potentially useful
knowledge having been already generated in other (sub)fields and waiting to
be utilized. This is only my personal opinion anyway, the time will show
who is right.

Regarding your specific queries about ReplaceAll etc, just two comments:

1. The whole topic of this thread is based on an exceptional situation
(considering auto-evaluation of I and a couple of other symbols), and there
are really just a few of such exceptions, so I don't think it is appropriate
to base general statements on these.

2. For anyone with a decent understanding of Mathematuca pattern-matching
and evaluation, all these things don't pose any problem at all - and these
two topics are not that hard to learn either.

Regards,
Leonid

>
> Suppose an instructor of EE or physics undergraduates in an already
> crammed and time-limited introductory network analysis or mechanics
> course starts by going through some simple phasor analyses of linear
> electric circuits or coupled mechanical systems with one or two
> resonances "by hand".
>
> Then, as take-home exercises, the students are asked to analyze and plot
> some 3 or 4 or 5-resonance cases using Mathematica and Manipulate (which

> can be a very pleasant as well as educational experience), but to do

Richard Fateman

unread,
Jan 18, 2010, 2:35:20 AM1/18/10
to
David Park wrote:
>(teaching of Mathematica....) It will

> happen because as a tool for studying, developing and communicating
> technical material Mathematica is orders of magnitude better than existing
> practice.

I am unaware of any objective evidence that the introduction of any
computer algebra system in any traditional mathematics course results in
a substantial net increase in student achievement.

(Note: anecdotes don't count. I am reminded of)

Should Mathematica or something like it be used as the basis for storing
and retrieving technical material (rather than printing ink on paper),
sure.

But telling professors that Mathematica version 7.0 should be taught
instead of (say) quantum mechanics, won't work. And to tell them that
it should be taught as an EXTRA course won't work. And to tell them
that it will be more useful than some other programming language in
which most of their colleagues' work is written, won't work. And to
tell them that they should write their papers (at some additional
effort) in this new way, and then present them to journals that will
just flatten them out into static page images, probably won't work.

So you might start by trying to reform the publication system.
Convincing a journal to publish papers that can only be fully viewed by
readers who have a computer running Mathematica [which version?] is
a tough sell.

Providing a program disk with a free program to use to view the journal,
(or a free download) might have a better chance. See if you can
convince math societies, or places like NIST (USA), with their DLMF
library. This is tough, and I wish you luck.


RJF

Helen Read

unread,
Jan 18, 2010, 2:35:42 AM1/18/10
to
On 1/17/2010 7:12 AM, David Park wrote:
> Students will never be learning Mathematica early and be reasonably
> proficient with it before they get to college? I beg to disagree. It will
> happen because as a tool for studying, developing and communicating
> technical material Mathematica is orders of magnitude better than existing
> practice. Students who don't learn it, and institutions that don't exploit
> it will just fall too far behind.
>
> The education problem is a difficult problem to be solved, but it can be
> solved and it will be solved one way or another.
>
> Tony, I wish I could convince you to take a more positive approach to
> Mathematica. It is not a perfect instrument but through the ages masterworks
> have been produced with imperfect instruments. It's shortcomings are not
> nearly as important as what you CAN do with it. Nor is it a static
> instrument.
>
> The problem for all of us is to keep learning how to use it. It does pay
> off.

Hear, hear.

My students come into university level Calculus I or II with no
Mathematica experience, and learn to use it in my calculus class while
learning calculus. It really only takes them a couple of weeks at the
beginning of the semester to get up and running, and by the end of the
semester all of my students are quite good at it. I haven't had to take
things out of the curriculum to do this, either; we simply use
Mathematica routinely in our work. Sometimes students come to see me a
year or two or three later, and ask for help putting something they are
working on for some other class into Mathematica. Generally they have a
very good start on it when they come to see me, and need just a little
help with a few details.

--
Helen Read
University of Vermont

Andrzej Kozlowski

unread,
Jan 18, 2010, 2:36:16 AM1/18/10
to

On 17 Jan 2010, at 13:13, Richard Fateman wrote:

> (con brio, musical notation for With Vigor).
>
> With[{I=-I}, 3+4 I] returns 3-4 I, so clearly this could be used, as
> someone mentioned waay back in this thread. Or can it?
>
> Let us try v=3+4I; With[{I=-I},v] returns 3+4I.
>
> oops. and
>
> With[{1/5=OneFifth}, 3/5]
>
> which gives an error message, that says that you can't use 1/5 as a
> local variable because it is not a symbol.
>
> It is true that Head[1/5] is Rational, and hence 1/5 is not a symbol.
> But Head[I] is Complex, and is not a symbol either, and so should
> not be allowed. I suppose one could argue that error message is just
> wrong. (but if you care, the explanation is below.)

Except that this is all completely wrong. Head[I] is indeed Complex but

Head[Unevaluated[I]]

Symbol

And since we have

Attributes[With]

{HoldAll,Protected}

I is never evaluated and is seen as an object with Head Symbol. So
everything works for this reason, the message is quite correct and the
your entire argument is completely off target.

Andrzej Kozlowski


Richard Fateman

unread,
Jan 19, 2010, 5:16:14 AM1/19/10
to
Andrzej Kozlowski wrote:

>
> I is never evaluated and is seen as an object with Head Symbol.

Yes, so that explains why the "error" is not caught and the message
given for that case, too. In fact the "symbol" is converted to
something like I$1234, which was explained in my note. Explaining why a
system behaves in a certain way is not equivalent to proving that it is
correct. At least in my book.

So
> everything works for this reason,

No, as I said,


With[{I=-I}, 3+4 I] returns 3-4 I,

v=3+4I; With[{I=-I},v] returns 3+4I.

You can, of course, say that "this works, we meant to do that, any user
who does not read and understand the full documentation should not use
With, or more generally, should not expect Mathematica to conform to any
particular ordinary beliefs about mathematics except by coincidence".

I explained why, and frankly, the idea that you can (in the technical
sense) lambda-bind numbers, is a novelty. Just as you cannot locally
bind 3 to 4, you should not be able to locally bind I to 4, at least if
I is a constant. That's not a feature, and explaining how it works is
to point out a solution to the puzzle of this buggy behavior, and
perhaps point to a solution. Properly implementing lambda-binding
would be one solution, instead of constructing new names like I$1234
would be one way.

RJF


Richard Fateman

unread,
Jan 19, 2010, 5:16:36 AM1/19/10
to
Do you have any evidence that, taken collectively, the students know
more calculus? Can you show that they do better on the final exam than
students who haven't used computer systems?

Typically the calc teachers I've encountered want to know "what to
leave out to make room" for computer stuff. I tell them to leave out
Logarithmic Derivatives.

Some students like computers because they are neat, and may be
enthusiastic about this aspect of the course (though not all...).

Maybe it is unimportant that they learn calculus at all, and they should
just learn about computers. This would be an important but divisive
claim: i.e. calculus is unimportant; we should require that students
learn computer skills (Mathematica??) instead. Maybe David Park's point
is really somewhere along that spectrum, and we should hold students who
learn Mathematica to a lower standard regarding the traditional
curriculum.

To be clear, I don't object to teaching students about computer algebra
systems. I do so when I get a chance (in computer science courses).
I just am unaware of evidence that it makes them better calculus
students. I don't doubt that a teacher using a computer to do graphics
can enliven a calculus class. And even students doing graphics on their
own (e.g. TI graphing?) can have fun. But can you show they learn more
calculus if they have Mathematica at hand?

RJF


Helen Read wrote:

>
> My students come into university level Calculus I or II with no
> Mathematica experience, and learn to use it in my calculus class while

> learning calculus. ...

Andrzej Kozlowski

unread,
Jan 19, 2010, 5:16:47 AM1/19/10
to

On 18 Jan 2010, at 17:18, Richard Fateman wrote:

> Andrzej Kozlowski wrote:
>
>> I is never evaluated and is seen as an object with Head Symbol.
>

> Yes, so that explains why the "error" is not caught and the message
given for that case, too. In fact the "symbol" is converted to
something like I$1234, which was explained in my note. Explaining why a
system behaves in a certain way is not equivalent to proving that it is
correct. At least in my book.

Of course you did not explain anything at all, or rather what you
explained is wrong. Or perhaps you can explain why there is no renaming
in the first case but there is in the second:

Trace[With[{I = -I}, 3 + 4 I]]

{With[{I=-I},3+4 I],{{I,I},-I,-I},3+4 (-1) I,{4 (-1) I,-4 I},3-4 I,3-4 I}

Trace[Module[{I = -I}, 3 + 4 I]]

{Module[{I=-I},3+4 I],{{I,I},-I,-I},{I$4671=-I,-I},{{{I$4671,-I},4 (-1) I,-4 I},3-4 I,3-4 I},3-4 I}

Guessing wrongly, particularly when one it is easy to check that the guess is wrong, is not the same as explaining.


Andrzej Kozlowski

unread,
Jan 19, 2010, 5:16:58 AM1/19/10
to
And, by the way, any claims to the effect that something like what you
"explained" must be going on in the C source code in which Mathematica
is written do not count for that would be at best pure speculation which
something anyone else can do as well as you .

Andrzej Kozlowski

On 18 Jan 2010, at 18:22, Andrzej Kozlowski wrote:

>
> On 18 Jan 2010, at 17:18, Richard Fateman wrote:
>
>> Andrzej Kozlowski wrote:
>>

>>> I is never evaluated and is seen as an object with Head Symbol.
>>

AES

unread,
Jan 19, 2010, 5:17:08 AM1/19/10
to
In article <hj12vo$bbu$1...@smc.vnet.net>,
Richard Fateman <fat...@cs.berkeley.edu> wrote:

> But telling professors that Mathematica version 7.0 should be taught
> instead of (say) quantum mechanics, won't work. And to tell them that
> it should be taught as an EXTRA course won't work. And to tell them
> that it will be more useful than some other programming language in
> which most of their colleagues' work is written, won't work. And to
> tell them that they should write their papers (at some additional
> effort) in this new way, and then present them to journals that will
> just flatten them out into static page images, probably won't work.

Don't know how long Professor Fateman has been in a major ".edu"
institution, but in my case it's 50+ years. Seen a lot of things come
and go.

And I'd say that every word of the preceding paragraph is absolutely
correct, beyond further discussion.

> So you might start by trying to reform the publication system.
> Convincing a journal to publish papers that can only be fully viewed by
> readers who have a computer running Mathematica [which version?] is
> a tough sell.

Also spent a fair amount of volunteer time myself at upper levels of
major professional societies and dealing with scientific publication
matters over the years; and this paragraph is equally valid.

And there are a lot of other equally compelling reasons why Mathematica
won't be the standard scientific publishing system of the future.

Murray Eisenberg

unread,
Jan 20, 2010, 6:46:40 AM1/20/10
to
It's been some years since I've seen studies comparing performance of
students taking a traditional calculus course, on the one hand, and
those taking a Mathematica-using course, on the other hand. As I
recall, the studies showed the latter group performing at least as well
as the former, and sometimes better, at traditional pen-and-paper
skills. In addition, the latter could solve more complex or more
realistic problems than the former.

You might want to take a look, e.g., at the link to "A guide to the
studies done on the Mathematica-based courses" at matheverywhere.com.
This concerns the "Calculus& Mathematica" project created by Jerry Uhl,
Horacio Porta, and Bill Davis, at University of Illinois and Ohio State
University.

There have been a number of Mathematica-permeated calculus and
post-calculus courses taught over the years. Others you might wish to
look at are:

Calculus, Keith Stroyan, University of Iowa
Interactive Multivariable Calculus, Stroyan also
Differential Equations, Selwyn Hollis,
Armstrong Atlantic State University
Abstract Algebra, Al Hibbard and Ken Levasseur, Central College
and University of Massachusetts/Lowell

There have been presentations about some of these projects at various
Mathematica conferences.

I've based several courses myself upon Mathematica use. Those of us who
do so often just grow tired of trying to justify what we're doing to
those who are dubious or skeptical or just plain ignorant of what's
possible and how. My own experience is that those who don't want to
"believe" simply will not believe. And often they don't want to make
the effort to reconceptualize what it is they're teaching (and why) and how.

>> My students come into university level Calculus I or II with no
>> Mathematica experience, and learn to use it in my calculus class while

>> learning calculus. ...

Richard Fateman

unread,
Jan 20, 2010, 6:47:35 AM1/20/10
to
Andrzej Kozlowski wrote:
> And, by the way, any claims to the effect that something like what you
> "explained" must be going on in the C source code in which Mathematica
> is written do not count for that would be at best pure speculation which
> something anyone else can do as well as you .

No, I also read the documentation:

"Module allows you to set up local variables, to which you can assign
values and then change them. Often, however, all you really need are
local constants, to which you assign a value only once. The Mathematica
With construct allows you to set up such local constants. "

also in the documentation for With, we learn that With is faster than
Module...
Timing[Do[Module[{x = 5}, x;], {10^5}]] is 3X slower than
Timing[Do[With[{x = 5}, x;], {10^5}]].

This is presumably because the local variable x in With has lower
overhead. No extra symbol name etc.

I find Mathematica's "Trace" to be quite useless, myself, so I had to
brace myself to look at what you posted there...

I think that what the Trace reveals is that in the use of "With", the
symbols, which I have said were "something like I$1234" are, indeed,
something like I$1234, but in order to make things less burdensome for
Mathematica, they are not fully instantiated symbols.
This saves on memory allocation/deallocation. It also means that they
print just like "I" and not like "I$1234". But that does not change the
argument that they act like new symbols, local to the body of the With.

Perhaps this example further illustrates the situation:

With[{I=a}, f[I]+g[Complex[0,1]]] which returns f[a]+g[I].

That is, the local variable "I", which according to me becomes a secret
something like I$1234, is unrelated to Complex[0,1] or I, even though
they print exactly the same way.


This totally misses the point of the discussion, which is the illogical
consequences of the current treatment of the symbol I vs. the constant,
which also appears to be compound object as well as having the
appearance of a function -- of Complex[0,1].


RJF

David Park

unread,
Jan 20, 2010, 6:46:29 AM1/20/10
to
Again, I have to strongly disagree with AES and RJF. Active, dynamic
textbooks and papers backed by a good CAS will displace static documents.
They are better for learning, teaching and communication. I will repeat my
arguments again, just so newcomers won't get the wrong impression.


1) Think of Mathematica as a 'piece of paper' on which you are developing,
writing and communicating your technical ideas. Don't think of it as just a
'super graphical calculator' or a 'programming language'. The object is to
learn, or develop and express mathematical ideas in as clear and elegant a
fashion as possible.

2) Mathematica coupled with mathematics is complicated. It really takes long
years of study and practice to get good at it. This would be true of any
comparable medium. How long did it take just to learn how to write
reasonably good English? Learning how to write good technical documents is
even more difficult. Early exposure and practice is essential. It is an
intrinsic problem. There is no easy way around it.

3) Mathematica can't make the big breakthrough until WRI provides a free
Mathematica Player that will allow anyone to read, evaluate and operate
dynamic controls in any Mathematica notebook. (But not edit, and maybe not
print or save.) Users don't write notebooks for communication now because
most other people can't read them. So there are presently very few good
examples. When there are more good examples, more people will be impressed
with them and want to do the same. In my opinion, this issue is more
important than anything else for WRI. (But the licensing and business model
also need critical examination.)

A few other preliminary comments.

It is not obvious or necessarily easy to write good active, dynamic
mathematical documents. People haven't tried to do it much. It is easy to
fall into traps and fill up a notebook with 'computer junk'. There are so
many tools at our disposal that it is difficult to know which ones are best
for a given situation. It is a little like Tufte with data graphics. There
are good and bad ways to do things and we just don't know all the good ways
yet. Also, the very process of trying to present something clearly, using
the new dynamic tools, will often bring us to a deeper understanding of the
subject. "He who makes the graphics often makes the discoveries."

Unfortunately, I think the common present usage of Mathematica is just to
calculate some things and then copy them out to some other document. Then
what would be the use of all the dynamic features, other than our own
pleasure? (And AES recommends that WRI drop all these features and stick to
basic CAS.) I'm trying to convince more people to go beyond that restricted
usage. Of course, the main reason we have the restricted usage is that most
other people can't read the notebooks.

How should such notebooks be written? They should have structured sections
(with group openers) and otherwise look like classical technical papers.
They will probably contain a Routines section where developed routines are
placed. Everything should be actively calculated. If it sounds too
difficult, try anyway.

Now, why do I say that active, dynamic mathematical documents are orders of
magnitude better than the present static documents? Here are the reasons:

1) Embedded knowledge. Good notebooks can generate embedded knowledge:
active usable definitions that result from derivations. This embedded
knowledge can then be used within the notebook itself, in extended
applications in other notebooks and can form the basis for writing a general
purpose package. This is some of the principal fruit of your labor. Don't
let it slip through your fingers. (I will discuss how to better organize
this below.)

2) Actions are better than static presentations. It is always easier to
understand an action than a static diagram or a set of static equations.
Animations can be used to show what is being changed and how it affects a
derivation. A Step by step derivation using rules is something like an
animation as it shows exactly what principles or identities or substitutions
are required to advance an argument and exactly what effect they have.

3) Self-proofing. An active Mathematica notebook is to a large extent
self-proofing. Cells that contain typographical errors generally will not
evaluate properly or often not evaluate at all. Equations that are nonsense
will similarly fail. All of the elements necessary to a derivation must be
present and explicit. It is certainly still possible to make errors or
muddled arguments but not nearly as easy as without active mathematics.

4) Integrated graphics and presentations. The active mathematics can be
integrated with the graphics and dynamic presentations. That is, the
definitions and embedded knowledge developed in the notebook is used to draw
the graphical elements. This not only makes the presentations easier, but
the graphics can also validate the mathematics and may often be the first
indication of errors.

One can go even further and organize work into applications using
Workbench/DocuTools. This could be used for 1) Writing a book, 2) Setting up
college course material, 3) a research project, 4) a study project. An
application could contain 'finished' work: a package, documentation and
notebooks (chapters, lessons or papers), and a Workbooks (say) folder that
contained working notebooks where most day to day work would be done. This
is a very good way to organize and preserve work.

AES and RJF look for flaws in Mathematica (and certainly it's worthwhile to
have skeptics and critics) but what about flaws in present practices? There
are plenty of them and they are glaring. What about all the typos and errors
in printed texts and papers? What about being referred to an equation in a
previous chapter, which is difficult to find, and then this just refers to
another previous equation? Reading some books is like being a real estate
lawyer doing a title search! Why not reprint the equation? Oh, they wouldn't
want to waste some paper and ink. With a notebook you could recall the
equation (by bringing it up at the place where it is used, not by jumping
out of place.) Suppose you are asking a student to do derivations using
axioms. You could bring up all the axioms in a separate window whenever and
wherever you needed them. Better yet, you could have the axioms in active
form so a student could apply them in seeing how derivations are done. Texts
often have skipped steps that can cause students immense aggravation and
loss of time. What about proofs or derivations that run on for a number of
pages and which must be presented in a serial manner? With a notebook one
can organize an extended proof in a compact space, and in a structure that
follows the structure of the proof. Then one can look at the individual
parts by clicking buttons, or bring up parts of the proof in separate
windows. What about the restrictions and artifacts of a fixed length printed
page? Putting content aside and just considering form, I think it's fair to
say that static printed documents are generally chock full of deficiencies
that are significant impediments to communication.

Now to your questions and objections.

I readily admit that there are HUGE problems to solve to make these ideas
work. (Universal ability to read notebooks, early training, preparation of
adequate material.) That doesn't mean it wouldn't be worth it.

I don't know of any studies to test if this will work. I doubt if any such
test has been done. I don't know how one could set up such a test without
the preconditions above.

I don't think that a professor should be told to teach Mathematica instead
of quantum mechanics. Unfortunately, that is what happens now! My point is
that students should know Mathematica BEFORE they take the quantum mechanics
course.

An Extra course might help, in freshman year. But students with a potential
for a technical career should be introduced to Mathematica in secondary
school.

When active and dynamic Mathematica notebooks can be freely read,
researchers WILL write their papers as notebooks (or applications). They
want to sell their ideas and they can do that much better with active,
dynamic notebook papers. Printed journals have the same future as
newspapers. They will eventually fade away. More and more people take papers
from the Internet. I don't even have access to a technical library. The only
journal I look at is Science, which the local library carries. (I used to
sometimes visit the NIST library in Maryland, which is not too far away, but
since 9/11 it is closed to ordinary American citizens.) So I don't give a
damn about the printed journals; they're useless to me.

I wouldn't attempt to convince printed journals to accept Mathematica
notebooks. The journals are way too expensive, too slow, and way outdated.
The only thing they offer is a 'stamp of approval' and that isn't worth
much. The real scientific world is much more lively.


From: AES [mailto:sie...@stanford.edu]

In article <hj12vo$bbu$1...@smc.vnet.net>,
Richard Fateman <fat...@cs.berkeley.edu> wrote:

> But telling professors that Mathematica version 7.0 should be taught
> instead of (say) quantum mechanics, won't work. And to tell them that
> it should be taught as an EXTRA course won't work. And to tell them
> that it will be more useful than some other programming language in
> which most of their colleagues' work is written, won't work. And to
> tell them that they should write their papers (at some additional
> effort) in this new way, and then present them to journals that will
> just flatten them out into static page images, probably won't work.

Don't know how long Professor Fateman has been in a major ".edu"

institution, but in my case it's 50+ years. Seen a lot of things come
and go.

And I'd say that every word of the preceding paragraph is absolutely
correct, beyond further discussion.

> So you might start by trying to reform the publication system.

> Convincing a journal to publish papers that can only be fully viewed by
> readers who have a computer running Mathematica [which version?] is
> a tough sell.

Also spent a fair amount of volunteer time myself at upper levels of

Richard Fateman

unread,
Jan 21, 2010, 4:50:39 AM1/21/10
to
Murray Eisenberg wrote:
> It's been some years since I've seen studies comparing performance of
> students taking a traditional calculus course, on the one hand, and
> those taking a Mathematica-using course, on the other hand. As I
> recall, the studies showed the latter group performing at least as well
> as the former, and sometimes better, at traditional pen-and-paper
> skills.

Rather than looking at all the material you suggest, I will take your
word for it, since it generally agrees with what I recall. What I
recall is that, essentially, the group of students using computers did,
on the whole, substantially the same as the students not doing so.

In addition, the latter could solve more complex or more
> realistic problems than the former.

This would be an interesting consequence (did they use the computer to
solve more complex problems?) I can see it either way -- a student who
has more confidence and has seen problems solved where the answer did
not magically drop out and become some remarkably simple expression --
may be more willing to attempt to attack a more ambitious realistic problem.

Often calculus students (indeed, I recall a graduate course in applied
math where this was true) could guess that any time the solution of a
homework problem required a large expression or a number with more than
3 digits, that he/she had made a blunder somewhere. The right answer in
the back of the book was always small.


>
> You might want to take a look, e.g., at the link to "A guide to the
> studies done on the Mathematica-based courses" at matheverywhere.com.
> This concerns the "Calculus& Mathematica" project created by Jerry Uhl,
> Horacio Porta, and Bill Davis, at University of Illinois and Ohio State
> University.

The success of such courses obviously depend on the enthusiasm, energy,
and charisma of the teachers. To what extent does it depend on the
computing aspect?
In the case of this particular link, this leads to a business, where the
professors are apparently selling courseware. I'm not saying this is a
bad thing. Just that I would not expect statements on that web site to
present nuanced opinions on pro/con teaching math with computers :)
>
.. snip..

> I've based several courses myself upon Mathematica use. Those of us who
> do so often just grow tired of trying to justify what we're doing to
> those who are dubious or skeptical or just plain ignorant of what's
> possible and how.

I haven't been in the business of teaching calculus for a long time. (I
taught math at MIT before I taught computer science at Berkeley). My
experience is that math teachers are, on the whole, quite conservative.
My own calculus lab (this was in 1971-2) was dropped when I was not
available to teach it. I used a computer algebra system, obviously not
Mathematica.

In the absence of a controlled experiment, it is hard to convince
skeptics. Even the experiments that might be tried would probably be
flawed -- e.g. two sections of the same course -- may be defective if
the better students self-select to come to the "experimental
computer-based" course. What we would like, I think, is some mechanical,
automatic, guaranteed-to-win, technique (computer based or not!) that
would take all students, including below average, and get them to have a
superior understanding and appreciation of mathematics. If someone
could convincingly show that using Mathematica (or anything else) was a
sure-fire mechanism, then people in charge of schools who are in a
position to hire/fire teachers, might take notice.

There have been period efforts to improve education. e.g. I participated
in conferences on "Calculus for the New Century". (uh, I think that
was the previous one!).. Using graphing calculators -- still a big
sell -- was one innovation.

I personally don't doubt the efficacy of using computers to actually DO
calculus problems. I also suspect that by far the most lucrative sales
of programs like Mathematica are to schools to make them available for
courses like calculus, for those semesters in which someone uses them
(perhaps for an additional calculus lab.).
But do students learn more? Note that most calculus students just want
to pass the course so they can graduate and never use calculus for
anything -- so they do not really want to learn "more" than necessary :) .

Calculus is not the only course, though if you are selling educational
software, it is probably the biggie (or maybe pre-calc, but that's not
so much fun and often remedial).

I would like to believe that my colleagues who teach engineering of
various sorts would see computer algebra systems as more or less
essential tools in their fields, and would feel an obligation to make
room in the curriculum for the teaching of such software. While I do not
have the 50 years of experience of AES, I do have 35+ years of
experience in a similar situation. Maybe an occasional guest lecture is
the best I could do. I suspect the engineering (undergraduate)
curriculum is even less prone to experimentation than math.

One article I have read on using computers to teach math (modern
algebra, not calc.) included a study on whether students learned more
(with or without computers). Observations: students stopped learning
the computer aspects when they realized the final exam was going to be
held in a room without computers. On the final exam, the students
with/without computers did about the same.

The authors conclude (with a straight face..) that more money should be
spent on developing the computer programs so that they would be more
successful.

Good luck.

RJF

Richard Fateman

unread,
Jan 21, 2010, 4:51:13 AM1/21/10
to
David Park wrote:
> Again, I have to strongly disagree with AES and RJF.
You are entitled to. AES says he has 50 years of experience; I have 35+.

Active, dynamic
> textbooks and papers backed by a good CAS will displace static documents.
> They are better for learning, teaching and communication. I will repeat my
> arguments again,

.. arguments snipped out...

>
> AES and RJF look for flaws in Mathematica (and certainly it's worthwhile to
> have skeptics and critics) but what about flaws in present practices?

The problems of adoption of software as you advocate are NOT especially
dependent on the problems or flaws that we point out. Indeed, most
people who fail to adopt this software are not even aware of these
flaws, but simply say the programs are too expensive and would require
additional time to learn or teach, or would take extra time in courses
to teach, and would require extra people, and how about the cost of
computer labs, and anyway I'm too old to learn a new program, etc.


> There
> are plenty of them and they are glaring.

Which makes you wonder if anyone reads them, and furthermore why would
anyone care if they had computer programs-- they might be buggy and no
one would know either??


.. more snip...

of explanations of why David Park is advocating nice things.

>
> Now to your questions and objections.
>
> I readily admit that there are HUGE problems to solve to make these ideas
> work. (Universal ability to read notebooks, early training, preparation of
> adequate material.) That doesn't mean it wouldn't be worth it.

I think there are lots of possibilities for long-term improvement of
education that will not happen because of short-term inhibition. I
think there are even more specifically for Mathematica.


>
> I don't know of any studies to test if this will work. I doubt if any such
> test has been done. I don't know how one could set up such a test without
> the preconditions above.

See Murray Eisenberg's note.


>
> I don't think that a professor should be told to teach Mathematica instead
> of quantum mechanics. Unfortunately, that is what happens now! My point is
> that students should know Mathematica BEFORE they take the quantum mechanics
> course.

There are lots of things that students SHOULD know that they don't
(about alcohol, drugs, music, sex.) Mathematica per se is WAY down the list.

>
> An Extra course might help, in freshman year. But students with a potential
> for a technical career should be introduced to Mathematica in secondary
> school.

I cannot see this happening, even if you substitute "computer algebra
system" for the word "Mathematica"


> I wouldn't attempt to convince printed journals to accept Mathematica
> notebooks.

If I encounter a reference to on-line Mathematica notebook that purports
to be a technical contribution on a subject of interest to me, I will
generally NOT read it via Mathematica. I will instead look for a PDF or
other static presentation. And I HAVE Mathematica at my disposal.

So far as I can recall, I've downloaded a .nb only ONCE, and I didn't
run it to the end.

Off the top of my head, here are some of the problems.

1. I want to read the deliberately extracted, summarized, and
carefully- written exposition of the subject matter. I want to read it
in a linear fashion, not with out-of-sequence links to references or
footnotes or programs. Good technical science writing is a skill,
though now much in decline, and peppering a document with links is no
substitute.

2. Programs generally are hard to read. They are especially hard to read
when they are poorly written, which is most of the time. If I want to
see them, I am willing to look for them.
If the point of the paper is "look at the programs" and the programs are
polished, that is a different paper than one that says "look at the
math." It is sort of like a fine dinner, where there are some delectable
items on the plate. You don't ordinarily welcome (on the same plate)
evidence that the animal you are eating was grass fed -- here is its
stomach --.


3. I would be willing, as a teacher, to consider a textbook-like online
object with computer links, but I would first seek some evidence that
this was an excellently-composed object, by an authoritative and skilled
expositor. (e.g. reviewed by a reputable person). I would be eager, as
a researcher, to find such an object which was a reference book and also
was interactive. There are probably some such worthy books
(Zwillinger's Differential Equations comes to mind.)

While it might help to have tools such as those promoted by David Park
(or WRI), it is by no means an assurance of quality. The presence of a
".nb" after a file name is no assurance that the contents of the file is
worthwhile. And if one returns to the notion that .nb implies
Mathematica [some version or other] and its notable flaws at least to
date, the .nb notation is almost a guarantee of some "gotchas" and hence
I would especially avoid .nb objects, and most especially on topics of
numerical analysis, where the design flaws are, in my opinion, so
fundamental. Example (mathematica 7.0):
{x >= 1, x > 1, x > 0, x}
evaluates to
{True, False, False, 0.}

can you construct x?

RJF


One possible answer, below....


x=0``-.5

AES

unread,
Jan 21, 2010, 4:56:46 AM1/21/10
to
In article <hj40q4$sgk$1...@smc.vnet.net>,
Richard Fateman <fat...@cs.berkeley.edu> wrote:

> But can you show they learn more
> calculus if they have Mathematica at hand?

Speaking only for myself (and noting that my calculus-learning days are
far in the past, and that I'm not at all sure what the operational
meaning of "learn more calculus" might be), I can only say that having
Mathematica at hand whenever I'm doing any kind of "maths" �� whether
it's learning more about some familiar or new mathematical topic, or
trying to solve some real problem using math �� certainly enables me to
gain immensely more insight and/or intuition into what the symbols on
the paper mean, or how the mathematically described system of interest
will actually behave. Mathematica can really be "insanely great" at
helping do that, and I'm grateful for it.

But it's Mathematica that's the "tool" for producing results here, and
the conventional mathematical symbols as conventionally written on paper
and the real physical systems that are the important realities �� the
things that most of us want to concentrate on �� not the arcane and
sometimes inconsistent or even bizarre innards of Mathematica.

Which is why it's so egregious and some of us so unsympathetic when
attempts to apply Mathematica to some conventional mathematical input in
what would seem a sensible and consistent fashion instead trigger some
arcane Mathematica "gotcha"; and Mathematica acolytes then try to
convince us that, hey, that's the way Mathematica works, and we must
therefore accept it as near divinely inspired, and focus unlimited
energies on learning the arcane (and often very ill-documented) details
of what Mathematica does, not the tasks we want to accomplish with it.

Mathematica is a _commercial tool_, not a divinely endowed
accomplishment of human creativity before which we must all bow down
(and that remains true not withstanding the large amount of great human
creativity that has obviously gone into developing it).

Andrzej Kozlowski

unread,
Jan 21, 2010, 4:57:18 AM1/21/10
to

On 20 Jan 2010, at 12:46, David Park wrote:

> Printed journals have the same future as
> newspapers. They will eventually fade away.

And not only journals but also the people who edit them and publish in
them and even write post about how it should be done. And that is
certain.

Andrzej Kozlowski

It is loading more messages.
0 new messages