[solved] COLLECT bug? (10637)

[tastyelectron]

Thanks everyone, I'm impressed with how active this community is!

(11-20-2016 11:21 AM)DrD Wrote:  To avoid any possible conflict with the variable e, (epsilon or ln) if you change variable e to f, instead, the last optional form (from the collect() help doc's, for a list of expressions, with respect to a variable), doesn't work, either:

collect({a*b+a*c,a*d+a*f+d*f},a); ==> [a*(b+c)+d+f,d*f]

Interestingly, if you bring the Ans (above) to the command line, it displays:

poly1[a*(b+c)+d+f,d*f]

-Dale-

Agreed, that is curious. It appears that collect()'s issues stem from passing both a list of of polys as well as a Var to collect with respect to, which I'll admit isn't a usage explicitly shown in Help. As you probably saw, collect({a*b+a*c,a*d+a*f+d*f}) does produce algebraically equivalent results, even if not fully collected.

JMB pointed out the subtlety that collect() is expecting a pure polynominal rather than a rational relation of two polys which I'm passing here. Since collect() does appear to be working correctly for collecting with respect to a single variable when rational relations aren't part of its parameters, I've thrown together a quick program which captures the essence of JMB's recommendation to work around collect()'s defficiency in an automated way.

Code:

#cas
COLLECTR(r,var):=
BEGIN
  LOCAL cp;
  cp:={collect(numer(r),var), collect(denom(r),var)};
  return cp[1]/cp[2];
END;
#end

I'll need to do some more stress testing to blindly trust COLLECTR()'s results, but for the example I provided above it does appear to produce algebraically correct results in the form I was hoping for.

Code:

r:=(a*b+a*c)/(a*d+a*f+d*f)
o1:=collect(r)
    (a*(b+c))/(a*d+a*f+d*f)
o2:=collect(r,a)
    (a*(b+c))/(d+f)
o3:=COLLECTR(r,a)
    (a*(b+c))/(a*(d+f)+d*f)
subst({r, o1, o2, o3},{a=2,b=3,c=4,d=5,f=6})
    {7/26, 7/26, 14/11, 7/26}

-Andy