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/
> >
> >
> >
> >
> >
>