[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
 tastyelectron Junior Member Posts: 9 Joined: Nov 2016
[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
11-20-2016, 11:21 AM
Post: #2
 DrD Senior Member Posts: 1,133 Joined: Feb 2014
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-
11-20-2016, 11:23 AM (This post was last modified: 11-20-2016 11:26 AM by JMB.)
Post: #3
 JMB Member Posts: 98 Joined: Jan 2016
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.
11-20-2016, 11:49 AM
Post: #4
 DrD Senior Member Posts: 1,133 Joined: Feb 2014
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-
11-20-2016, 06:45 PM
Post: #5
 tastyelectron Junior Member Posts: 9 Joined: Nov 2016
RE: COLLECT bug? (10637)
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
11-21-2016, 07:29 PM
Post: #6
 parisse Senior Member Posts: 1,322 Joined: Dec 2013
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.
11-21-2016, 07:40 PM
Post: #7
 John P Member Posts: 219 Joined: Dec 2013
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.
11-23-2016, 02:13 AM
Post: #8
 tastyelectron Junior Member Posts: 9 Joined: Nov 2016
RE: COLLECT bug? (10637)
Neat. thanks for your help parisse
 « Next Oldest | Next Newest »

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