MathGroup Archive 2010

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

Search the Archive

Re: Replacement Rule with Sqrt in denominator. Also Bug in Series

  • To: mathgroup at
  • Subject: [mg114652] Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
  • From: Richard Fateman <fateman at>
  • Date: Sun, 12 Dec 2010 05:40:15 -0500 (EST)
  • References: <idv78i$t4l$>

On 12/10/2010 10:55 PM, Bill Rowe wrote:
> With respect to replacement rules or any other behavior of
> Mathematica you have a pretty limited choice for solving problems.
> You can:
> 1) use different functions in Mathematica and ignore the
> behavior you don't care for or don't want to take the time to
> understand more thoroughly.
> 2) you can dig into the operation of the function until you do
> understand how it behaves and can use it effectively
> 3) you can use something other than Mathematica to solve the problem.

4.  You can request that the tool be modified by the vendor.  The vendor
will almost certainly do this if there is enough money at stake.

5. You can build you own tools (after all, Mathematica is programmable).
This is what I suggest in my paper, and which is done in a much more
elaborate fashion by Harris' Semantica program.

6. You can ask another person to write a suitable tool. (E.g. a student
who can get credit for designing/writing/testing a program.)

> There really isn't any other useful choice in terms of getting a
> problem solved.
> With respect to 2) above and replacement rules, it is not
> correct to say the behavior is undocumented.

Um, some of it is documented. Some of it is not documented.
Try to find discussion of "raw objects" that are not handled by matching.
There is also the contradiction that if Rational[] is an atom,
how can it be decomposed via the pattern Rational[n_,m_]?

  Most of the posters
> here are not WRI employees and have no access to the source
> code. All they have access to is the same documentation you have
> access to.

You give the documentation too much credit.  Most of the posters also 
have access to the program, and they determine its behavior by trial
and error.  I certainly do.

  And since it is clear some users do understand the
> behavior of replacement rules it cannot be true the behavior is undocumente
> d.

There's lots of stuff that does not come with documentation, and
yet people eventually understand the behavior, more or less.


>. For myself, I generally choose
> option 2). The payoff for option 2) is as I increase my
> understanding of how Mathematica behaves in some specific case,
> I find I have more confidence in the results I get and I am
> better able to predict behavior for other problems. In this
> respect, Mathematica is like any other complex tool. The better
> you understand a tool, the more effectively you can apply that
> tool to a new problem.

For some tools, yes.  But programs are different from (say) chainsaws
in a very important respect.  A chainsaw is a physical object that
is fundamentally limited by its physical properties. A purchaser of
a chainsaw probably cannot use it as (for example) a belt sander,
or a bicycle, or a water pump.


Software in a general-purpose programmable language running on a
digital computer with sufficient memory etc is almost infinitely
mutable into other software. If you are sufficiently clever,
you can change it: you can write a Lisp system in Mathematica,
or vice versa.  For you to say that you have to learn to use it
as is, is to deny the nature of software.

E.g. "Semantica" tried to fix the matching in Mathematica.


  • Prev by Date: Re: Replacement Rule with Sqrt in denominator
  • Next by Date: Re: On the foundation of Mathematica, was Re: Foo /: Plus[b_Foo] := b
  • Previous by thread: Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
  • Next by thread: Re: Replacement Rule with Sqrt in denominator. Also Bug in Series