fyi, a new CAS integration file added. IntegrateAlgebraic

80 views
Skip to first unread message

Nasser M. Abbasi

unread,
Aug 26, 2021, 5:24:26 AM8/26/21
to
fyi;

A new test file was added to CAS integration tests. Currently it is build
as separate test. In the future it will be added to main report. This is now
test file #209.

https://www.12000.org/my_notes/CAS_integration_tests/index.htm
https://www.12000.org/my_notes/CAS_integration_tests/reports/summer_2021/test_cases/9_Blake_problems/report.htm

This test file contains 3,154. These integration problems were
provided thanks to Sam Blake author of IntegrateAlgebraic.

The following is link to test results

The following systems were tested on this file:

1. Mathematica 12.3.1 (64 bit) on windows 10.
2. Rubi 4.16.1 in Mathematica 12.3.1 on windows 10.
3. Maple 2021.1 (64 bit) on windows 10.
4. Maxima 5.44 on Linux. (via sagemath 9.3)
5. Fricas 1.3.7 on Linux (via sagemath 9.3)
6. Giac/Xcas 1.7 on Linux. (via sagemath 9.3)
7. Sympy 1.8 under Python 3.8.8 using Anaconda distribution on Ubuntu.
8. Mupad using Matlab 2021a with Symbolic Math Toolbox Version 8.7
9. IntegrateAlgebraic under Mathematica 12.3.1 on windows 10.
https://github.com/stblake/algebraic_integration August 23, 2021 version.

Results and statistics are given in the above link in PDF and HTML format.

Any problems, please let me know.

--Nasser

nob...@nowhere.invalid

unread,
Aug 26, 2021, 12:49:54 PM8/26/21
to

"Nasser M. Abbasi" schrieb:
And these are the results from the 2nd link:

System Solved Failed
--------------------------------------------------
IntegrateAlgebraic %99.11 (3126) % 0.89 (28)
Fricas %69.44 (2190) %30.56 (964)
Mathematica %69.18 (2182) %30.82 (972)
Rubi %64.49 (2034) %35.51 (1120)
Maple %56.21 (1773) %43.79 (1381)
Mupad %25.68 (810) %74.32 (2344)
Giac %24.57 (775) %75.43 (2379)
Maxima %18.07 (570) %81.93 (2584)
Sympy %17.34 (547) %82.66 (2607)
--------------------------------------------------

FriCAS comes in second in front of MMA - by a narrow margin. Maple
rates only fifth - was its Trager method really activated? And SymPy
comes in last as usual - though not far behind Maxima here.

Martin.

Nasser M. Abbasi

unread,
Aug 30, 2021, 6:36:35 PM8/30/21
to
On 8/26/2021 11:56 AM, clicl...@freenet.de wrote:
>

> And these are the results from the 2nd link:
>
> System Solved Failed
> --------------------------------------------------
> IntegrateAlgebraic %99.11 (3126) % 0.89 (28)
> Fricas %69.44 (2190) %30.56 (964)
> Mathematica %69.18 (2182) %30.82 (972)
> Rubi %64.49 (2034) %35.51 (1120)
> Maple %56.21 (1773) %43.79 (1381)
> Mupad %25.68 (810) %74.32 (2344)
> Giac %24.57 (775) %75.43 (2379)
> Maxima %18.07 (570) %81.93 (2584)
> Sympy %17.34 (547) %82.66 (2607)
> --------------------------------------------------
>
> FriCAS comes in second in front of MMA - by a narrow margin. Maple
> rates only fifth - was its Trager method really activated? And SymPy
> comes in last as usual - though not far behind Maxima here.
>
> Martin.
>

Hello Matrin;

>>was its Trager method really activated?

I really do not know. I looked at help in

https://de.maplesoft.com/support/help/maple/view.aspx?path=int%2fmethods

and it says

