Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
- To: mathgroup at smc.vnet.net
- Subject: [mg114657] Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
- From: Bill Rowe <readnews at sbcglobal.net>
- Date: Sun, 12 Dec 2010 05:41:11 -0500 (EST)
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? Several posters who work for WRI have stated the behavior is not a bug and the behavior is consistent with 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. 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. 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. So, your belief the changes needed to implement what you would prefer to see as the behavior of replacement rules has no factual support. >>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. 3+4I/.I->-1 yields 3+4I for the same reason 2.345/.2->1 yields 2.345. 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. 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. 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. 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. >>Not at all. I make no claim changes are unthinkable. Mathematica >>has changed many times from version to version and will undoubtedly >>do so in future versions. Some of those changes will be ones I like >>while others will be ones I dislike for one reason or another. But >>I do understand my like/dislike of any past change or future change >>in no way determines whether those changes are "bugs" or design >>errors. >It should be obvious to anyone that one determinant in whether some >change in a program is a "bug" or not is whether users dislike those >changes. It is not the only factor, but to say that your view "in >no way determines...[bughood]" is something that you, and perhaps >others, should reconsider. >Would you feel the same way about the provider of any other good or >service -- that the brewer's new beer formulation must be better >because he says so, even if you dislike it? That the car steers >better because the manufacturer says so? etc. etc. 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. But my dislike of one brewer's formulation doesn't equate to that formulation being a design error/flaw or bug. In the same fashion, a users dislike of some behavior in Mathematica in no way makes that behavior a bug or design error. If there are enough users that want the behavior changed, then possibly WRI will implement the change. 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. 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. 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.