Post Reply 
[solved] COLLECT bug? (10637)
11-20-2016, 07:26 AM (This post was last modified: 11-23-2016 02:15 AM by tastyelectron.)
Post: #1
[solved] COLLECT bug? (10637)
Hello all, I'm new to the forum and HP calculators in general.

Working within CAS on firmware (10637), I believe that I've found some repeatable incorrect results from collect():
Code:
collect((a*b+a*c)/(a*d+a*e+d*e), a)
    (a*(b+c))/(e+d)

Numeric substitution confirms the invalid result:
Code:
subst((a*b+a*c)/(a*d+a*e+d*e), {a=2,b=3,c=4,d=5,e=6})
    269.2E-3
subst((a*(b+c))/(e+d), {a=2,b=3,c=4,d=5,e=6})
    1.273E0

I'm content with collect()'s work in the numerator but for nearly half of my uses it appears to be chewing up denominators and returning only simplified portions of them, casting doubt over the work of this function and the underlying CAS.

Perhaps I am expecting something this function wasn't designed for, but the Help appears to describe this function as returning an equivalent representation of the input, collected with respect to Var.

Thanks all
Find all posts by this user
Quote this message in a reply
11-20-2016, 11:21 AM
Post: #2
RE: COLLECT bug? (10637)
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-
Find all posts by this user
Quote this message in a reply
11-20-2016, 11:23 AM (This post was last modified: 11-20-2016 11:26 AM by JMB.)
Post: #3
RE: COLLECT bug? (10637)
The function that you're trying to collect is not a polynomial, but a rational fraction (division of two polynomials). The help for the collect command states that the argument must be a polynomial or a list of polynomials.

Of course, collect(a*b+a*c,a) / collect(a*d+a*e+d*e,a) should work as expected.
Find all posts by this user
Quote this message in a reply
11-20-2016, 11:49 AM
Post: #4
RE: COLLECT bug? (10637)
(11-20-2016 11:23 AM)JMB Wrote:  The function that you're trying to collect is not a polynomial, but a rational fraction (division of two polynomials). The help for the collect command states that the argument must be a polynomial or a list of polynomials.

Of course, collect(a*b+a*c,a) / collect(a*d+a*e+d*e,a) should work as expected.

Given the above, maybe the command should error out, rather than return a value?

Perhaps Parisse will shed additional perspective on this topic.

-Dale-
Find all posts by this user
Quote this message in a reply
11-20-2016, 06:45 PM
Post: #5
RE: COLLECT bug? (10637)
Thanks everyone, I'm impressed with how active this community is! Smile

(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
Find all posts by this user
Quote this message in a reply
11-21-2016, 07:29 PM
Post: #6
RE: COLLECT bug? (10637)
I will add a check for collect(fraction,variable) or collect(list,variable) since only collect(polynomial expression,variable) is supported.
Find all posts by this user
Quote this message in a reply
11-21-2016, 07:40 PM
Post: #7
RE: COLLECT bug? (10637)
(11-21-2016 07:29 PM)parisse Wrote:  I will add a check for collect(fraction,variable) or collect(list,variable) since only collect(polynomial expression,variable) is supported.

Good idea.
Find all posts by this user
Quote this message in a reply
11-23-2016, 02:13 AM
Post: #8
RE: COLLECT bug? (10637)
Neat. thanks for your help parisse
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 1 Guest(s)