> > (1) we can rename gcd to polygcd and create a new gcd function.
> > The new gcd would treat its arguments as numbers
> > (or expressions which eventually evaluate to numbers).
I agree with this for three reasons:
1) The current behavior of gcd is confusing to many users.
2) In general, I believe that a lot of the power of Maxima comes from
the manipulation of mathematical (simplifying) functions rather than
programming (transforming) functions.
3) This lets us make gcd n-ary, a natural extension.
There is still the question of the meaning of gcd for non-integers.
In the rational case, currently gcd(a/b,c/d) = gcd(a,b)/lcm(b,d), so
that gcd(1/2,2/3) = 1/6 and gcd(2/9,4/3)=2/9. This preserves the
basic definition of GCD: that gcd(a,b) is the largest positive k such
that k|a and k|b (where a|b means that b/a is an integer). This
allows such simplifications as gcd(k*x,k*y)=>k*gcd(x,y), but also
means that gcd(x,1) isn't necessarily 1. Should gcd(%e,3*%e) be %e?
That also preserves the basic definition.
Whatever the definition is, we should have a *consistent* one between
gcd, mod, and divide. Today, divide(24/25,1/5)=[24/5,0] while
gcd(24/25,1/5)=1/25, so I would expect divide(24/25,1/5)=[4,4/25]
(where the quotient is always an integer).
-s