Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
- To: mathgroup at smc.vnet.net
- Subject: [mg114632] Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
- From: Richard Fateman <fateman at cs.berkeley.edu>
- Date: Sat, 11 Dec 2010 01:52:57 -0500 (EST)
- References: <idsl03$6mg$1@smc.vnet.net>
On 12/9/2010 11:31 PM, Bill Rowe wrote: > > >>> (Bill) 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. > >> (RJF) 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." > > (Bill) Do you understand the difference between getting some formula > wrong and claiming 1/x*Tan[x] is an intentional design result > for Cot[x]? Well, my point was, you could have hired some person who misunderstood or misread or somehow got some formula wrong, but then accurately transcribed that incorrect formula into a program. His intentional design was to do the correct thing, and that is how the program was designed. So how could it be a bug? (no, maybe it is something else. perhaps a blunder?) > 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. I think you miss the point. You think there is no relevance, but that is because you miss the point. > > 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. Aha, that is the point. You just think it is inconceivable that someone could "believe" an incorrect formula. The Red Queen, in Alice in Wonderland, says that "...sometimes I've beleived as many as six impossible things before breakfast" > also realize there are people who will claim any result obtained > is exactly what they intended. Certainly. In the software "engineeering" world there are notions like "requirements" "specifications" "design" "detailed design" "implementation" etc. And there are people who "prove" that programs are correct because they satisfy the specifications even though they are terrible because the requirements are inadequate. For example, a requirement might be "in all cases the result of the manipulation should be the mathematically correct one, (if the correct result is unambiguous, mathematically)" Could you argue against that? Neither of these things have > relevance. If these were relevant criteria no behavior could > ever qualify as being a bug. Certainly. so how does one determine buggy? > > > (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? 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. Aha, so you agree that there is some criterion, which you call "user friendly". I might call it "mathematically consistent". That is how one might make a useful distinction between a "bug" and a "feature". 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. > 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? > >> 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. Um, it seems to me that we see messages on this newsgroup that look like requests by users to change the behavior to correspond to what they think should happen. So these are not quite different at all. > >> 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. You are just being too solicitous of the views of WRI defenders. 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. > >