Re: RE: RE: Question about Replace

*To*: mathgroup at smc.vnet.net*Subject*: [mg35755] Re: [mg35713] RE: [mg35696] RE: [mg35670] Question about Replace*From*: "Xuguang\(Heather\) Zhang" <xuguang_zhang at hotmail.com>*Date*: Mon, 29 Jul 2002 03:13:30 -0400 (EDT)*References*: <2F63E988-A1B4-11D6-B1F5-00039311C1CC@tuins.ac.jp>*Sender*: owner-wri-mathgroup at wolfram.com

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 Subject: [mg35755] 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: [mg35755] 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 > > > > > > > Andrzej Kozlowski > Toyama International University > JAPAN > http://platon.c.u-tokyo.ac.jp/andrzej/ > > > > > > > > > > >

**Re: More weird integration issues...**

**Extracting Terminal Value**

**Re: Question about Replace**

**Re: Re: Question about Replace**