"The indefinite integration polyalgorithm in Maple is
not formulated as a single pass through a list of integration
methods. However, the method option can be used get
access to some of the individual integration algorithms
used as part of the integration process. The supported values
for indefinite integration are below. They can be given as names
or strings and are not case sensitive.

method=_DEFAULT is equivalent to not specifying a method,
exactly like definite and numeric integration."

So using int(integrand,x) is like using int(integrand,x,method=_DEFAULT)

But it does not say which method(s) it uses in this case. It does
not sound Maple tries Trager:

"Trager applies the Risch-Trager algorithm for the
integration of a pure algebraic function" by default.

But may be someone who knows Maple better than me can
answer your question.

--Nasser

nob...@nowhere.invalid

unread,
Aug 31, 2021, 12:00:43 PM8/31/21
to

"Nasser M. Abbasi" schrieb:
>
> On 8/26/2021 11:56 AM, clicl...@freenet.de wrote:
>
> > And these are the results from the 2nd link:
> >
> > System Solved Failed
> > --------------------------------------------------
> > IntegrateAlgebraic %99.11 (3126) % 0.89 (28)
> > Fricas %69.44 (2190) %30.56 (964)
> > Mathematica %69.18 (2182) %30.82 (972)
> > Rubi %64.49 (2034) %35.51 (1120)
> > Maple %56.21 (1773) %43.79 (1381)
> > Mupad %25.68 (810) %74.32 (2344)
> > Giac %24.57 (775) %75.43 (2379)
> > Maxima %18.07 (570) %81.93 (2584)
> > Sympy %17.34 (547) %82.66 (2607)
> > --------------------------------------------------
> >
> > FriCAS comes in second in front of MMA - by a narrow margin. Maple
> > rates only fifth - was its Trager method really activated? And SymPy
> > comes in last as usual - though not far behind Maxima here.
> >
>
> >>was its Trager method really activated?
>
> I really do not know. I looked at help in
>
> https://de.maplesoft.com/support/help/maple/view.aspx?path=int%2fmethods
>
> and it says
>
> "The indefinite integration polyalgorithm in Maple is
> not formulated as a single pass through a list of integration
> methods. However, the method option can be used get
> access to some of the individual integration algorithms
> used as part of the integration process. The supported values
> for indefinite integration are below. They can be given as names
> or strings and are not case sensitive.
>
> method=_DEFAULT is equivalent to not specifying a method,
> exactly like definite and numeric integration."
>
> So using int(integrand,x) is like using int(integrand,x,method=_DEFAULT)
>
> But it does not say which method(s) it uses in this case. It does
> not sound Maple tries Trager:
>
> "Trager applies the Risch-Trager algorithm for the
> integration of a pure algebraic function" by default.
>
> But may be someone who knows Maple better than me can
> answer your question.
>

In his manuscript "A Simple Method for Computing Some Pseudo-Elliptic
Integrals in Terms of Elementary Functions" (arXiv:2004.04910v2), Sam
Blake found Maple's Trager method to solve 91.6% of his test suite of
190 algebraic integrals. So the 56.2% you obtained on a larger suite of
3154 algebraics are surprisingly few.

When, in your last run of the full Rubi suite, Maple improved beyond
FriCAS on the Timofeev integrals, that looked to me like a result of
Maple automatically fielding Trager's method on purely algebraic
integrands. But this interpretation may have been premature.

The point may be settled by having Maple recompute the integrals with
"method = Trager" instead of your implicit "method = _DEFAULT", or
presumably much faster with "method = [_DEFAULT, Trager]".

Martin.

Nasser M. Abbasi

unread,
Aug 31, 2021, 12:27:55 PM8/31/21
to
On 8/31/2021 11:07 AM, clicl...@freenet.de wrote:

