Re: Replacement Rule with Sqrt in denominator
- To: mathgroup at smc.vnet.net
- Subject: [mg114476] Re: Replacement Rule with Sqrt in denominator
- From: Richard Fateman <fateman at cs.berkeley.edu>
- Date: Sun, 5 Dec 2010 21:52:49 -0500 (EST)
- References: <idd7q5$ne9$1@smc.vnet.net>
On 12/4/2010 3:14 AM, Bill Rowe wrote: > On 12/3/10 at 5:19 AM, fateman at cs.berkeley.edu (Richard Fateman) > wrote: > >> Anyway, I would rather have the CAS do some simple guessing of what >> I mean, as at least a fair trade for me having to guess what secret >> things will happen in FullSimplify or Integrate or Solve, or ... >> especially as versions change. > > I definitely do not want Mathematica to do any guessing as to > what I mean. I was speaking loosely here; obviously Mathematica should be deterministic (well, no less deterministic than it already is). > I very strongly dislike software that behaves in > that manner. This leads to unpredictability and often > significant difficulty in stopping the "guessing" to have > exactly what I inputed executed as I want. Word is a good > example of software that implements this "guessing" which is one > reason I very much dislike Word. Microsoft (etc) would probably call this activity, done on behalf of the user, as "user-friendly interface", which I (and now you) refer to as guessing. > > I also see a very significant difference between how replacement > rules operate and changes in things like FullSimplify, > Integrate, Solve ... These functions are not "guessing" as to > what I want. Yes, they involve complex algorithms that may > change from version to version and may mean results change from > version to version. You miss my point. It is unfortunately necessary for the human to guess what these programs do. I write a program, and it no longer works. Why? Because Solve or Reduce has changed, and I have to guess why, and do some testing. > Unlike these functions, operation of > replacement rules is truly easy to predict once you realize the > operate on the FullForm of an expression. Obviously not for DanL or for me, at least when we try something a little out of the ordinary. > There is no ambiguity. Actually, there is some ambiguity about order in which things are done or matched. > And since replacement is a literal replacement, the behavior is > consistent from version to version. I disagree, since predicates are part of matching and the predicates can depend on anything in Mathematica, including things that change in version "updates". > >> Basically, explaining a bug does not make it into a feature, > > When an aspect of software works as designed it is inappropriate > to refer to that aspect as a bug. OK, I say "Dressing up a bug as a feature does not fix the bug." You say, in effect, If a designer writes a program that does exactly what the designer intended, then it is not a bug. OK, then, what term do you wish to use to refer to the result of design and programming that results from an error in the design that causes mathematical computations to proceed in a way that is internally inconsistent, and is generally considered mathematical nonsense? A feature? I would call it a bug (in the design). And I think I am being generous. > The fact replacement rules > operate on the FullForm of an expression but what is displayed > is not the FullForm does mean inexperienced users of Mathematica > will encounter some difficulties with replacement rules. But, > that simply doesn't equate to being a bug. No, I think the error is that users need to have another kind of pattern matching, and that when too many people stumble over the same feature, the correct response is NOT, "the customer is wrong, yet again." It might be , Oh, you want the semantic pattern matcher. Maybe, Here's how we can set it up to be your default command pattern matcher... RJF > >