Re: Replacement Rule with Sqrt in denominator. Also Bug in Series

*To*: mathgroup at smc.vnet.net*Subject*: [mg114536] Re: Replacement Rule with Sqrt in denominator. Also Bug in Series*From*: Richard Fateman <fateman at cs.berkeley.edu>*Date*: Tue, 7 Dec 2010 06:45:21 -0500 (EST)*References*: <idigif$is4$1@smc.vnet.net>

On 12/6/2010 3:14 AM, Bill Rowe wrote: ... > >> (RJF, putting words in Bill Rowe's mouth)... >> If a designer writes a program that does exactly what the designer >> intended, then it is not a bug. > > (Bill Rowe) 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. 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? > >> that causes mathematical computations to proceed in a way that is >> internally inconsistent, and is generally considered mathematical >> nonsense? Mathematica does not restrict its blunders to matching and rules. > > Since replacement rules are not doing mathematics there should > be no requirement for the result to make mathematical sense. I don't require rules to be applications of identities. I think that it is mathematically inconsistent to match "I" in a+b*I but not match "I" in 3+4*I. > That is a replacement rule such as 2->1 is perfectly valid but > clearly doesn't make 2 equal to 1. OK, It is perfectly valid, but it doesn't work consistently. Example. (a+b)^2 /. 2-> 1 returns a+b AS EXPECTED. (a+b)^(1/2) /. 2->1 returns Sqrt[a+b] IS THIS EXPECTED?? 2+a*I /. 2->1 returns 1+a*I AS EXPECTED. 2+3*I /. 2->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. Actually, replacement rules operate on the internal representation of the expression. FullForm is simply another output form that is an alternative string representation ( or XML or whatever..) of the internal representation. One that is somewhat more explicit in some ways than the usual standard form. Clearly FullForm doesn't work as you think it does, because FullForm[Sqrt[a+b]] has a "2" in it, but the rules don't know it. So you REALLY need to know that FullForm of a Rational is not an accurate representation of the internal form, and is hiding something that is the yet Fuller Form, that explains that although Rational[1,2] is what you see, it is not REALLY an object with a Head of Rational and two parts; Example. f= F[3,5] has Head F, f[[1]] is 3, f[[2]] is 5. g=3/5 has Head Rational g[[1]] is not 3, but an error. But, that simply doesn't equate to being a bug. No, but it means that any program that traverses an expression (say, to do a replacement 2->1), has to check for a subexpression that has head Rational, and must decide NOT to do replacements within it. Is this extra work to get the wrong answer? Of course if the replacement were 2->x then replacing Rational[1,2] by Rational[1,x] would be a bad idea... so it is a tradeoff of some sort. In my view, the wrong tradeoff. That means I think it is a bug or blunder. You may view it otherwise. I may view your view as incorrect. That's the way it goes. > >> 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. You (and DanL?) seem to think that I am advocating making replacement rules work on what is displayed. Yet in a/b, I see no occurrence of Numerator[] or Denominator[], which encode the semantics. Semantics is what I think should be used for patterns. It would be possible to translate a_/b_ into "let x=a_/b_; consider Numerator[x] and Denominator[x] ...." The alternative which is presented for consumption in this newsgroup is that patterns operate on the syntax as depicted by FullForm. But that too is a simplification, since it does not work for Complex[], Rational[], or for that matter, other forms that you may not know about (yet). Example. (is this a bug??) Series[ x^5, {x,0, 10} ] /. 5-> 6 gives x^6 + O[x]^11 Series[1+x^5, {x,0, 10} ] /. 5-> 6 gives 1 + x^5 + O[x]^11 or is it a feature? And do you know about SparseArray, for which replacements don't work either? and who knows what else. Blame the customer for not knowing. That's the ticket. RJF

**Re: CMake module for Mathematica**

**Re: Replacement Rule with Sqrt in denominator**

**Re: Are these bugs fixed in Mathematica 8 ?**

**Re: Replacement Rule with Sqrt in denominator. Also Bug in Series**