>
> In his manuscript "A Simple Method for Computing Some Pseudo-Elliptic
> Integrals in Terms of Elementary Functions" (arXiv:2004.04910v2), Sam
> Blake found Maple's Trager method to solve 91.6% of his test suite of
> 190 algebraic integrals. So the 56.2% you obtained on a larger suite of
> 3154 algebraics are surprisingly few.
>
> When, in your last run of the full Rubi suite, Maple improved beyond
> FriCAS on the Timofeev integrals, that looked to me like a result of
> Maple automatically fielding Trager's method on purely algebraic
> integrands. But this interpretation may have been premature.
>
> The point may be settled by having Maple recompute the integrals with
> "method = Trager" instead of your implicit "method = _DEFAULT", or
> presumably much faster with "method = [_DEFAULT, Trager]".
>
> Martin.
>

What I can do is this. Run Maple with all its methods, using the
option "method=_RETURNVERBOSE" which tries all its methods and
then pick the result that passes but the with lowest leafsize.
When there is a tie, will pick the first one.

For an example, I can change Maple test to do

sol:=int(x/(x^2-1)^(1/4),x,method=_RETURNVERBOSE)

Which gives

sol := ["gosper" = 2/3*(x - 1)*(x + 1)/(x^2 - 1)^(1/4),
"derivativedivides" = 2/3*(x^2 - 1)^(3/4),
"default" = 2/3*(x^2 - 1)^(3/4),
"trager" = 2/3*(x^2 - 1)^(3/4),
"meijerg" = 1/2*(-signum(x^2 - 1))^(1/4)*x^2*hypergeom([1/4, 1], [2], x^2)/signum(x^2 - 1)^(1/4),
"risch" = 2/3*(x^2 - 1)^(3/4),
FAILS = ("lookup", "norman", "elliptic")]

If this sounds OK with everyone, I can do the above and re-run the

summer_2021/test_cases/9_Blake_problems

test and see if Maple result improves or not.

regards,
--Nasser

nob...@nowhere.invalid

unread,
Aug 31, 2021, 1:10:04 PM8/31/21
to

"Nasser M. Abbasi" schrieb:
This should improve some leaf counts at the cost of increasing all
execution times. Using "method = [_DEFAULT, Trager]" won't improve any
leaf count but keep Maple's execution times fast.

Nasser's question, however, is to everyone ...

Martin.

Nasser M. Abbasi

unread,
Sep 1, 2021, 1:58:30 PM9/1/21
to
On 8/31/2021 12:16 PM, clicl...@freenet.de wrote:

>
> This should improve some leaf counts at the cost of increasing all
> execution times. Using "method = [_DEFAULT, Trager]" won't improve any
> leaf count but keep Maple's execution times fast.
>
> Nasser's question, however, is to everyone ...
>
> Martin.
>

I just finished re-running the 3154 problems in

<https://www.12000.org/my_notes/CAS_integration_tests/reports/summer_2021/test_cases/9_Blake_problems/report.htm>

Just on Maple, by adding

method = default,trager]

to the int commandm, to see if the score improves.

The score for Maple went down!

It was %56.21 pass befor, and now it scored %54.72. Which is very
strange. Looking at it more, this looks like a bug in Maple. Here
is an example

int((-5+2*x)/(x^2-4*x+4)^(1/4),x)
2/3*(x - 2)*(2*x - 7)/(x^2 - 4*x + 4)^(1/4)

int((-5+2*x)/(x^2-4*x+4)^(1/4),x,method=[default,trager])

returns unevaluated.

If one is using ONE method only, then the syntax is that
method name is UpperCase. But when using more than one
method, I found that only lower case works. So this fails

int((-5+2*x)/(x^2-4*x+4)^(1/4),x,method=[_DEFAULT,Trager])
Error, (in IntegrationTools:-Indefinite) unknown indefinite integration method _DEFAULT

but this works

int((-5+2*x)/(x^2-4*x+4)^(1/4),x,method=_DEFAULT)
2/3*(x - 2)*(2*x - 7)/(x^2 - 4*x + 4)^(1/4)

and this works (notice, now I had to use lower case)

