Re: Replacement Rule with Sqrt in denominator
- To: mathgroup at smc.vnet.net
- Subject: [mg114520] Re: Replacement Rule with Sqrt in denominator
- From: Bill Rowe <readnews at sbcglobal.net>
- Date: Mon, 6 Dec 2010 06:14:21 -0500 (EST)
On 12/5/10 at 9:52 PM, fateman at cs.berkeley.edu (Richard Fateman) wrote: >On 12/4/2010 3:14 AM, Bill Rowe wrote: >>When an aspect of software works as designed it is inappropriate to >>refer to that aspect as a bug. >OK, I say "Dressing up a bug as a feature does not fix the bug." And I agree. >You say, in effect, >If a designer writes a program that does exactly what the designer >intended, then it is not a bug. Yes. >OK, then, what term do you wish to use to refer to the result of >design and programming that results from an error in the design I don't agree the behavior of replacement rules reflects an error in design. >that causes mathematical computations to proceed in a way that is >internally inconsistent, and is generally considered mathematical >nonsense? Since replacement rules are not doing mathematics there should be no requirement for the result to make mathematical sense. That is a replacement rule such as 2->1 is perfectly valid but clearly doesn't make 2 equal to 1. >>The fact replacement rules operate on the FullForm of an expression >>but what is displayed is not the FullForm does mean inexperienced >>users of Mathematica will encounter some difficulties with >>replacement rules. But, that simply doesn't equate to being a bug. >No, I think the error is that users need to have another kind of >pattern matching, and that when too many people stumble over the >same feature, the correct response is NOT, "the customer is wrong, >yet again." >It might be , Oh, you want the semantic pattern matcher. >Maybe, Here's how we can set it up to be your default command pattern >matcher... In another post Daniel Lichtblau described the issues with trying to make replacement rules work on what is displayed rather than full form.