Re: RE: RE: Question about Replace
- To: mathgroup at smc.vnet.net
- Subject: [mg35760] Re: [mg35713] RE: [mg35696] RE: [mg35670] Question about Replace
- From: Andrzej Kozlowski <andrzej at tuins.ac.jp>
- Date: Tue, 30 Jul 2002 07:22:07 -0400 (EDT)
- Sender: owner-wri-mathgroup at wolfram.com
First, let me show how the rule I sent last time can be used to somewhat simplify the manual operations you have been making. We define a rather simple-minded "much smaller" function by: MuchSmaller[y_, x_][expr_] := expr //. HoldPattern[x + (k : (_?NumericQ) : 1)*y] :> x all it does is try to replace expressions like x+k*y by just plain x when y is much smaller than x. k is any numeric quantity. Now let's consider your case: In[2]:= TF[s_]= gm1* (gds2+gm2+A*gm2 +cbd2*s)/(gds1*(gds2+(cbd2+cload)*s)+s*(cload*(gds2+gm2+A*gm2+cbd2*s)+c1* (g ds2+(cbd2+cload)*s))); In[3]:= TF[0] From In[3]:= (gm1*(gds2 + gm2 + A*gm2))/(gds1*gds2) We know that gds2 is much smaller than gm2 so: In[4]:= MuchSmaller[gds2,gm2][%] From In[4]:= (gm1*(gm2 + A*gm2))/(gds1*gds2) next we would like to use the fact that A is much smaller than 1. However, the problem with using pattern matching to do this sort of thing is that you first have to transform the expression in such a way that the pattern you are trying to match is explicitly visible. In this case we only need to apply: In[5]:= MuchSmaller[A,1][Factor[%]] From In[5]:= (gm1*gm2)/(gds1*gds2) It would not have worked without Factor. One could refine the MuchSmaller function to consider a number of rules at the same time and to try simplifying before using rules, but in the end "manual control" will always be necessary. With some effort it might indeed be possible to write a sensible set of rules for simplifying expressions using "muchsmaller" assumptions, although one has to be careful because many usual laws of arithmetic will break down (e.g. suppose we know that x is much smaller than y but we know nothing about a. In that case you do not wish to reduce a + x to just a. However, applying "usual" laws of aritmetic we get a + x == (a-y) + (y + x) == a-y + y == a). Andrzej Andrzej Kozlowski Toyama International University JAPAN http://platon.c.u-tokyo.ac.jp/andrzej/ On Monday, July 29, 2002, at 07:44 AM, Xuguang(Heather) Zhang wrote: > First, thank you for all the response. > > In fact, my second question about replace do relate to the first > question > about simplification with "much less" assumptions. It is an Engineering > problem. I have circuits with different parasitic capacitors and > resistors. > The transfer function of the circuit in frequency domain (S domain) is > very > complicated. I need to simplify the frequency response under certain > assumptions. Then, it will be easier for me to find the dominant poles > and > zeros of the transfer function. Previously I do the simplification by > hand. > Sometimes it is time-consuming and very easy to make mistakes. Since I > started using Mathematica recently, I am trying to figure out whether > Mathematica can easily help me in simplifying transfer functions. > > For example, a transfer function in S domain is as follows: > > TF(s) = gm1* (gds2+gm2+A*gm2 > +cbd2*s)/((gds1*(gds2+(cbd2+cload)*s)+s*(cload*(gds2+gm2+A*gm2+cbd2*s)+c1* > (g > ds2+(cbd2+cload)*s)))....(Eqn.1) > > Where gds1 is much less than gm1 (Assumption 1), gds2 is much less than > gm2 > (Assumption 2) , cbd2 is much less than cload (Assum. 3) and A is much > larger than 1 (Assum. 4). > s=j*w where w refers to the frequency. Here s is a variable. It ranges > from > 0 to infinity. When s=0, we can get the DC gain as > > TF(0)=gm1*(gds2+gm2+A*gm2)/(gds1*gds2)........(Eqn. 2), > > which can be approximated as gm1*A*gm2/(gds1*gds2) under the > assumptions. > > All the parameters in the above equations are positive. > > Please note that Assum. 1,2,3 and 4 are the only assumptions we have. > There > is no other relationship definitions between different parameters. For > example, we do not know whether gds1 is larger than gds2 or not. Or gm1 > is > larger than gm2 or not and so on and so forth. Obviously, when > simplifying > TF(s), we can not simply assume gds2->0, gds1->0 and cbd2->0. > If we redefine gds1/gm1 as x, gds2/gm2 as y, cbd2/cload as z, TF(s) > becomes > a function of {x, y, z, gm1,gm2,cload,c1,A}as shown below, > > TF(s)=gm1*(gm2+A*gm2+gm2*y+cload*s*z))/(cload*gm2*s+A*cload*gm2*s+c1*cload* > s > ^2+cload*gm1*s*x+c1*gm2*s*y > +cload*gm2*s*y+gm1*gm2*x*y+c1*cload*s^2*z+cload2*s2*z+cload*gm1*s*x*z)... > ... > .....(Eqn.3) > > After using "Limit" function on TF with x->0 & y->0 & z->0, TF(s) will > be > (1+A)*gm1*gm2/(cload*s*(gm2+A*gm2+c1*s))......(Eqn.4) > > At the first glance, the answer seems simple enough. However, if we > verify > the answer, we find it is totally wrong because now TF(0) becomes > infinite > other than what we shown in Eqn. (2). Furthermore, the location of > poles and > zero of TF(s) are changed. One reason causing this error is that > Mathematica > removes any terms that have x, y or z . For example, cload*s*z term is > being > deleted by Mathematica by mistake after "Limit" function. In fact, the > value > of cload*s*z is undefined although z is close to zero. cload*s*z can be > very > large if s and cload are both very large compared with z. > > I also found some other methods such as using "Series" & "Normal" or > using > "MachineEpsilon" & "chop" are not practical for my case. > > In order to avoid deleting some terms mistakenly as what happened in > "Limit" > function, I think the only way is to go back to Eqn. (1) and just let > Mathematica to replace (gm1+gds1) by gm1, (gm2+gds2) by gm2 and > (cbd2+cload) > by cload. By doing this, we can guarantee that gds1 will be neglected > only > when gm1 and gds1 have common coefficients. For example, > cload*gm2+cload*gds2 will be replace by cload*gm2. But cload*gm2+c1*gds2 > will not be changed since gm2 and gds2 do not have common coefficients. > > To speak frankly, after trying all the above methods, I found simplying > TF > by hand is comparably straight forward. > > Anyone who have comments, better suggestions are quite welcome. Anyone > who > have similar experience on circuit analysis, please let me know whether > you > have better simplification method or not. I am looking forward to > hearing > from you all. Thank you. > > > Heather > > ----- Original Message ----- > From: "Andrzej Kozlowski" <andrzej at tuins.ac.jp> To: mathgroup at smc.vnet.net > Cc: <xuguang_zhang at hotmail.com> > Sent: Saturday, July 27, 2002 7:57 PM > Subject: [mg35760] Re: [mg35713] RE: [mg35696] RE: [mg35670] Question about > Replace > > >> Seems to me that this is quite obviously *not* what was asked for as >> it >> will do things like: >> >> In[15]:= >> e^x /. x -> z - y /. z -> x >> >> Out[15]= >> e^(x - y) >> >> which, if I remember correctly the original posting (I did not keep it) >> was not wanted. But hen we are just guessing what's in another person"s >> mind. >> >> On Sunday, July 28, 2002, at 02:15 AM, DrBob wrote: >> >>> She's looking for a change of variables. Nothing mysterious about it. >>> >>> Expr/.x->z-y/.z->x >>> >>> Bobby >>> >>> -----Original Message----- >>> From: Andrzej Kozlowski [mailto:andrzej at tuins.ac.jp] To: mathgroup at smc.vnet.net >>> Sent: Saturday, July 27, 2002 9:42 AM >>> Cc: mathgroup at smc.vnet.net >>> Subject: [mg35760] Re: [mg35713] RE: [mg35696] RE: [mg35670] Question about >>> Replace >>> >>> >>>> On Saturday, July 27, 2002, at 07:43 PM, Allan Hayes wrote: >>>> >>>> "Xuguang(Heather) Zhang" <xuguang_zhang at hotmail.com> wrote in message >>>> news:ahr0mf$l20$1 at smc.vnet.net... >>>> Hi, Bob, >>>> >>>> I tried ReplaceRepeated, however, I got the following answer: >>>> x+y+z/(x+y)+e^(x+y)+(w*x)+y//. x+y->x >>>> >>>> e^x+x+(w*x)+2y+z/x >>>> >>>> In fact, there is still one more (x+y) term if we rewritten the >>> answer. >>>> That >>>> is e^x+(x+y)+y+(w*x)+z/x. Do you know how to get rid of it? Thanks. >>>> >>>> Heather, >>>> >>>> Use Simplify with the assumption x+y=x: >>>> >>>> Simplify[x + y + z/(x + y) + e^(x + y) + w*x + y, {x + y == x}] >>>> >>>> e^x + x + w*x + z/x >>>> >>>> In other circumstances we may have to give more help Simplify (or >>>> FullSimplify). >>>> Please check possiblities in the Help Browser. >>>> >>>> >>>> Allan >>>> >>>> --------------------- >>>> Allan Hayes >>>> Mathematica Training and Consulting >>>> Leicester UK >>>> www.haystack.demon.co.uk >>>> hay at haystack.demon.co.uk >>>> Voice: +44 (0)116 271 4198 >>>> Fax: +44 (0)870 164 0565 >>>> >>> >>> >>> The problem is that the assumption {x+y==x} is exactly the same as >>> {y==0} ,e.g. : >>> >>> >>> Simplify[y + z/(x + y) + e^(x + y) + w*x + y, {x + y == x}] >>> >>> >>> e^x + w*x + z/x >>> >>> which presumably is not what was wanted (if it was than it is much >>> simpler just to substitute y -> 0}? Quite frankly, the original >>> request >>> does not make any mathematical sense at all, at least to me. For a >>> start, it is hard to imagine under what conditions it is reasonable to >>> substitute x for x+y if y is not 0! In addition, what does it mean to >>> say "there is still one more term if we rewrite the answer"? If x+2y >>> "contains" x+y because it can be rewritten as (x+y) + y than so does >>> x+1/2 y since that can be re-written as (x+y)-1/2y and so does any >>> expression. The kind of magic that seems to asked for cannot be >>> achieved >>> >>> either by syntactic pattern matching (because of the need to interpret >>> "contains") or by Simplify which uses wll defined mathematical rules >>> (and in this case the only well defined rule is y==0). >>> >>> Actually on second thoughts I began to suspect that this question is >>> related to another one posted by Heather, concerning simplifying >>> expressions in which x is "much larger than" y. I am not at all sure >>> if >>> a sensible calculus of this kind can be developed but obviously >>> Simplify >>> >>> will not do this. Moreover, it seems to me that under any sensible >>> interpretation of "much larger than", if x+y is approximately x, then >>> so is x+2y, and so on. In other words, x is essentially Infinity in >>> relation to y. If so, there is no reason then why a single y should be >>> left int the answer and x+ (any numeric quantity) y ought to be >>> replaced by just x (without at the same time assuming that y is zero). >>> This sort of thing may perhaps be achieved with the following rule: >>> >>> >>> x + y + z/(x + y) + e^(x + y) + e^y + w*x + y//. >>> x + (k:(_?NumericQ):1)*y -> x >>> >>> >>> e^x + e^y + x + w*x + z/x >>> >>> >>> >>> >>> >>> >>> >>> >> > > >