Re: Replacement Rule with Sqrt in denominator

*To*: mathgroup at smc.vnet.net*Subject*: [mg114474] Re: Replacement Rule with Sqrt in denominator*From*: Richard Fateman <fateman at cs.berkeley.edu>*Date*: Sun, 5 Dec 2010 21:52:27 -0500 (EST)*References*: <idd7nd$nb9$1@smc.vnet.net>

On 12/4/2010 3:12 AM, Daniel Lichtblau wrote: >> (RJF wrote) Thus the burden falls on >> you to look at the data representation underlying the abstraction >> to make your program work." > > (DanL wrote) I'd change "abstraction" to "representation". At which point I would > agree, regarding the burden. No, I think the abstraction is something like "a/b" or possibly "a^(-n)". Or "An expression x such that Numerator[x]==a, Denominator[x]==b. Of course the representation, deep down, is using electrons and stuff. But one layer down the representation can be Rational[a,b] if a,b, are numbers, and gcd(a,b)=1 and a>0. Or it can be Times[a,Power[b,-1]] or yet other options. The fact that Mathematica requires you to deal with this representation layer is the problem. > > >> It's not so hard to make the system smarter. > > I'll indicate below why I am not convinced what you want equates to > smarter software. > > >> But you pay for what >> you get. > > Here I agree. > > Actually one of the things I really appreciate about Mathematica, and > for which, alas, I can take no credit, is that rule replacement works so > reliably well. When I get frustrated with it failing to do what I intend > (about once every month or two), there is the inevitable session with > MatchQ to sort things out. You see, the abstraction (in your mind) and the representation are different. I too find the pattern issues occasionally frustrating, and I have the advantage of (reverse engineering) the Mathematica pattern matcher (version 3.0) or so, in Lisp. So there were things I had to figure out so I could program them. Things I would not have ever tried, and probably no one had ever used. > > >> RJF > > I think any nonsyntactic rule replacement will need very clear > semantics. Yes, I agree. The notion "replace it if it shows up visually" is not > terribly clear. It relies, among other things, on specifics of the > format settings, vagaries of e.g. StandardForm, and other details. I agree. That's why notions like "coefficient of I" and "numerator of X" are needed. > > To give an idea of what is meant by the formatting vagaries, consider > that we could represent 1/Sqrt[x+1] explicitly as (x+1)^(-1/2) (mentally > format that so it looks pretty, with the exponent raised, no caret, > etc.) So the substitution semantics being proposed would depend on > formatting?! Not really. The notion of sqrt(x) is fairly clear, and it seems to include the denominator of 1/sqrt(x). This is not, I think, rocket science. Or should it apply to any power of (x+1) when that power > visually has a 2 in the denominator? (Does it then apply to > (x+1)^(a/2+b/4)? Or only to the equivalent (x+1)^(1/2*(a+b/2))?) Possibly. It seems to me that this is kind of like "Simplify" vs "FullSimplify". > > These are the questions that would need to be answered before even > embarking on this journey. Note that I have shown that the improved pattern matching can be built using syntactic pattern matching plus some other programs. I am not requiring that the syntactic pattern matching be removed. > > I will add that about the last thing anyone wants is that StandardForm > formatting be influenced by the desire to avoid any possibility of > showing "misleading" expression structure. I don't think you are > proposing otherwise, but it would be a natural outcome to any effort to > try to curtail this misunderstanding. I am not proposing altering the display. > > I have not raised the I->3*I issue. I do wonder what should be the > outcome of Sin[x] /. I->3*I . Well, you could also claim that -1/. I->x should be x^2. This kind of issue can be thought through by fairly simple means. If you can divide an expression H by P to compute Q,R in H=Q*P+R, then replacing P by M results in the expression Q*M+R. Done. So we are talking about division. (This does not quite cover all the cases, but it is close). Maybe the trig equivalent of > (Exp[3*I*x] - Exp[-3*I*x]) / (6*I), which is Sin[3*x]/3? (Maybe we > should make it case insensitive, and return S3in[x]?) String substitution and regular expressions and the like are of course a different matter. :) RJF