Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
- To: mathgroup at smc.vnet.net
- Subject: [mg114652] Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
- From: Richard Fateman <fateman at cs.berkeley.edu>
- Date: Sun, 12 Dec 2010 05:40:15 -0500 (EST)
- References: <idv78i$t4l$1@smc.vnet.net>
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. BUT 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. RJF