int((-5+2*x)/(x^2-4*x+4)^(1/4),x,method=[default,trager])

No error and it works on many integrals, but now there are
few integrals where Maple returns unevaluated even
though it works when using default!

Help says

"method=[method1, method2, etc] combines methods. If the methods
are integrators, then each is tried in sequence. If the methods
are all of the form NoIntegrator then they are each removed
from the default integration sequence. A list with one
method or a list combining Integrator and NoIntegrator methods
is not particularly useful, but both are supported. _UNEVAL
overrides any other methods it might be combined with
and _DEFAULT is overridden by any other methods."

Maple help has always been hard to follow for me, and there are no
examples to help one better understand it. So I will leave the test
as is, unless someone else knows why it fails in this example,
and if the syntax should be something else.

The method option was updated in Maple 2021.

I am using Maple 2021.1 on windows 10.

--Nasser

Nasser M. Abbasi

unread,
Sep 1, 2021, 2:19:04 PM9/1/21
to
fyi, here is another what looks like a bug in Trager

int((1+2*x+3^(1/2))/(1+2*x-3^(1/2))/(-1+4*x^4-4*3^(1/2)*x^2)^(1/2),x,method=Trager)
Error, (in IntegrationTools:-Indefinite) invalid argument for sign, lcoeff or tcoeff

int((1+2*x+3^(1/2))/(1+2*x-3^(1/2))/(-1+4*x^4-4*3^(1/2)*x^2)^(1/2),x,method=_DEFAULT)

sqrt(1 - (-4 - 2*sqrt(3))*x^2)*sqrt(1 - (-2*sqrt(3) + 4)*x^2)*EllipticF(x*(I + sqrt(3)*I), sqrt(1 - sqrt(3)*(-2*sqrt(3) + 4))*I)/((I + sqrt(3)*I)*sqrt(4*x^4 - 1 - 4*sqrt(3)*x^2)) + 2*sqrt(3)*(-1/4*arctanh(1/2*(-4*sqrt(3)*(1/2*sqrt(3) - 1/2)^2 - 2 - 4*sqrt(3)*x^2 + 8*x^2*(1/2*sqrt(3) - 1/2)^2)/(sqrt(4*(1/2*sqrt(3) - 1/2)^4 - 4*sqrt(3)*(1/2*sqrt(3) - 1/2)^2 - 1)*sqrt(4*x^4 - 1 - 4*sqrt(3)*x^2)))/sqrt(4*(1/2*sqrt(3) - 1/2)^4 - 4*sqrt(3)*(1/2*sqrt(3) - 1/2)^2 - 1) - 1/2*sqrt(1 - (-4 - 2*sqrt(3))*x^2)*sqrt(1 - (-2*sqrt(3) + 4)*x^2)*EllipticPi(sqrt(-4 - 2*sqrt(3))*x, 1/((-4 - 2*sqrt(3))*(1/2*sqrt(3) - 1/2)^2), sqrt(-2*sqrt(3) + 4)/sqrt(-4 - 2*sqrt(3)))/(sqrt(-4 - 2*sqrt(3))*(1/2*sqrt(3) - 1/2)*sqrt(4*x^4 - 1 - 4*sqrt(3)*x^2)))

Maple 2021.1, windows 10.


anti...@math.uni.wroc.pl

unread,
Sep 1, 2021, 8:45:44 PM9/1/21
to
Have you tried

int((-5+2*x)/(x^2-4*x+4)^(1/4),x,method=trager)

> and this works (notice, now I had to use lower case)
>
> int((-5+2*x)/(x^2-4*x+4)^(1/4),x,method=[default,trager])

AFAICS _DEFAULT is different than default. Your previous post
indicates that default is just one of several possible methods.
_DEFAULT is collection of _all_ methods run by default (maybe
even all).

--
Waldek Hebisch

Nasser M. Abbasi

unread,
Sep 1, 2021, 9:22:56 PM9/1/21
to
yes, I tried it, but it returns unevaluated

