Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
- To: mathgroup at smc.vnet.net
- Subject: [mg114687] Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
- From: Richard Fateman <fateman at cs.berkeley.edu>
- Date: Mon, 13 Dec 2010 03:51:21 -0500 (EST)
- References: <ie28s3$mk0$1@smc.vnet.net>
On 12/12/2010 2:41 AM, Bill Rowe wrote: > On 12/11/10 at 1:52 AM, fateman at cs.berkeley.edu (Richard Fateman) > wrote: > >> On 12/9/2010 11:31 PM, Bill Rowe wrote: > >>> (Bill) No. I merely claim the current behavior of replacement rules >>> is not a bug or a design error. > >> On what basis do you make this claim? > > (Bill) Several posters who work for WRI have stated the behavior is not > a bug and the behavior is consistent with the documentation. I have said that too. That WRI says "[we] meant to do that". That does not, however, mean they are correct. All it means is that do not have a stated current intention to change the program or the documentation. > >>> I don't have access to the source code and simply do not know what it >>> would take to implement the changes > >> Neither do I. But I believe that for a careful design, the changes >> would be minor. I have access to the source code for a similar >> program. > > Access to the source code of a similar program cannot tell you > how easy/difficult something is to implement in Mathematica. Sure it can. Not in all cases, but in some cases the requirements of a program provide a fairly clear basis on which to design an implementation. There are several open-source pattern match programs similar to Mathematica's (e.g. mine, Kevin McIsaac's http://www.reduce-algebra.com/docs/pm.pdf, matheclipse, ...) > You've no basis for assuming the code in Mathematica is > partitioned in the same manner, uses the same approaches etc as > your similar program. Actually, you are wrong. There is a basis for assuming the code is similar. (a) Its behavior (including misfeatures) is predictable based on some assumptions of similarity. (b) Sometimes there are not really so many reasonable ways of doing something. > All access to source code for a similar > program does is tell you how easy it would be to change that > similar program, not Mathematica. Again, wrong. > So, your belief the changes > needed to implement what you would prefer to see as the behavior > of replacement rules has no factual support. In your opinion, but you are being mislead by your incorrect assumptions. > >>> you would like or what impact it might have on other parts of >>> Mathematica. > >> I find it hard to believe that any part of Mathematica REQUIRES the >> behavior that 3+4I /. I->-I result in 3+4I unchanged but 3+bI /. >> I->-I result in 3+bI > >> What do you think? > > The current design requires this behavior. No, the program simply implements the design. Do you think there is a program already in existence [not written for illustrating this bug/feature] that relies on this behavior to get a correct answer? 3+4I/.I->-1 yields > 3+4I for the same reason 2.345/.2->1 yields 2.345. 2.345/.2->1 does not yield 2.345. It yields 11.725 -> 1 And for an entirely different reason, which is that Mathematica parser requires a space after "/." when the next token is a number. Personally, I would have no problem if Mathematica implemented "2.345" /. "2"->"1" to yield "1.345" instead it requires StringReplace["2.345", "2" -> "1"] so the "reason" your (repaired) example doesn't work is that the example doesn't indicate to the system that you are apparently concerned with the character representation of "2.345" not its numerical value, which has many possible representations, and internally it is presumably a binary number of some sort, and as a binary number it does not have any "2" in it. That is, > despite the way it appears on screen, to Mathematica 3+4I is a > single entity with no parts. You can replace the entire entity > but not part of it. Well, is that a good thing or a bad thing? Does it HAVE to be that way? > > In contrast a+b*I is an expression with constituent parts that > can be operated on by replacement rules. The fact that 3+4I and > a+b*I get displayed in the same manner does not make these the same. Again, it doesn't have to be that way. Not every computer algebra system has the same restrictions. > > Now, I agree, the current design of Mathematica is not > immutable. And for some a change in the design might be highly > desirable. But I don't know how difficult such a change would be > or what the impact of such a change would be. It seems to me that we are discussing what the impact of such a change would be. I say it would be beneficial. You seem to have claimed either it shouldn't be done, or can't be done. Now you are claiming that you don't know what the impact would be. So now you have no opinion? > However, it does > seem to me making changes to the representation of complex > numbers so that replacement rules could work as you seem to want > isn't likely to be a minor change. Why do you think it requires a change in the representation? As I have said previously, the change could be made in ReplaceAll and ReplaceAllDelayed. It is, I think, not too hard to change (vanishingly rare) case of "expression is Complex" + "pattern is number" from "DONT DO IT" to "DO IT". I say this, once again, from having written such a program. You seem to think it would be somehow wrong based on not "know[ing] how difficult such a change would be". .. snip.. > If the brewer's new beer formulation wasn't to my liking, I > wouldn't buy it again from him. Instead I would get beer from > another brewer. It is a harder to change from one software system to another, than to choose a different beer, at least in most countries. Imagine if there were only one brand of beer. > But my dislike of one brewer's formulation > doesn't equate to that formulation being a design error/flaw or bug. Tell that to the people who designed "New Coke" http://en.wikipedia.org/wiki/New_Coke > > In the same fashion, a users dislike of some behavior in > Mathematica in no way makes that behavior a bug or design error. no, it does make it an error, in some way. > If there are enough users that want the behavior changed, then > possibly WRI will implement the change. well, it could be enough users, or a strong enough argument, which would include "it does not harm anyone and makes the system easier to document". If WRI becomes totally > unresponsive to users, then there is opportunity for competitors > to WRI. Eventually, being totally unresponsive to your user base > will mean you have no users. Really? Consider industrial monopolies. Consider totalitarian regimes. Consider software operating system "lock-ins". > > My experience is software developers react much better to > reasoned requests for changes then they do claims behavior that > is precisely as they intended is a bug and must be changed. Oh, so now you want me to be polite. That costs extra. > In > fact, repeated claims of such behavior being a bug tends to get > the same response as outlined in the parable of the boy who > cried "Wolf" when there was none. Except, of course, I've reported plenty of acknowledged bugs, and whether (whatever you are defending) is a bug or not, has been raised, repeatedly, by various posters. RJF