serious bug in integrate. Fails first time, OK second time. 1.3.6 version

[Nasser M. Abbasi]

Could someone please explain why this call to integrate fails first time, but works second time?

Running 1.3.6 on Linux Manjaro under Virtual box

>fricas

Checking for foreign routines

FRICAS="/usr/local/lib/fricas/target/x86_64-linux-gnu"

spad-lib="/usr/local/lib/fricas/target/x86_64-linux-gnu/lib/libspad.so"

foreign routines found

                       FriCAS Computer Algebra System 

                            Version: FriCAS 1.3.6

                 Timestamp: Mon 09 Mar 2020 12:35:03 PM CDT

(1) -> setSimplifyDenomsFlag(true)       

   (1)  false

                                                                Type: Boolean

(2) -> integrate((b*x + a)^(3/2)*(d*x + c)^(5/2)/x^7,x)

 

   >> Error detected within library code:

   "failed" of mode Union(SparseUnivariatePolynomial(Expression(Integer)),"failed") cannot be coerced to mode SparseUnivariatePolynomial(Expression(Integer))

(2) -> integrate((b*x + a)^(3/2)*(d*x + c)^(5/2)/x^7,x)

No error. Gives result ok second time.

Thanks

--Nasser

[Nasser M. Abbasi]

Fyi, found another one with the same problem. I found this happens when setting  setSimplifyDenomsFlag(true) 

If I do not issue  setSimplifyDenomsFlag(true)  before, then the integral works first time.

So to test these yourself, make sure to start Fricas fresh session and then issue setSimplifyDenomsFlag(true) and then issue the integrate command next. It should fail. Now issue the integrate command again, and now it should work.  

1) ->  setSimplifyDenomsFlag(true) 

   (1)  false

                                                                Type: Boolean

(2) ->  integrate((1-cos(d*x+c)^2)*sec(d*x+c)/(a+b*cos(d*x+c)),x)

 

   >> Error detected within library code:

   "failed" of mode Union(Integer,"failed") cannot be coerced to mode Integer

[oldk1331]

Thanks for your report.

This bug is a regression between 1.3.5 and 1.3.6.
It's introduced in r2586
(https://github.com/fricas/fricas/commit/aacdddd3e2ecbb4e34f5cfa473f19c9333623d86).

If I do following change the bug goes away:

- ml := reverse(monomials(up))
+ ml := monomials(up)

Don't know why though.

On 3/24/20 4:03 AM, 'Nasser M. Abbasi' via FriCAS - computer algebra

> --
> You received this message because you are subscribed to the Google
> Groups "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to fricas-devel...@googlegroups.com
> <mailto:fricas-devel...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/26d92ddd-56c9-4514-bb30-a05dd0a02ad4%40googlegroups.com
> <https://groups.google.com/d/msgid/fricas-devel/26d92ddd-56c9-4514-bb30-a05dd0a02ad4%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Waldek Hebisch]

On Wed, Mar 25, 2020 at 06:51:59PM +0800, oldk1331 wrote:
> Thanks for your report.
>
> This bug is a regression between 1.3.5 and 1.3.6.
> It's introduced in r2586

> (https://github.com/fricas/fricas/commit/aacdddd3e2ecbb4e34f5cfa473f19c9333=
> 623d86).
<snip>

> On 3/24/20 4:03 AM, 'Nasser M. Abbasi' via FriCAS - computer algebra
> system wrote:
> > Could someone please explain why this call to integrate fails first
> > time, but works second time?
> >

> > (1) -> setSimplifyDenomsFlag(true)

> > (2) -> integrate((b*x + a)^(3/2)*(d*x + c)^(5/2)/x^7,x)
> >
> > >> Error detected within library code:
> > "failed" of mode
> > Union(SparseUnivariatePolynomial(Expression(Integer)),"failed") cannot
> > be coerced to mode SparseUnivariatePolynomial(Expression(Integer))

Error is detected in 'split' in MONOTOOL. The actual error is
in 'gcd': first 'gcd' returns wrong result, it gives 1 while
polynomial has multiple factors. The second 'gcd' looks is OK.

It is not clear if change above introduced bug, it is more
likely that it merely triggered already present bug.

--
Waldek Hebisch

[oldk1331]

Yes, you are right, when I was comparing function call traces from the diff,

the first call difference (in the wrong version) is that the argument to 'map' is 1

instead of an expression.

So this diff should exposed a bug.

On Fri, Mar 27, 2020, 11:25 PM Waldek Hebisch <heb...@math.uni.wroc.pl> wrote:

Error is detected in 'split' in MONOTOOL.  The actual error is
in 'gcd': first 'gcd' returns wrong result, it gives 1 while
polynomial has multiple factors.  The second 'gcd' looks is OK.

It is not clear if change above introduced bug, it is more
likely that it merely triggered already present bug.

--
                              Waldek Hebisch

--
You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.

To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20200327152537.GA9372%40math.uni.wroc.pl.

[Waldek Hebisch]

On Mon, Mar 23, 2020 at 01:03:06PM -0700, 'Nasser M. Abbasi' via FriCAS - computer algebra system wrote:
> Could someone please explain why this call to integrate fails first time,
> but works second time?
>
> Running 1.3.6 on Linux Manjaro under Virtual box
>

> (1) -> setSimplifyDenomsFlag(true)
>
> (1) false
> Type:
> Boolean
> (2) -> integrate((b*x + a)^(3/2)*(d*x + c)^(5/2)/x^7,x)
>
> >> Error detected within library code:
> "failed" of mode
> Union(SparseUnivariatePolynomial(Expression(Integer)),"failed") cannot be
> coerced to mode SparseUnivariatePolynomial(Expression(Integer))

The failure was due to wrong GCD. GCD routine substitutes
(pseudo)-random numbers in place of parameters and it
did not notice that substitution resulted in division by
zero, hence nonsense result. Second run used different
(pseudo)-random numbers, so problem did not appear.
When you start FriCAS (pseudo)-random number generator
starts in the same state, so failure is reprducible.

This is relatively new bug, it was introduced about 5 years
ago and exposed by recent change to order of computations
(whcih chanded usage pattern of random number generator.

--
Waldek Hebisch

[Waldek Hebisch]

This is different bug, factorization routine did inadequate checks
for bad reduction. Again due to use of pseudo-random numbers
second run did not hit the problem. AFAICS this is old bug,
more than 30 years old.

--
Waldek Hebisch