int((-5+2*x)/(x^2-4*x+4)^(1/4),x,method=trager)

same input is echoed back. Same using method=Trager

>> and this works (notice, now I had to use lower case)
>>
>> int((-5+2*x)/(x^2-4*x+4)^(1/4),x,method=[default,trager])
>
> AFAICS _DEFAULT is different than default. Your previous post
> indicates that default is just one of several possible methods.
> _DEFAULT is collection of _all_ methods run by default (maybe
> even all).
>
>

So should I run Maple using _DEFAULT method to force it to use
all methods? That is what I suggested before but by using

"method=_RETURNVERBOSE applies all of the known methods
and reports the results for each."

So it looks that it is similar to _DEFAULT:

"method=_DEFAULT forces use of the default integration method. It runs
all of the integrators in sequence and returns the first answer found."

The only difference is that _DEFAULT automatically returns the first
answer found while _RETURNVERBOSE runs all method even if an answer was
already found.

The nice thing about _RETURNVERBOSE is that one can see which method
was used for each answer. This can be useful to record.

But If I hear no objection from anyone, I will re-run Maple again
using _DEFAULT and see if the result improves?

regards,
--Nasser

anti...@math.uni.wroc.pl

unread,
Sep 2, 2021, 6:34:13 AM9/2/21
to
Probably better to use _RETURNVERBOSE, then it will be clear
which method worked.

--
Waldek Hebisch

nob...@nowhere.invalid

unread,
Sep 2, 2021, 12:09:52 PM9/2/21
to

"Nasser M. Abbasi" schrieb:
>
> On 8/31/2021 12:16 PM, clicl...@freenet.de wrote:
>
> >
> > This should improve some leaf counts at the cost of increasing all
> > execution times. Using "method = [_DEFAULT, Trager]" won't improve
> > any leaf count but keep Maple's execution times fast.
> >
> > Nasser's question, however, is to everyone ...
> >
>
> [...]
>
> Help says
>
> "method=[method1, method2, etc] combines methods. If the methods
> are integrators, then each is tried in sequence. If the methods
> are all of the form NoIntegrator then they are each removed
> from the default integration sequence. A list with one
> method or a list combining Integrator and NoIntegrator methods
> is not particularly useful, but both are supported. _UNEVAL
> overrides any other methods it might be combined with
> and _DEFAULT is overridden by any other methods."
>
> Maple help has always been hard to follow for me, and there are no
> examples to help one better understand it. So I will leave the test
> as is, unless someone else knows why it fails in this example,
> and if the syntax should be something else.
>
> The method option was updated in Maple 2021.
>
> I am using Maple 2021.1 on windows 10.
>

