Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
- To: mathgroup at smc.vnet.net
- Subject: [mg114691] Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
- From: Bill Rowe <readnews at sbcglobal.net>
- Date: Mon, 13 Dec 2010 03:52:05 -0500 (EST)
On 12/12/10 at 5:40 AM, fateman at cs.berkeley.edu (Richard Fateman) wrote: >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.) Your 4) and 6) aren't very effective techniques for solving problems. As for 5), it is what I had in mind with my 2). I had not meant by 2) that you are limited to built-in functions even though I can see the way I wrote it could be construed that way. >>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. I also use "trial and error". But those "trials" are guided by the documentation and are of the nature of understanding what the documentation is saying. To me, this kind of "trial and error" is expected with any software as complex as Mathematica. >>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. You seem to have rather extreme interpretations of my remarks. I really don't see how anything I said can be taken to "deny the nature of software". Yes, physical tools are different than software. Yes, I can view Mathematica as a general purpose programming environment and use it to create any other software I care to use. Of course, while it may be technically possible to create something that looks and behaves like say Microsoft's Excel using Mathematica, the end result is unlikely to be worth the time and effort needed to achieve it. There are more efficient ways to achieve such a result. The only point I was attempting to make about learning Mathematica "as it is", is that doing so enables you to more efficiently create other things with it. Create the functions needed to solve a problem or to use the existing functions to solve a problem.