[solved] COLLECT bug? (10637) - Printable Version

[solved] COLLECT bug? (10637) - Printable Version

+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: HP Prime (/forum-5.html)
+--- Thread: [solved] COLLECT bug? (10637) (/thread-7270.html)

[solved] COLLECT bug? (10637) - tastyelectron - 11-20-2016 07:26 AM

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

RE: COLLECT bug? (10637) - DrD - 11-20-2016 11:21 AM

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-

RE: COLLECT bug? (10637) - JMB - 11-20-2016 11:23 AM

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.

RE: COLLECT bug? (10637) - DrD - 11-20-2016 11:49 AM

(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-

RE: COLLECT bug? (10637) - tastyelectron - 11-20-2016 06:45 PM

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

RE: COLLECT bug? (10637) - parisse - 11-21-2016 07:29 PM

I will add a check for collect(fraction,variable) or collect(list,variable) since only collect(polynomial expression,variable) is supported.

RE: COLLECT bug? (10637) - John P - 11-21-2016 07:40 PM

(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.

RE: COLLECT bug? (10637) - tastyelectron - 11-23-2016 02:13 AM

Neat. thanks for your help parisse