From: Eberhard Schruefer <eschruefer@ca...>  20131215 14:46:40

Hi Raffaele, The 'strange' behavior you noticed has all to do with the flag gcd (which is off by default). Let's take a look at your matrix element glmat2(1,1). It is the expanded form of (polynomial1*polynomial2)/(polynomial2**5) where polynomial1 and polynomial2 are nonmonic irreducible polynomials. As the REDUCE flag 'gcd' is off, these kind of expressions can occur, i.e. polynomial2 is not canceled out of the numerator and the denominator. In the next step of your calculation the above expression is multiplied by polynomial2**4 When 'gcd' is off this simplifies with the current code to (polynomial1*polynomial2)/polynomial2 and this is the root of the behavior you discovered. I think this is not what one would expect, because if you input this expression directly (which you did in your first mail) the simplification would yield just polynomial1 The reduction to polynomial1 would of course also be triggered by a call to rmsubs() and confuse an user even more. A nicer simplification could be achieved by altering the procedure addsq to symbolic procedure addsq(u,v); % U and V are standard quotients. % Value is canonical sum of U and V. if null numr u then v else if null numr v then u else if denr u=1 and denr v=1 then addf(numr u,numr v) ./ 1 else begin scalar x,y,z; if null !*exp then <<u := numr u ./ mkprod denr u; v := numr v ./ mkprod denr v>>; if !*lcm then x := gcdf!*(denr u,denr v) else x := gcdf(denr u,denr v); z := canonsq(quotf(denr u,x) ./ quotf(denr v,x)); y := addf(multf(denr z,numr u),multf(numr z,numr v)); if null y then return nil ./ 1; z := multf(denr u,denr z); if (x := gcdf(y,x)) neq 1 then <<y := quotf(y,x); z := quotf(z,x)>>; if !*gcd then return if x=1 then y ./ z else canonsq(y ./ z); return if (x := gcdf(y,z))=1 then canonsq(y ./ z) else canonsq(quotf(y,x) ./ quotf(z,x)) end; However, this slows down calculations a little bit. Here is a simpler example that shows the behavior 1: t1 := (  4*tb1)/(tb1 + 3);  4*tb1 t1 :=  tb1 + 3 2: t2 := (4*tb1*(  tb1**2  5*tb1  6))/(tb1**2 + 6*tb1 + 9); 2 4*tb1*(  tb1  5*tb1  6) t2 :=  2 tb1 + 6*tb1 + 9 3: t1+t2; 4*tb1*(  tb1  3)  tb1 + 3 4: lisp rmsubs(); 5: ws;  4*tb1 Anybody comments on this? Best wishes, Eberhard On 12/14/2013 12:31 AM, Raffaele Vitolo wrote: > Hi Eberhard, > > On 13/12/13 12:41, Eberhard Schruefer wrote: >> Hi Raffaele, >> >> What version of REDUCE are you using? I'm not seeing the behaviour you >> describe on >> an up to date svn version of REDUCE. The denominator is always cleared out. > I'm using the latest svn. > > You are right, the behaviour is exhibited when I do the computation with > this simple script: > http://poincare.unisalento.it/vitolo/tempo/test > > Just say 'y' after pauses and you will see it. The simplification is > performed only after switching off factorization. Maybe it is normal? > > Best wishes, Raf. > >> Best wishes, Eberhard >> >> On 12/13/2013 11:38 AM, Raffaele Vitolo wrote: >>> Dear All, >>> >>> I noticed a strange behaviour of the factorization with respect to >>> rational expressions. Namely, I have a rational expression where I know >>> that the denominator must simplify: >>> >>> g:= >>> (2*cf1**3*tb1*tb3**2 + 2*cf1**2*cf2*tb2*tb3**2 + 2*cf1**2*cf3*tb3**3  >>> 4*cf1**2* >>> tb1*tb2*tb3 + 2*cf1**2*tb3**2 + cf1*cf2**2*mu*tb1*tb2**2 + >>> 2*cf1*cf2*cf3*mu*tb1* >>> tb2*tb3 + 2*cf1*cf2*mu*tb1*tb2  4*cf1*cf2*tb2**2*tb3 + >>> cf1*cf3**2*mu*tb1*tb3**2 >>> + 2*cf1*cf3*mu*tb1*tb3  4*cf1*cf3*tb2*tb3**2 + cf1*mu*tb1 + >>> 2*cf1*tb1*tb2**2  >>> 4*cf1*tb2*tb3 + cf2**3*mu*tb2**3 + 3*cf2**2*cf3*mu*tb2**2*tb3 + >>> 3*cf2**2*mu*tb2 >>> **2 + 3*cf2*cf3**2*mu*tb2*tb3**2 + 6*cf2*cf3*mu*tb2*tb3 + 3*cf2*mu*tb2 + >>> 2*cf2* >>> tb2**3 + cf3**3*mu*tb3**3 + 3*cf3**2*mu*tb3**2 + 3*cf3*mu*tb3 + >>> 2*cf3*tb2**2*tb3 >>> + mu + 2*tb2**2)/(cf1*tb1 + cf2*tb2 + cf3*tb3 + 1)$ >>> >>> I do >>> off exp; on gcd; on ezgcd; >>> >>> then the expression correctly factorizes in numerator and denominator >>> but does *not* simplify: >>> >>> g; >>> >>> ((2*cf1**2*tb3**2  4*cf1*tb2*tb3 + cf2**2*mu*tb2**2 + >>> 2*cf2*cf3*mu*tb2*tb3 + 2* >>> cf2*mu*tb2 + cf3**2*mu*tb3**2 + 2*cf3*mu*tb3 + mu + 2*tb2**2)*(cf1*tb1 + >>> cf2*tb2 + cf3*tb3 + 1))/(cf3*tb3 + 1 + cf2*tb2 + cf1*tb1)$ >>> >>> you may see that the two equal factors are written with summands in >>> different order. >>> >>> Then if I do off ezgcd; off gcd; on exp; >>> and call g; I have the simplification to: >>> >>> 2*cf1**2*tb3**2  4*cf1*tb2*tb3 + cf2**2*mu*tb2**2 + >>> 2*cf2*cf3*mu*tb2*tb3 + 2* >>> cf2*mu*tb2 + cf3**2*mu*tb3**2 + 2*cf3*mu*tb3 + mu + 2*tb2**2$ >>> >>> Is this the correct behaviour? I thought that simplification should >>> occur at the factorization stage ... maybe a bug due to the 'strange' >>> reordering of terms in the denominator after factorization? >>> >>> Raf. >>> >>> >>> >>>  >>> Rapidly troubleshoot problems before they affect your business. Most IT >>> organizations don't have a clear picture of how application performance >>> affects their revenue. With AppDynamics, you get 100% visibility into your >>> Java,.NET, & PHP application. Start your 15day FREE TRIAL of AppDynamics Pro! >>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Reducealgebradevelopers mailing list >>> Reducealgebradevelopers@... >>> https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers >>  >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15day FREE TRIAL of AppDynamics Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk >> _______________________________________________ >> Reducealgebradevelopers mailing list >> Reducealgebradevelopers@... >> https://lists.sourceforge.net/lists/listinfo/reducealgebradevelopers >> 