And? How do we improve the art of GB?   
      
   Am Donnerstag, 6. Juli 2017 20:55:59 UTC+2 schrieb Richard Fateman:   
   > On 7/6/2017 10:05 AM, bursejan@gmail.com wrote:   
   > > In the below paragraph there is possibly a negation   
   > > of yours somewhere missing:   
   > yep.   
   >   
   > corrected it should read ...   
   >   
   > Nevertheless, there are good reasons to believe that,   
   > in any reasonably implemented CAS which   
   > has  polynomial GCD and GB procedures,   that using GB to   
   > implement a GCD  would   
   > NOT   
   >   be faster than the GCD.   
   >   
   > ..........   
   >   
   > Since Jan mentions the classical Euclidean GCD ...   
   >   
   >   
   > The classical Euclidean GCD algorithm directly implemented   
   > for polynomial arithmetic is an obvious method. It is   
   > lucidly described and compared to some far superior alternatives   
   > in D.E. Knuth's Art of Computer Programming, vol. 2.   
   > Yet more superior algorithms were subsequently developed   
   > and are in fairly wide-spread implementations.   
   >   
   > The Euclidean GCD's theoretically expected behavior, and its actual   
   > behavior in practice are really quite poor.   
   >   
   > I can think of a worse algorithm for gcd(a,b), which   
   > is to use some method (perhaps a heuristic to make guesses)   
   > to make a list L1 of the factors of   
   > the polynomial a and L2 of the factors of   
   >   the polynomial b.  Then look   
   > to see which factors are in common in L1 and L2.   
   >   
   > (There is a generally slow but compact factoring algorithm   
   > available in Maxima.  Set berlefact:false to try it out.   
   > It is ok for really small degree small coefficient few variables.)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)