Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
- To: mathgroup at smc.vnet.net
- Subject: [mg114617] Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
- From: Bill Rowe <readnews at sbcglobal.net>
- Date: Fri, 10 Dec 2010 02:31:13 -0500 (EST)
On 12/9/10 at 6:01 AM, fateman at cs.berkeley.edu (Richard Fateman) wrote: >On 12/8/2010 3:40 AM, Bill Rowe wrote: >>On 12/7/10 at 6:45 AM, fateman at cs.berkeley.edu (Richard Fateman) >>wrote: >>>On 12/6/2010 3:14 AM, Bill Rowe wrote: ... >>>>I don't agree the behavior of replacement rules reflects an error >>>>in design. >>>Aha, but you don't answer the question. Let us say that the >>>designer put in something you truly thought was wrong, for example >>>the designer truly thought that Cot[x] could be simplified to >>>1/x*Tan[x]. >> >>>If this is not a bug, perhaps you would call it a BLUNDER? >>This is a meaningless strawman of your own making which has no >>bearing on the discussion. >OK, you want some examples that have occurred, and whose resolution >has changed, from version to version of Mathematica? How would you >characterize a situation in which version N replies True but version >N+1 replies False? Did version N+1 fix a bug? a blunder? or exhibit >just some chronologico-mathematical time warp? >If you want to argue about such things, just look at the brouhaha >regarding whether sqrt(x^2) is abs(x), or the difference between >0^0 and 0.0^0.0 . or whether integral of x^n is 1/(n+1)*x^(n+1), >which is arguably false if n=-1. None of the examples you give above are relevant to the discussion at hand which is whether the behavior of replacement rules with respect to 1/Sqrt[x] is a bug or not. None of my remarks imply Matheamtica has no bugs. Nor do my remarks imply there have not been changes from one version to the next that have caused problems for people. These things certainly exsits, and I can be much more specific than you have been above. But none of these are relevant to a discussion of whether the current behavior of replacement rules is a bug or not. >>I cannot believe anyone designing software to do mathematics would >>argue getting 1/x*Tan[x] as the result for Cot[x] was intentional >>design. >You can't? You cannot believe that anyone designing software might >have gotten some formula wrong? So much of computer algebra system >design includes a portion of "you might not like it but I have my >own reason for doing it this way." Do you understand the difference between getting some formula wrong and claiming 1/x*Tan[x] is an intentional design result for Cot[x]? If yes, you must realize your comments have no relevance to mine. If not, there is little point in a discussion of bugs with you. Yes, I realize errors made were not seen as errors at the time they were made and what was done was intentional at that time. I also realize there are people who will claim any result obtained is exactly what they intended. Neither of these things have relevance. If these were relevant criteria no behavior could ever qualify as being a bug. >I do agree that crowd-sourcing of mathematical theorems or opinions >on the design of Mathematica seems less useful than using expert(s) >in general. >I might point out that in almost all the reported problems, we have >a rule or sub-part of a rule, which has a constant, like 2, or I, >which fails to match an expression like -2 or or 1/2 or -I. You, >and others seem to thing that the effects of allowing this match >would be confusing, or inefficient, or would break things. No. I merely claim the current behavior of replacement rules is not a bug or a design error. It may well be possible to change the behavior so that it is in some respect more user friendly without causing other inefficiencies or breaking things. I don't have access to the source code and simply do not know what it would take to implement the changes you would like or what impact it might have on other parts of Mathematica. >In my view it would be simple enough to completely define the changes >necessary, document them, and implement them. I took the trouble to >write a paper and a sample implementation. It responds to certain >customers' issues. Suggesting a change that would respond to the needs of certain users is one thing. Calling the current behavior of replacement rules a bug or design error is quite another. >Your view, shared by some others, is that such a change is >unthinkable, and that the customer is wrong. 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.