## [Reduce-algebra-developers] On simplification

 [Reduce-algebra-developers] On simplification From: Raffaele Vitolo - 2013-12-13 10:56:12 ```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. ```

 [Reduce-algebra-developers] On simplification From: Raffaele Vitolo - 2013-12-13 10:56:12 ```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. ```
 Re: [Reduce-algebra-developers] On simplification From: Eberhard Schruefer - 2013-12-13 13:32:32 ```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. 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 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Reduce-algebra-developers mailing list > Reduce-algebra-developers@... > https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers ```
 Re: [Reduce-algebra-developers] On simplification From: Raffaele Vitolo - 2013-12-13 23:31:22 ```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 15-day FREE TRIAL of AppDynamics Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk >> _______________________________________________ >> Reduce-algebra-developers mailing list >> Reduce-algebra-developers@... >> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers > > > ------------------------------------------------------------------------------ > 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 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Reduce-algebra-developers mailing list > Reduce-algebra-developers@... > https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers > -- Raffaele Vitolo, associate professor Dipartimento di Matematica e Fisica "E. De Giorgi" Universita' del Salento, Italy web: http://poincare.unisalento.it/vitolo ```
 Re: [Reduce-algebra-developers] On simplification From: Eberhard Schruefer - 2013-12-15 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 non-monic 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 <>; 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 <>; 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 15-day FREE TRIAL of AppDynamics Pro! >>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Reduce-algebra-developers mailing list >>> Reduce-algebra-developers@... >>> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers >> ------------------------------------------------------------------------------ >> 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 15-day FREE TRIAL of AppDynamics Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk >> _______________________________________________ >> Reduce-algebra-developers mailing list >> Reduce-algebra-developers@... >> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers >> ```
 Re: [Reduce-algebra-developers] On simplification From: Rainer Schöpf - 2014-12-29 12:22:41 ```On Sun, 15 Dec 2013 at 15:46 +0100, Eberhard Schruefer proposed a change to addsq: > 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 < 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 < 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. I ran the test suite against this change. The run times differ at most by 5% (specfn), in some cases the test runs a bit faster after making the change. The only notable difference is in the assert test log: with the old code, the call addsq(simp 'x, numr simp 'x); returns something whose structure is not a standard quotient, but with the new code it returns (1 . nil) Ie. formally a s.q., but with zero denominator. Any objection to including this change into the core system? Rainer ```
 Re: [Reduce-algebra-developers] On simplification From: Eberhard Schruefer - 2014-12-29 14:51:08 ```Actually, I was just looking at this code as part of my year end cleanup of my mail. Thanks Rainer for doing regression testing on it! Just to remind what it is supposed to fix. The current code yields 1: q1 := 1/(x+3); 1 q1 := ------- x + 3 2: q2 := (x**2+5*x+6)/(x**2+6*x+9); 2 x + 5*x + 6 q2 := -------------- 2 x + 6*x + 9 3: q1+q2; x + 3 ------- x + 3 Obviously the simplification is incomplete. The updated version of addsq results in 1 as one would expect. If nobody objects I will commit the fix by tomorrow evening. Eberhard On 12/29/2014 01:22 PM, Rainer Schöpf wrote: > On Sun, 15 Dec 2013 at 15:46 +0100, Eberhard Schruefer proposed a change to > addsq: > > > 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 < > 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 < > 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. > > I ran the test suite against this change. The run times differ at most by 5% > (specfn), in some cases the test runs a bit faster after making the change. > > The only notable difference is in the assert test log: with the old code, the > call > > addsq(simp 'x, numr simp 'x); > > returns something whose structure is not a standard quotient, but with the new > code it returns > > (1 . nil) > > Ie. formally a s.q., but with zero denominator. > > Any objection to including this change into the core system? > > Rainer ```