[Date Index] [Thread Index] [Author Index]

Re: Re: More /.{I->-1} craziness

• To: mathgroup at smc.vnet.net
• Subject: [mg106249] Re: [mg106203] Re: More /.{I->-1} craziness
• From: Richard Fateman <fateman at cs.berkeley.edu>
• Date: Wed, 6 Jan 2010 05:59:40 -0500 (EST)
• References: <200912300915.EAA17299@smc.vnet.net> <hhhmn8$o9t$1@smc.vnet.net> <hhkjc4$5ag$1@smc.vnet.net> <hhpl4j$9mf$1@smc.vnet.net> <421988.1262677154744.JavaMail.root@n11> <005001ca8e15$766e7bd0$634b7370$@net>

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.



>
> David Park
> djmpark at comcast.net
> http://home.comcast.net/~djmpark/  
>
>
> From: Richard Fateman [mailto:fateman at 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
>
>
>