According to this help paragraph, my proposal should be useless as
Maple simply replaces it by "method = Trager" (I had looked at the
options site but didn't notice these specifics). The slightly lower
score thus seems to bear out that Maple's Trager method can indeed
handle only roughly half of the 3154 algebraics.

Unfortunately, as quoted in an earlier post, the Maple people also
say that the "indefinite integration polyalgorithm in Maple is not
formulated as a single pass through a list of integration methods",
leaving open when Trager is called automatically and when not.

To examine if the Trager method is indeed systematically tried in the
_DEFAULT handling of all pure algebraics, it may be useful to also run
the tests with "method = _RETURNVERBOSE" (and the output postprocessed
suitably). I see that this is proposed by Waldek as well.

Martin.

nob...@nowhere.invalid

unread,
Sep 2, 2021, 12:10:11 PM9/2/21
to

"Nasser M. Abbasi" schrieb:
>
> [...]
>
> "method=_DEFAULT forces use of the default integration method. It
> runs all of the integrators in sequence and returns the first answer
> found."
>

Nooo! This paragraph applies to Definite Integration only. As quoted
already, the paragraph for Indefinite Integration reads: "The
indefinite integration polyalgorithm in Maple is not formulated as a
single pass through a list of integration methods [...]".

Martin.

Nasser M. Abbasi

unread,
Sep 3, 2021, 2:21:43 PM9/3/21
to
On 9/2/2021 11:16 AM, clicl...@freenet.de wrote:

> To examine if the Trager method is indeed systematically tried in the
> _DEFAULT handling of all pure algebraics, it may be useful to also run
> the tests with "method = _RETURNVERBOSE" (and the output postprocessed
> suitably). I see that this is proposed by Waldek as well.
>
> Martin.
>

I am rebuilding Maple tests now and will see what it will do
with _RETURNVERBOSE.

But _RETURNVERBOSE seem to have some bugs. It is new in 2021. Here
is one example I found.

-------------------
restart;
integrand:=cos(x)*(-cos(x)^2+2*(1+2*sin(x))^(1/4))/(1+2*sin(x))^(3/2);
int(integrand,x,method=_RETURNVERBOSE);

[FAILS = ("gosper", "lookup", "derivativedivides", "default",
"norman", "trager", "meijerg", "risch", "elliptic")]

But

int(integrand,x);

1/3*(sin(x)^2 - 2*sin(x) - 12*(1 + 2*sin(x))^(1/4) + 1)/sqrt(1 + 2*sin(x))

I do not understand how the above could be possible. Why would it not
give a result when trying ALL methods, but it gives result otherwise?

I send bug report on the above to maplesoft.

Maple 2021.1 on windows 10.
--Nasser

Nasser M. Abbasi

unread,
Sep 3, 2021, 5:04:07 PM9/3/21
to
I am starting to think that int() with method=_RETURNVERBOSE is not a
superset that includes the result obtained when just using int()

Here is another strange result that I do not understand

===================
restart;
integrand:=sin(x)/(1+sin(x));
int(integrand,x,method=_RETURNVERBOSE);

["default" = 2*arctan(tan(1/2*x)) + 2/(tan(1/2*x) + 1),
"norman" = (x + x*tan(1/2*x) + x*tan(1/2*x)^2 + x*tan(1/2*x)^3 + 2*tan(1/2*x)^2 + 2)/((1 + tan(1/2*x)^2)*(tan(1/2*x) + 1)),
"risch" = x + 2/(exp(x*I) + I),
FAILS = ("gosper", "lookup", "derivativedivides", "trager", "meijerg", "elliptic")]
============

But

int(integrand,x);

2/(tan(1/2*x) + 1) + x

And the above result is not one of the results obtained when
using method=_RETURNVERBOSE, but I think the "default" result could
be simplified to it with some assumptions on x.

I would have expected the result from just using int() to match
exactly the "default" output from _RETURNVERBOSE, or at least match one
of its methods.

So it seems that _RETURNVERBOSE is doing something else or extra, other
than just calling "default" in addition to all the other integration methods.

This has an effect on the grading of the anti-derivatives also. The grading
of int() in this example gets an A, but the grading from _RETURNVERBOSE got
a B, since its leaf size twice as big as than optimal.

Maple 2021.1

--Nasser

nob...@nowhere.invalid

unread,
Sep 4, 2021, 2:21:44 PM9/4/21
to

"Nasser M. Abbasi" schrieb:
Good grief! But you already found that Maple's int() without option
integrates 56.21 percent of the 3154 algebraics, and with the "method
= Trager" option integrates 54.72 percent of them. Such a difference is
to be expected if _DEFAULT integration tries some simpler methods first
and then passes any incalcitrant algebraic to the Trager algorithm.

If "_DEFAULT" means no integrator option, which invokes a fairly
comprehensive suite of integrators, whereas "default" = "Default"
invokes just some quick and simple integrator, I propose to rename the
"_DEFAULT" option to "Native" or somesuch, and to reject the input of
"_DEFAULT".

Martin.

anti...@math.uni.wroc.pl

unread,
Sep 17, 2021, 5:41:47 PM9/17/21
to
Nasser M. Abbasi <n...@12000.org> wrote:
I puzzled by some FriCAS results in your report.

2: I get

integrate((3*x^2+1)/(x^3+x-1)^(1/2),x)

+----------+
| 3
(8) 2 \|x + x - 1
Type: Union(Expression(Integer),...)
Time: 0.00 (EV) + 0.01 (OT) = 0.02 sec

you report timeout.

2892:

integrate(1/((-1+2*x)^(1/2)*(4+3*x)+(1+x)*(-3+4*x)^(1/2)),x)

You report timeout, for me it gives largish result in about 0.3 second.

--
Waldek Hebisch

Nasser M. Abbasi

unread,
Sep 17, 2021, 7:37:15 PM9/17/21
to
On 9/17/2021 4:41 PM, anti...@math.uni.wroc.pl wrote:

>> Results and statistics are given in the above link in PDF and HTML format.
>>
>> Any problems, please let me know.
>
> I puzzled by some FriCAS results in your report.
>
> 2: I get
>
> integrate((3*x^2+1)/(x^3+x-1)^(1/2),x)
>
> +----------+
> | 3
> (8) 2 \|x + x - 1
> Type: Union(Expression(Integer),...)
> Time: 0.00 (EV) + 0.01 (OT) = 0.02 sec
>
> you report timeout.
>
> 2892:
>
> integrate(1/((-1+2*x)^(1/2)*(4+3*x)+(1+x)*(-3+4*x)^(1/2)),x)
>
> You report timeout, for me it gives largish result in about 0.3 second.
>

I suspect this happens sometimes due to overload. I was running
many things on Linux, which runs inside VBox inside windows 10 host.

When things run short of memory and cpu near 100%, Vbox gets
too slow.

Unfortunately, Sagemath has no build-in timeout on a function call,
as with Mathematica or Maple, so I have to use a wall clock timer
(not CPU consumed timer) of 3 minutes for the task to complete.

Each task runs one integrate problem and completes. It seems
occasionally when the PC is overloaded, the 3 minutes expires
before the task doing the integrate is completed because
it did not get the chance to use the CPU as much due to
scheduling overloading.

I am rerunning Fricas now on its own in Vbox, and these 2 problems
did not time out now. It will take another 1-2 days for me to update
the web page with new result.

The way I do timeout on Linux using sagemath script is this
this loops over all integration problem in one file:

=========================
theQueue = Queue()
theQueue.put([item[0], item[1],item[3]]) #integrand, variable, optimal
process = Process(group=None,target=doTheIntegration, args=(theQueue,))
process.start()
process.join(3*60) #clock set at 3 minutes

if process.exitcode == None or process.is_alive():
print ("process did not terminate. Kill it. Timed out")#timed out!
process.terminate()
result = -1
grade = "F(-1)"
anti_in_latex = "\\text{Timed out}"
else:
anti = theQueue.get() #get the result, did not time out

del(theQueue)
=====================

I need to get myself a new PC with many more and faster cores
and more RAM or a separate Linux powerful PC for these tests. I will
also now add more RAM to the VBox, and change its settings to use "4"
processors in the Oracle VBox manager configuration instead of the
current "2".

Hopefully this will help elminate such rare false timeouts when PC is
very busy.

--Nasser

anti...@math.uni.wroc.pl

unread,
Sep 18, 2021, 9:22:39 PM9/18/21
to
Nasser M. Abbasi <n...@12000.org> wrote:
Thanks for info. I looked at few other cases and AFAICS in
those cases timeout was justified. So I do not expect
significant change to results. For me it is more important
to understand what happened.

> The way I do timeout on Linux using sagemath script is this
> this loops over all integration problem in one file:
>
> =========================
> theQueue = Queue()
> theQueue.put([item[0], item[1],item[3]]) #integrand, variable, optimal
> process = Process(group=None,target=doTheIntegration, args=(theQueue,))
> process.start()
> process.join(3*60) #clock set at 3 minutes
>
> if process.exitcode == None or process.is_alive():
> print ("process did not terminate. Kill it. Timed out")#timed out!
> process.terminate()
> result = -1
> grade = "F(-1)"
> anti_in_latex = "\\text{Timed out}"
> else:
> anti = theQueue.get() #get the result, did not time out
>
> del(theQueue)
> =====================

I wonder if this is responsible for longer runtimes that you
see. FYI, the 10335 cases exp-log file, when run as I indicated
took 747 seconds on my slow machine (1.6 GHz Celeron). However
first example took 2.07 sec, second 0.44 sec which is much above
average. In fact only 6 case take more than 1 second and there are
only 7 cases that take between 0.4 and 1 second. First example
is expected to take longer because it is performing delayed
startup initialization. It is likely that also second
example pays some initialization cost, once things are
initialized computation works with normal speed. Really
long runs may accumulate garbage, but this is not a problem
with exp-log file.

I understand that for batch runs you want timeout and you have
various scripts. However it would be nice if you could compare
for small semi-random sample (say 20 examples) times that you get
from your setup and times that you get from FriCAS time report
using FriCAS command line.

--
Waldek Hebisch

Nasser M. Abbasi

unread,
Sep 19, 2021, 12:27:43 AM9/19/21
to
Fricas is called from sagemath. The call to Fricas is made from
the child process that is created in the script above
in order to do the timeout.

The child process, calls fricas integrate. Sagemath now creates
another NEW Linux process to run Fricas in it. So the following
call, from the child process (made from function defined
by target=doTheIntegration not shown above) does this

integrate(5,x, algorithm="fricas")

The above call, made from the child process creates yet
another new process to run Fricas. (child process of the child process)

Once the above command is completed, the Fricas process terminates,
when the the child process terminates and returns back to
the script mainline:

process.start() #this makes child process to call Fricas integrate
process.join(3*60) #wait for the child, 3 minutes only

This has to be done in 3 minutes.

So for each integral, 2 processes are created.

But the timing recorded, to time the integral, is only for the integrate
command. i.e.

clock starts here
integrate(5,x, algorithm="fricas")
clock ends here

However, this time includes starting a new fricas process each time.

So, yes, it will take more time, than if the call was made from
inside a fricas process of course. All the overheads of starting
a new Linux process, and Fricas initialization and any
sagemath<--->Fricas API translation and process to process communication
is added each time and for each integral call.

I am afraid there is no other way I know about to set a timeout
on a call to integrate in sagemath, other than the above. I asked
about this before

https://ask.sagemath.org/question/50331/can-one-now-set-a-timelimit-on-operation-in-sagemath/
https://ask.sagemath.org/question/42644/timeout-does-not-work-with-maxima-ok-with-others/

But solutions given were not practical to use. The solution I use now
works but will add extra time for the integrate, yes.

> I understand that for batch runs you want timeout and you have
> various scripts. However it would be nice if you could compare
> for small semi-random sample (say 20 examples) times that you get
> from your setup and times that you get from FriCAS time report
> using FriCAS command line.
>

I am sure using Fricas directly, the timing will be much less,
since there are no overheads of starting new Fricas process
for each integrate call in the loop. I am just not good
at writing Fricas scripts.

Best regards,
--Nasser

Dr Huang

unread,
Oct 22, 2021, 9:25:32 PM10/22/21
to
Which system can integrate(x^x,x)?
May I suggest you add MathHand.com to test?
10. MathHand.com

nob...@nowhere.invalid

unread,
Oct 23, 2021, 1:31:01 PM10/23/21
to

Dr Huang schrieb:
>
> [...]
>
> Which system can integrate(x^x,x)?
>
> [...]

Derive 6.10 returns INT(x^x, x) unevaluateed.

Martin.
Reply all
Reply to author
Forward
0 new messages