Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
- To: mathgroup at smc.vnet.net
- Subject: [mg114667] Re: Replacement Rule with Sqrt in denominator. Also Bug in Series
- From: Daniel Lichtblau <danl at wolfram.com>
- Date: Sun, 12 Dec 2010 05:43:19 -0500 (EST)
> > 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? Yes, if it means guessing user intent. I'll add that it is not generally a good idea to punch holes in the "usual" behavior to get some exceptional cases to "work" in some different way. It should be done sometimes, but it is a slippery slope. A major problem is that there are often unintended side effects. This may not be an issue if you take an academic view. But if you are charged with maintaining or marketing the software then it becomes a different matter. I recently dug a big hole, and jumped inside it, in an attempt to make some rational function algebra (e.g. Together and friends) do the "obvious" thing with inputs containing approximate number coefficients. Not yet sure if I am climbing out, or still digging. > > (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? One reasonable basis would be that the designers claim it is neither a bug nor a design error. You, as a user, are then quite entitled to opine that it was a bad design. That would be okay as an opinion. It is not the same thing as a design error (as I understand the meaning) and it is quite far from a bug. > 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". That would involve a redefinition ofthe term "bug", as opposed to e.g. a bad design. > 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? It was asked of someone else, but I think the developer who makes the change would need to take care that nothing else of importance changed as a side effect. It would also be desirable to check by some means whether the change went sufficiently far as to capture what many users expect, without leaving loose ends. > >> 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. What is there is not necessarily what would be required for maintaining a commercial product. > > 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. They are indeed quite different. > >> 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. These opinions do not determine the quality of being a bug. They may help to point to cases of bad design of some functionality. I do not think the examples in question qualify as such a case, but clearly others disagree. If you wish to change, by extension, the meaning of "bug", then it behooves you to distinguish carefully what you are doing. Else you are likely to cheapen your own currency. Daniel Lichtblau Wolfram Research