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.
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.
was its Trager method really activated?
On 8/26/2021 11:56 AM, clicliclic@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.
On 8/31/2021 11:07 AM, clicliclic@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.
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.
On 8/31/2021 12:16 PM, clicliclic@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])
Nasser M. Abbasi <nma@12000.org> wrote:
On 8/31/2021 12:16 PM, clicliclic@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)
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).
On 9/1/2021 7:45 PM, antispam@math.uni.wroc.pl wrote:
Nasser M. Abbasi <nma@12000.org> wrote:
On 8/31/2021 12:16 PM, clicliclic@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)
Have you tried
int((-5+2*x)/(x^2-4*x+4)^(1/4),x,method=trager)
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?
[...]
"method=_DEFAULT forces use of the default integration method. It
runs all of the integrators in sequence and returns the first answer
found."
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.
On 9/2/2021 11:16 AM, clicliclic@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
On 9/3/2021 1:21 PM, Nasser M. Abbasi wrote:
On 9/2/2021 11:16 AM, clicliclic@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
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
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.
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.
On 9/17/2021 4:41 PM, antispam@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)
=====================
Nasser M. Abbasi <nma@12000.org> wrote:
On 9/17/2021 4:41 PM, antispam@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.
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.
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
[...]
Which system can integrate(x^x,x)?
[...]
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 286 |
Nodes: | 16 (2 / 14) |
Uptime: | 87:33:13 |
Calls: | 6,496 |
Calls today: | 7 |
Files: | 12,100 |
Messages: | 5,277,163 |