FYI, CAS independent integration tests, summer 2022 edition online

[Nasser M. Abbasi]

FYI,

A new CAS integration test build started. This is summer 2022 edition.

<https://www.12000.org/my_notes/CAS_integration_tests/reports/summer_2022/index.htm>

It will take 2-3 more months to complete but I am posting this now
in case there are problems or suggestions so I can do them early one.

The following is summary of changes in this summer 2022
compared to 2021 edition are
============================
1. This now includes 85,483 integrals compared to 71,994.
The test integrals used are made of the following 210 files:
a. Rubi test suite. Files 1 to 208. Thanks to Alert Rich.
Downloaded from <https://github.com/RuleBasedIntegration>
b. IntegrateAlgebraic test file. File 209. Thanks to Sam Blake.
c. Fricas test file. File 210. Thanks to Waldek Hebisch.

2. CAS version changes: Mathematica 12.3->13.01, Maple 2021.1->2022.1,
Giac 1.7.0->1.9.07, Sympy 1.8->1.10.1. Maxima 5.44->5.46.
No changes to FriCAS at 1.3.7, Mupad at 2021a, Rubi at 4.16.1.

3. New CAS added: Mathics 4.0 called from sagemath.
Mathics is an open source CAS which uses Mathematica syntax.
<https://mathics.org/>
It was possible to add it easily to CAS integration tests since
it can now be called from inside sagemath 9.6.
<https://doc.sagemath.org/html/en/reference/interfaces/sage/interfaces/mathics.html>
Mathics integrator seems to rely on sympy integrator for some of
its work but I do not know to what extent. This explains the similar
anti-derivatives compared to sympy and the similar overall performance and
result.

4. A new program to test GIAC directly using its C++ API.
<https://www-fourier.ujf-grenoble.fr/~parisse/giac_us.html>
This resulted in much faster execution and also avoids any sagemath
interface issues found so far. FriCAS and Maxima and Mathics still
use sagemath. Now GIAC has now become one of the fastest CAS's to complete
after this change. (Compiled C++ is fast!)

5. Updated sagemath from 9.3 to 9.6.

6. General improvements to Latex and other formatting.

7. Updated design flowchart of the test program to show the changes made.
<https://www.12000.org/my_notes/CAS_integration_tests/images/design.svg>

Currently only first [3,809] integrals are completed and graded
(first 13 files). Results are at the above webpage. Will not post these here as
current results will change until all files are processed.

All systems are graded except for mupad. Verification is done
for only Rubi, Mathematica and Mathics. Integrals which
produce result that did not verify are listed with direct
links for easy inspection.

I will update the web page as soon as more files are processed. May be once
every 2-3 weeks (unless a big problem shows up) until all 210 files
are completed.

The reports are written in Latex and converted to PDF using lualatex
and converted to HTML using tex4ht, all using TeXLive 2022 on Linux.

Any problems/questions/changes needed, please let me know. You could
email me directly or by posting here.

--Nasser

[nob...@nowhere.invalid]

"Nasser M. Abbasi" schrieb:

On the page <.../reports/summer_2022/indexchapter1.htm#x2-10001> in the
table under 1.2.1 ("Time and leaf size Performance") I think you should
document your definition of "Normalized mean" and "Normalized median".
What is devided by what, and is the mean or median computed before or
after the normalization?

Could the addition of the Sam Blake and Waldek Hebisch test files
affect the overall performance statistics significantly?

Martin.

[Nasser M. Abbasi]

On 6/7/2022 1:03 AM, clicl...@freenet.de wrote:

> On the page <.../reports/summer_2022/indexchapter1.htm#x2-10001> in the
> table under 1.2.1 ("Time and leaf size Performance") I think you should
> document your definition of "Normalized mean" and "Normalized median".
> What is devided by what, and is the mean or median computed before or
> after the normalization?
>

Sure, will add these next build.

Mean size is the average leaf size produced by the CAS (before any
normalization). The Normalized mean is relative to the
mean size of the optimal anti-derivative given in the input files.

For example, if CAS has "Normalized mean" of 3, then
the mean size of its leaf is 3 times as large as
the mean size of the optimal.

Median size is value of leaf size where half the values
are larger than this and half are smaller (before any
normalization). i.e. The Middle value.

Similarly the "Normalized median" is relative to the median
leaf size of the optimal.

So if a CAS has Normalized median of 1.2, then its
median is 1.2 as large as the median leaf size of the optimal.

> Could the addition of the Sam Blake and Waldek Hebisch test files
> affect the overall performance statistics significantly?
>
> Martin.

It will change statistics for some CAS'es, but probably
not too much? Files 209 and 210 combined have about
13,500 integrals, while Rubi's test suite (files 1 .. 208)
have a total of 71,994. So this is about 18.75% increase.

Fyi, There were separate tests done before on just file 209 and 210
alone on my page, under section "Specialized integration tests"
but now these files are combined with the main build.

It is good to have more variations of input test files,
this insures more coverage of each CAS.

--Nasser

[nob...@nowhere.invalid]

"Nasser M. Abbasi" schrieb:

>
> On 6/7/2022 1:03 AM, clicl...@freenet.de wrote:
>
> > On the page <.../reports/summer_2022/indexchapter1.htm#x2-10001> in
> > the table under 1.2.1 ("Time and leaf size Performance") I think you
> > should document your definition of "Normalized mean" and "Normalized
> > median".
> > What is devided by what, and is the mean or median computed before
> > or after the normalization?
> >
>
> Sure, will add these next build.
>
> Mean size is the average leaf size produced by the CAS (before any
> normalization). The Normalized mean is relative to the
> mean size of the optimal anti-derivative given in the input files.
>
> For example, if CAS has "Normalized mean" of 3, then
> the mean size of its leaf is 3 times as large as
> the mean size of the optimal.
>
> Median size is value of leaf size where half the values
> are larger than this and half are smaller (before any
> normalization). i.e. The Middle value.
>
> Similarly the "Normalized median" is relative to the median
> leaf size of the optimal.
>
> So if a CAS has Normalized median of 1.2, then its
> median is 1.2 as large as the median leaf size of the optimal.
>
> > Could the addition of the Sam Blake and Waldek Hebisch test files
> > affect the overall performance statistics significantly?
> >
>

> It will change statistics for some CAS'es, but probably
> not too much? Files 209 and 210 combined have about
> 13,500 integrals, while Rubi's test suite (files 1 .. 208)
> have a total of 71,994. So this is about 18.75% increase.
>
> Fyi, There were separate tests done before on just file 209 and 210
> alone on my page, under section "Specialized integration tests"
> but now these files are combined with the main build.
>
> It is good to have more variations of input test files,
> this insures more coverage of each CAS.
>

Waldek's "Yet another integration test" suite consist's of 10,335
integrands obtained by differentiation of random functions. While there
is a natural number of tests in the Rubi suite - something like three
to five integrands for every leaf of its decision tree -, the number in
a random suite could be anything. In fact, Waldek might argue that
it should be increased to 71,994 integrands for the sake of fairness.

A natural limit would be reached if nothing new were learned about an
integrator's performance when the size is increased - say, if all of
the error messages from failures due to various unimplemented branches
of an integration algorithm have appeared three to five times already.
If there are no failures at all, only three to five tests should be
used to establish integrator function.

Is the present size of "Yet another integration test" too large or too
small for FriCAS by this measure? This could be found out with your
machinery as well as on FriCAS itself.

Martin.

[anti...@math.uni.wroc.pl]

Let me explain how I arrived at that number. When doing random
testing there is problem that different random sample will
give different result. Accuraccy of result is proportional
to square root of sample size. So to get about 1% accuracy
you need 10000 samples. 10335 is artifact of how I generated
them: I generated more and then dropped nonsense like log(0).

Now, concerning fairness note that this collection consists
of log-exp functions. Also, random functions tend to have
relatively large derivative. So we get relatively large
function to integrate giving smaller answer. This means
that integrand contains a lot of information making
integration easier. It could be argued that for
integration more interesting are cases when integrand
is smaller than in random cases. Both reasons means
that it would be inappropriate for those integrals to
dominate the testsuite.

> A natural limit would be reached if nothing new were learned about an
> integrator's performance when the size is increased - say, if all of
> the error messages from failures due to various unimplemented branches
> of an integration algorithm have appeared three to five times already.
> If there are no failures at all, only three to five tests should be
> used to establish integrator function.
>
> Is the present size of "Yet another integration test" too large or too
> small for FriCAS by this measure? This could be found out with your
> machinery as well as on FriCAS itself.

Let me note that by design this testsuite have very small number
of algeberic integrals. OTOH when exp-log function turns out
to be algebraic, it is usually rather complicated algebraic
function and small number of them is enough to hit few error
messages. Let me add that _all_ incompletness messages are
in algebraic part. For purely transcendental elementary
integrals FriCAS claim completness (full coverage) and for
integration in terms of special functions FriCAS may
return unvaluated results even if other interals in term
of given special function work. So no error messages about
unimplemented branches of procedure handling integration
in terms of special functions. Note that depending on point
of view, handling of special functions is between 20% and 40%
of FriCAS integration code.

--
Waldek Hebisch

[acer]

On Monday, June 6, 2022 at 4:36:00 AM UTC-4, Nasser M. Abbasi wrote:
> FYI,
>
> A new CAS integration test build started. This is summer 2022 edition.
>
> <https://www.12000.org/my_notes/CAS_integration_tests/reports/summer_2022/index.htm>

> [deleted]

The first column chart ("Antiderivative Grade distribution for each CAS") doesn't match the data in either Table 1.1 or Table 1.3.

[Nasser M. Abbasi]

I do not see any mis-match? The bar chart diagram
called "Antiderivative Grade distribution for each CAS"
shows the grade distribution in colors. As the diagram
says the numbers on the columns are the %passed and
not % of A grade. (it was hard to put % of each grade
on the bars, in right place, so used total % pass there).

Which agrees with Table 1.1: Percentage solved for each CAS result?


screen shot

https://12000.org/tmp/06142022/screen_shot.png

Or do you mean something else?

--Nasser

[acer]

It has been fixed since the time a few hours ago that I posted my message.

But for several days that bar chart showed the percentages after only about a few thousand tests had run. Ie, it was stuck at:
Mma 99.61%
Fricas 89.16%
Maple 87.63%
etc
The total number of tests run changed a few times over the past few days, but that very first bar chart did not.

In the past few hours it has changed, and the bar chart now matches the data in Table 1.1.

[Nasser M. Abbasi]

On 6/6/2022 3:35 AM, Nasser M. Abbasi wrote:
> FYI,
>
> A new CAS integration test build started. This is summer 2022 edition.
>
> <https://www.12000.org/my_notes/CAS_integration_tests/reports/summer_2022/index.htm>
>
> It will take 2-3 more months to complete but I am posting this now
> in case there are problems or suggestions so I can do them early one.
>

Fyi, This is update.

Due to new release of Mathematica 13.1 and Fricas 1.3.8
and giac 1.9.0-11 I had to start all over and build everything
with the new versions.

Currently files 1-12 (1892 integrals) just completed and uploaded.
Will be uploading more files as they finish in the coming weeks.

This is the current % solved result for the first 12 files
(summer 2022 edition). The (+) column shows how much
CAS result improved compared to last year test.

All CAS systems which changed version improved.
=========================================
Mathematica 13.1 99.21 % (+0.48 %)
Rubi 4.16.1/MMA 13.01 99 % (+0.69 %)
FriCAS 1.3.8/sage 9.6 95.4 % (+0.84 %)
Maple 2022.1 93.71 % (+0.21 %)
Giac 1.9-11/sage 9.6 86.58 % (+0.43 %)
Maxima 5.46/sage 9.6 82.03 % (+0.05 %)
Mupad Matlab 2021a 82.03 % (0.00 %)
Sympy 1.10.1/Python 3.10.4 73.1 % (+0.64 %)

(it is coincidence that Maxima and Mupad scored same on the first
12 files).

The following is summer 2021 result for the same first 12 files

% solved result for the first 12 files
===================================
Mathematica 12.3 98.73 %
Rubi 4.16.1/MMA 12 98.31 %
FriCAS 1.3.7/sage 9.3 94.56 %
Maple 2021.1 93.5 %
Giac 1.7/sage 9.3 86.15 %
Mupad Matlab 2021a 82.03 %
Maxima 5.44/sage 9.3 81.98 %
Sympy 1.8/Python 3.8.8 72.46 %

There is also now a regression report for each cas,
which shows integrals that failed in summer 2022 edition
but passed in summer 2021.

<https://www.12000.org/my_notes/CAS_integration_tests/reports/summer_2022/REGRESSION_REPORTS/index.htm>

This regression report will be updated as more files are processed.

The above result ofcourse is for small sample. Only the first 12
files (1892 integrals).

Will update as more files are processes. Total files are 211.
(85,483 integrals).

Any problems found, please let me know.

For CAS's that use sagemath (Fricas, Maxima, Giac), any failed
integral due to sagemath interface will have an F(-2) next to the
exception name. From the exception name one can see if the
exception was due to interface issue or it was generated
from the called CAS itself due to internal error.

Hopefully with sagemath 9.6, failed integrals due to
interface issues will be much less than earlier version
as many bugs have been fixed in sagemath interface.

--Nasser

[nob...@nowhere.invalid]

"Nasser M. Abbasi" schrieb:

> The above result of course is for small sample. Only the first 12

> files (1892 integrals).
>
> Will update as more files are processes. Total files are 211.
> (85,483 integrals).
>
> Any problems found, please let me know.
>
> For CAS's that use sagemath (Fricas, Maxima, Giac), any failed
> integral due to sagemath interface will have an F(-2) next to the
> exception name. From the exception name one can see if the
> exception was due to interface issue or it was generated
> from the called CAS itself due to internal error.

But didn't you write this on 6 June 2022, 03:35:55 -0500:

> 4. A new program to test GIAC directly using its C++ API.
> <https://www-fourier.ujf-grenoble.fr/~parisse/giac_us.html>
> This resulted in much faster execution and also avoids any sagemath
> interface issues found so far. FriCAS and Maxima and Mathics still
> use sagemath. Now GIAC has now become one of the fastest CAS's to
> complete after this change. (Compiled C++ is fast!)

So FriCAS and Maxima should be the only systems that use sagemath now.

>
> Hopefully with sagemath 9.6, failed integrals due to
> interface issues will be much less than earlier version
> as many bugs have been fixed in sagemath interface.
>

Martin.

[Nasser M. Abbasi]

On 7/3/2022 5:42 AM, clicl...@freenet.de wrote:
>
> So FriCAS and Maxima should be the only systems that use sagemath now.
>
>

> Martin.

I went back to using sagemath for giac. After spending
whole week developing the C++ program and getting the timeout
working using C++ pthreads, later I noticed two issues:

1). Each time giac core dumps the C++ program itself core dumps.
It meant I had to keep restarting it manually from where this happened.
This ended up being too much manual work and monitoring.

This turned out due to using `e` as symbol in the integrand, which giac
treats as Euler's constant. I did not notice this before. This was
reported to giac

<https://xcas.univ-grenoble-alpes.fr/forum/viewtopic.php?f=3&t=2783>

It looks like these issues have been fixed since then.

2. Rubi's input files contain lots of integrals that use `e`. It
meant I would have to now also convert these to use different
symbol just for giac.

Using sagemath, this is taken care of automatically. Here is an example

------------------
Welcome to giac readline interface, version 1.9.0
0>> integrate((e*x+d)^(7/2)/(-c*e^2*x^2+c*d^2)^(3/2),x)

Warning, integration of abs or sign assumes constant sign by intervals (correct if the argument is real):
Check [abs(t_nostep)]
-64*d^2/3/c/sqrt(2)/sqrt(c*d)/exp(1)-2*(-4*d^2/sqrt(-c*(d+x*exp(1))+2*c*d)/c/exp(1)+(1/3*c^6*sqrt(-c*(d+x*exp(1))+2*c*d)*(-c*(d+x*exp(1))+2*c*d)*exp(1)^2-4*c^7*d*sqrt(-c*(d+x*exp(1))+2*c*d)*exp(1)^2)/c^9/exp(1)^3)
// Time 0.01
------------------

Using sagemath with same integral, it gives

--------------------------------------
>sage
┌────────────────────────────────────────────────────────────────────┐
│ SageMath version 9.6, Release Date: 2022-05-15 │
│ Using Python 3.10.4. Type "help()" for help. │
└────────────────────────────────────────────────────────────────────┘
sage: var('e x d c d')
sage: integrate((e*x+d)^(7/2)/(-c*e^2*x^2+c*d^2)^(3/2),x,algorithm="giac")

-32/3*sqrt(2)*d^2/(sqrt(c*d)*c*e) + 8*d^2/(sqrt(-(e*x + d)*c + 2*c*d)*c*e) + 2/3*(12*sqrt(-(e*x + d)*c + 2*c*d)*c^7*d*e^2 - (-(e*x + d)*c + 2*c*d)^(3/2)*c^6*e^2)/(c^9*e^3)
-------------------------------------------

You see, with sagemath `e` remained a symbol, and not exp(1)

So even thought it was faster to run the test for giac in C++, it
turned out to be more convenient to use sagemath for this and this was
it keeps the integrand the same as in Rubi's input files. No need to
change `e` to new letter just for giac.

I still need to update the diagram I have to show that giac is back using
sagemath.

--Nasser

[anti...@math.uni.wroc.pl]

Nasser M. Abbasi <n...@12000.org> wrote:
> On 6/6/2022 3:35 AM, Nasser M. Abbasi wrote:
> > FYI,
> >
> > A new CAS integration test build started. This is summer 2022 edition.
> >
> > <https://www.12000.org/my_notes/CAS_integration_tests/reports/summer_2022/index.htm>
> >
> > It will take 2-3 more months to complete but I am posting this now
> > in case there are problems or suggestions so I can do them early one.
> >
>
> Fyi, This is update.
>
> Due to new release of Mathematica 13.1 and Fricas 1.3.8
> and giac 1.9.0-11 I had to start all over and build everything
> with the new versions.
>
> Currently files 1-12 (1892 integrals) just completed and uploaded.
> Will be uploading more files as they finish in the coming weeks.

<snip>

> Any problems found, please let me know.

In introduction you write that grading is not implemented only
for Mupad. But result look like is is not implemented also
for Giac and Maxima...

--
Waldek Hebisch

[anti...@math.uni.wroc.pl]

Nasser M. Abbasi <n...@12000.org> wrote:
>

> Any problems found, please let me know.
>

Looking at results of Timofeev file results show truncated
after position 667. I am not sure if this is due to
incompatiblity of markup with my browser or shows in
general.

--
Waldek Hebisch

[Nasser M. Abbasi]

On 7/3/2022 9:18 AM, anti...@math.uni.wroc.pl wrote:

> In introduction you write that grading is not implemented only
> for Mupad. But result look like is is not implemented also
> for Giac and Maxima...
>

Opps, sorry about that. Last minute change caused the grader to
skip over giac and maxima. You are right, only mupad is not graded.
It gets default B grade as place holder for now.

All fixed now. Uploaded new pages

<https://www.12000.org/my_notes/CAS_integration_tests/reports/summer_2022/index.htm>

The current result for the first 12 files grading is
============================================
A B C F
1. Rubi 97.83% 0.9% 0.37% 1%
2. MMA 88.27% 5.39% 5.55% 0.79%
3. Maple 78.7% 6.82% 8.19% 6.29%
4. Fricas 74.26% 20.35% 0.79% 4.6%
5. Maxima 73.31% 7.98% 0.74% 17.97%
6. Giac 73.2% 11.89% 1.48% 13.42%
7. Sympy 55.6% 11.58% 5.92% 26.9%
8. Mupad 0.21% 81.82% 0% 17.97%


Thanks
--Nasser

[Nasser M. Abbasi]

I am not able to find/figure what you mean. I assume you mean this
is in the HTML not the pdf?

Do you have a link I could look at to see what you mean? There
should not be any truncation anywhere. Program did not have
any changes in pdf or HTML generation part. Still uses same texlive
and tex4ht for the conversion.

But if I can see what you are seeing, it will help.

Thanks
--Nasser

[nob...@nowhere.invalid]

anti...@math.uni.wroc.pl schrieb:

What does this FriCAS failure on Timofeev Chapter 5, Example 81 (p.
276 in the book, #417 in the test suite) mean:

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

Error detected within library code: not invertible

I also saw one evaluation failing with "catdef: division by zero"
among the Timofeev results.

Nasser's file:

<https://www.12000.org/my_notes/CAS_integration_tests/reports/summer_2022/test_cases/0_Independent_test_suites/10_Timofeev_Problems/reportsection2.htm#x17-260002.2>

on my system loads and renders all the way down to Problem 705, which
links to:

<https://www.12000.org/my_notes/CAS_integration_tests/reports/summer_2022/test_cases/0_Independent_test_suites/10_Timofeev_Problems/reportsubsection717.htm#705>

which I also have no trouble accessing.

Martin.

[Nasser M. Abbasi]

FYI, Here is the result you mention above using Fricas directly
(i.e not via sagemath)

----------------------------------
>fricas
FRICAS="/usr/local/lib/fricas/target/x86_64-linux-gnu"
spad-lib="/usr/local/lib/fricas/target/x86_64-linux-gnu/lib/libspad.so"
FriCAS Computer Algebra System
Version: FriCAS 1.3.8
Timestamp: Tue Jun 21 15:11:38 CDT 2022

(1) -> setSimplifyDenomsFlag(true)

(1) false
Type: Boolean
(2) -> integrate((-2*sin(2*x)+(cos(x)*sin(x)^3)^(1/2))/(-(cos(x)^3*sin(x))^(1/2)+tan(x)^(1/2)), x)

>> Error detected within library code:
not invertible

(2) -> integrate((-2*cos(x)^3*(-1+sin(x))+cos(2*x)*sin(x))/sin(x)^2/(-5+sin(x)^2)^(1/2),x)

>> Error detected within library code:

catdef: division by zero

========================

The second integral above is integral 426 in Timofeev file. The optimal
anti should be for it according to Rubi's input file is

2*arctan(cos(x)/(-5+sin(x)^2)^(1/2))-2*arctanh(sin(x)/(-5+sin(x)^2)^(1/2))-
1/5*arctan(cos(x)*5^(1/2)/(-5+sin(x)^2)^(1/2))*5^(1/2)-2/5*arctan(1/5*(-5+s
in(x)^2)^(1/2)*5^(1/2))*5^(1/2)+2*(-5+sin(x)^2)^(1/2)+2/5*(-5+sin(x)^2)^(1/
2)/sin(x

note that Without using setSimplifyDenomsFlag(true) Fricas returns zero
for same integral:

=======================
>fricas
FriCAS Computer Algebra System
Version: FriCAS 1.3.8
Timestamp: Tue Jun 21 15:11:38 CDT 2022
(1) -> integrate((-2*cos(x)^3*(-1+sin(x))+cos(2*x)*sin(x))/sin(x)^2/(-5+sin(x)^2)^(1/2),x)

(1) 0
Type: Union(Expression(Integer),...)
(2) -> integrate((-2*cos(x)^3*(-1+sin(x))+cos(2*x)*sin(x))/sin(x)^2/(-5+sin(x)^2)^(1/2),x)

(2) 0
Type: Union(Expression(Integer),...)
(3) -> setSimplifyDenomsFlag(true)

(3) false
Type: Boolean
(4) -> integrate((-2*cos(x)^3*(-1+sin(x))+cos(2*x)*sin(x))/sin(x)^2/(-5+sin(x)^2)^(1/2),x)

>> Error detected within library code:

catdef: division by zero

(4) ->
===========================

CAS integration test program always uses setSimplifyDenomsFlag(true) for Fricas.

--Nasser

[anti...@math.uni.wroc.pl]

https://www.12000.org/my_notes/CAS_integration_tests/reports/summer_2022/test_cases/0_Independent_test_suites/10_Timofeev_Problems/reportsection2.htm#x17-260002.2

--
Waldek Hebisch

[anti...@math.uni.wroc.pl]

clicl...@freenet.de <nob...@nowhere.invalid> wrote:
>
> anti...@math.uni.wroc.pl schrieb:
> >
> > Nasser M. Abbasi <n...@12000.org> wrote:
> > >
> > > Any problems found, please let me know.
> > >
> >
> > Looking at results of Timofeev file results show truncated
> > after position 667. I am not sure if this is due to
> > incompatiblity of markup with my browser or shows in
> > general.
> >
>
> What does this FriCAS failure on Timofeev Chapter 5, Example 81 (p.
> 276 in the book, #417 in the test suite) mean:
>
> integrate((-2*sin(2*x)+(cos(x)*sin(x)^3)^(1/2))
> /(-(cos(x)^3*sin(x))^(1/2)+tan(x)^(1/2)), x)
>
> Error detected within library code: not invertible

This is rather excessive example of dependent roots:

(cos(x)*sin(x)^3)^(1/2) = +-sin(x)*(cos(x)*sin(x))^(1/2)
(cos(x)^3*sin(x))^(1/2) = +-cos(x)*(cos(x)*sin(x))^(1/2)
tan(x)^(1/2) = +-(cos(x)*sin(x))^(1/2)/cos(x)

So there are 4 essentially different combinations of branches
(8 together, but they are equvalent in pairs).

As I wrote, dependent roots may lead to division by zero,
which happens in this example.

--
Waldek Hebisch

[Nasser M. Abbasi]

On 7/4/2022 6:09 AM, anti...@math.uni.wroc.pl wrote:
>
>> But if I can see what you are seeing, it will help.
>
> https://www.12000.org/my_notes/CAS_integration_tests/reports/summer_2022/test_cases/0_Independent_test_suites/10_Timofeev_Problems/reportsection2.htm#x17-260002.2
>

Thanks for the link. The above is the section titled

"Detailed conclusion table per each integral for all CAS systems"

Which shows a small table per each one integral with all stats for it.

I see all the 705 tables on one page, no problem here. Using Brave and other browsers.

There are 705 tables in there as expected. I think because there are
so many, may be your browser buffer get filled or slowed down?

But for the next update, I will change this section to only display
100 entries (tables) per one web page, and will break this section
into many subsection, each subsection with only 100 entries.

This should help loading this page faster but one will have to click on
each subsection now to see each 100 entries at a time. I had to do that with the
integrals listing pages also which helped loading them faster.

regards
--Nasser

[nob...@nowhere.invalid]

anti...@math.uni.wroc.pl schrieb:

>
> clicl...@freenet.de <nob...@nowhere.invalid> wrote:
> >
> > What does this FriCAS failure on Timofeev Chapter 5, Example 81 (p.
> > 276 in the book, #417 in the test suite) mean:
> >
> > integrate((-2*sin(2*x)+(cos(x)*sin(x)^3)^(1/2))
> > /(-(cos(x)^3*sin(x))^(1/2)+tan(x)^(1/2)), x)
> >
> > Error detected within library code: not invertible
>
> This is rather excessive example of dependent roots:
>
> (cos(x)*sin(x)^3)^(1/2) = +-sin(x)*(cos(x)*sin(x))^(1/2)
> (cos(x)^3*sin(x))^(1/2) = +-cos(x)*(cos(x)*sin(x))^(1/2)
> tan(x)^(1/2) = +-(cos(x)*sin(x))^(1/2)/cos(x)
>
> So there are 4 essentially different combinations of branches
> (8 together, but they are equvalent in pairs).
>
> As I wrote, dependent roots may lead to division by zero,
> which happens in this example.
>

If this error message is specific to the detection of dependent roots
that FriCAS cannot handle, it can serve as an indication for the user
to rewrite his integrand in terms of independent roots.

The problem of dependent roots would thereby be addressed adequately in
my view even though the test cases are currently counted as failed.

Martin.

[anti...@math.uni.wroc.pl]

clicl...@freenet.de <nob...@nowhere.invalid> wrote:
>
> anti...@math.uni.wroc.pl schrieb:
> >
> > clicl...@freenet.de <nob...@nowhere.invalid> wrote:
> > >
> > > What does this FriCAS failure on Timofeev Chapter 5, Example 81 (p.
> > > 276 in the book, #417 in the test suite) mean:
> > >
> > > integrate((-2*sin(2*x)+(cos(x)*sin(x)^3)^(1/2))
> > > /(-(cos(x)^3*sin(x))^(1/2)+tan(x)^(1/2)), x)
> > >
> > > Error detected within library code: not invertible
> >
> > This is rather excessive example of dependent roots:
> >
> > (cos(x)*sin(x)^3)^(1/2) = +-sin(x)*(cos(x)*sin(x))^(1/2)
> > (cos(x)^3*sin(x))^(1/2) = +-cos(x)*(cos(x)*sin(x))^(1/2)
> > tan(x)^(1/2) = +-(cos(x)*sin(x))^(1/2)/cos(x)
> >
> > So there are 4 essentially different combinations of branches
> > (8 together, but they are equvalent in pairs).
> >
> > As I wrote, dependent roots may lead to division by zero,
> > which happens in this example.
> >
>
> If this error message is specific to the detection of dependent roots
> that FriCAS cannot handle, it can serve as an indication for the user
> to rewrite his integrand in terms of independent roots.

Unfortunately, no. This is really generic "division by zero"
error which is possible for several different reasons.

> The problem of dependent roots would thereby be addressed adequately in
> my view even though the test cases are currently counted as failed.

Well, it is hard to know what user wants as an answer. Apparently
Timofeev completely disregared any branch issues. This makes
sense for integration as branch issues are almost independent
of finding correct formula. But there are also subtelties,
because correct formula may be different for different
branches. And it may happen that one branch has elementary
integral while other branch does not.

Anyway, I plan to add detection of dependent roots to FriCAS,
but ATM there is no such routine and results are mixed:
- FriCAS may signal division by zero
- FriCAS may produce result for some choice of branches
- various ad-hoc choices may contradict themself leading
to wrong result

--
Waldek Hebisch

[Валерий Заподовников]

Can you increase timeout for IntegrateAlgebraic to 100 seconds?
Here is the example where it matters, when your PC is too slow to
do it in default 10 seconds. At least my PC is. I really need to update
to Alder Lake. Maybe it can solve some of the failed cases in 13.1.

SetSystemOptions[
"IntegrateOptions" -> {"IntegrateAlgebraicTimeConstraint" -> 20}];
Integrate[x/Sqrt[x^4 - 2 x^3 + 3 x^2 + 4 x + 1], x]

Also, what is this? How is it possible we did not know the antiderivative? https://www.12000.org/my_notes/CAS_integration_tests/reports/summer_2022/indexchapter3.htm#x4-190003

[nob...@nowhere.invalid]

??????? ???????????? schrieb:

>
> Can you increase timeout for IntegrateAlgebraic to 100 seconds?
> Here is the example where it matters, when your PC is too slow to
> do it in default 10 seconds. At least my PC is. I really need to
> update to Alder Lake. Maybe it can solve some of the failed cases in
> 13.1.
>
> SetSystemOptions[
> "IntegrateOptions" -> {"IntegrateAlgebraicTimeConstraint" -> 20}];
> Integrate[x/Sqrt[x^4 - 2 x^3 + 3 x^2 + 4 x + 1], x]

FriCAS solves this in no time at all (expressed in Derive notation):

INT(x/SQRT(x^4 - 2*x^3 + 3*x^2 + 4*x + 1), x) =
LN((2*x^4 - 10*x^3 + 24*x^2 - 28*x + 14)
*SQRT(x^4 - 2*x^3 + 3*x^2 + 4*x + 1)
+ 2*x^6 - 12*x^5 + 36*x^4 - 56*x^3 + 42*x^2 - 13)/6

What source is the integrand taken from?

Martin.

[Nasser M. Abbasi]

On 7/6/2022 12:34 PM, Валерий Заподовников wrote:
> Can you increase timeout for IntegrateAlgebraic to 100 seconds?
> Here is the example where it matters, when your PC is too slow to
> do it in default 10 seconds. At least my PC is. I really need to update
> to Alder Lake. Maybe it can solve some of the failed cases in 13.1.
>
> SetSystemOptions[
> "IntegrateOptions" -> {"IntegrateAlgebraicTimeConstraint" -> 20}];
> Integrate[x/Sqrt[x^4 - 2 x^3 + 3 x^2 + 4 x + 1], x]
>

So you want instead of what now happens, which is constraint of
180 second on the whole call:

TimeConstrained[Integrate[x/Sqrt[x^4 - 2 x^3 + 3 x^2 + 4 x + 1], x], 180]

To change the above to the following:

SetSystemOptions["IntegrateOptions" -> {"IntegrateAlgebraicTimeConstraint" -> 100}];
TimeConstrained[Integrate[x/Sqrt[x^4 - 2 x^3 + 3 x^2 + 4 x + 1], x],180]

?

Do you think this will improve Mathematica's overall score? I can rerun
the first 12 Rubi files using V 13.1 with the above change and find out.

Currently Mathematica scored % 99.21 on the first 12 files.

I did not know that IntegrateAlgebraic had time limit of
only 10 seconds within Mathematica Integrate command. But the overall
time will remain only 3 minutes, as that is what every CAS has.

I'll will update when this is done. If result does improve (or grade
improve) will do that for the result of the tests otherwise, will keep
it as is.

> Also, what is this? How is it possible we did not know the antiderivative

<https://www.12000.org/my_notes/CAS_integration_tests/reports/summer_2022/indexchapter3.htm#x4-190003>

According to Rubi's input file #5 "Hearn Problems", this integral #145

integrate(x*cos(x)*cos(k/sin(x))/sin(x)^2,x, algorithm="maxima")

is not integrable. Here is the entry:

{x*Cos[k/Sin[x]]*Cos[x]/Sin[x]^2, x, 0, CannotIntegrate[x*Cos[k*Csc[x]]*Cot[x]*Csc[x], x]}

And Maxima was the only CAS which was able to integrate it giving
the following

-1/2*(x*e^(4*k*cos(2*x)*cos(x)/(cos(2*x)^2 + sin(2*x)^2 - 2*cos(2*x) + 1) + 4*k*sin(2*x)*sin(x)/(cos(2*x)^2 +
sin(2*x)^2 - 2*cos(2*x) + 1)) + x*e^(4*k*cos(x)/(cos(2*x)^2 + sin(2*x)^2 - 2*cos(2*x) + 1)))*e^(-2*k*cos(2*x)*
cos(x)/(cos(2*x)^2 + sin(2*x)^2 - 2*cos(2*x) + 1) - 2*k*sin(2*x)*sin(x)/(cos(2*x)^2 + sin(2*x)^2 - 2*cos(2*x)
+ 1) - 2*k*cos(x)/(cos(2*x)^2 + sin(2*x)^2 - 2*cos(2*x) + 1))*sin(2*(k*cos(x)*sin(2*x) - k*cos(2*x)*sin(x) + k
*sin(x))/(cos(2*x)^2 + sin(2*x)^2 - 2*cos(2*x) + 1))/k

But Maxima result is not verified. So it is flagged for this reason for
someone to look at. It could be wrong antiderivative? someone might
want to verify it. The test program currently only verifies Mathematica's
and Rubi's results.

--Nasser

[Валерий Заподовников]

I took it from here after search "Risch":

https://math.stackexchange.com/questions/3784897/how-to-apply-rischs-algorithm-to-int-fracx-sqrtx4-2x33x24x1-mat

>FriCAS solves this in no time at all (expressed in Derive notation)

Antiderivative looks different though up to a constant.

>Do you think this will improve Mathematica's overall score?

It can even solve some Integrals that otherwise gave not elementary
result. I was proposing to check only not solved results though.

[anti...@math.uni.wroc.pl]

Nasser M. Abbasi <n...@12000.org> wrote:

> On 7/6/2022 12:34 PM, ??????? ???????????? wrote:
>
> > Also, what is this? How is it possible we did not know the antiderivative
> <https://www.12000.org/my_notes/CAS_integration_tests/reports/summer_2022/indexchapter3.htm#x4-190003>
>
> According to Rubi's input file #5 "Hearn Problems", this integral #145
>
> integrate(x*cos(x)*cos(k/sin(x))/sin(x)^2,x, algorithm="maxima")
>
> is not integrable. Here is the entry:
>
> {x*Cos[k/Sin[x]]*Cos[x]/Sin[x]^2, x, 0, CannotIntegrate[x*Cos[k*Csc[x]]*Cot[x]*Csc[x], x]}
>
> And Maxima was the only CAS which was able to integrate it giving
> the following
>
> -1/2*(x*e^(4*k*cos(2*x)*cos(x)/(cos(2*x)^2 + sin(2*x)^2 - 2*cos(2*x) + 1) + 4*k*sin(2*x)*sin(x)/(cos(2*x)^2 +
> sin(2*x)^2 - 2*cos(2*x) + 1)) + x*e^(4*k*cos(x)/(cos(2*x)^2 + sin(2*x)^2 - 2*cos(2*x) + 1)))*e^(-2*k*cos(2*x)*
> cos(x)/(cos(2*x)^2 + sin(2*x)^2 - 2*cos(2*x) + 1) - 2*k*sin(2*x)*sin(x)/(cos(2*x)^2 + sin(2*x)^2 - 2*cos(2*x)
> + 1) - 2*k*cos(x)/(cos(2*x)^2 + sin(2*x)^2 - 2*cos(2*x) + 1))*sin(2*(k*cos(x)*sin(2*x) - k*cos(2*x)*sin(x) + k
> *sin(x))/(cos(2*x)^2 + sin(2*x)^2 - 2*cos(2*x) + 1))/k
>
> But Maxima result is not verified. So it is flagged for this reason for
> someone to look at. It could be wrong antiderivative? someone might
> want to verify it.

Well, when FriCAS says that there is no elementary integral and
Maxima says that there is one of them must be wrong.

AFAICS Maxima is wrong. By inspection one can check that this
expression depends on x only via trigonometric functions.
There are no logarithms and no inverse trigonometric function
so there is no way to get x in the derivative.

BTW: by Liouville and Risch theorems there should be no exp
with real exponent in the answer. Indeed the 3 exponentials
simplify to constant 2. What remains is much simpler and
it is slightly easier to see why it is wrong.

--
Waldek Hebisch

[anti...@math.uni.wroc.pl]

Nasser M. Abbasi <n...@12000.org> wrote:

> On 6/6/2022 3:35 AM, Nasser M. Abbasi wrote:
> > FYI,
> >
> > A new CAS integration test build started. This is summer 2022 edition.
> >
> > <https://www.12000.org/my_notes/CAS_integration_tests/reports/summer_2022/index.htm>
> >
> > It will take 2-3 more months to complete but I am posting this now
> > in case there are problems or suggestions so I can do them early one.
> >
>
> Fyi, This is update.
>
> Due to new release of Mathematica 13.1 and Fricas 1.3.8
> and giac 1.9.0-11 I had to start all over and build everything
> with the new versions.

<snip>

> Any problems found, please let me know.
>
> For CAS's that use sagemath (Fricas, Maxima, Giac), any failed
> integral due to sagemath interface will have an F(-2) next to the
> exception name. From the exception name one can see if the
> exception was due to interface issue or it was generated
> from the called CAS itself due to internal error.

Hmm, looking at

https://www.12000.org/my_notes/CAS_integration_tests/reports/summer_2022/test_cases/1_Algebraic_functions/1.1_Binomial_products/1.1.2_Quadratic/20_1.1.2.3-a+b_x%5E2-%5Ep-c+d_x%5E2-%5Eq/reportsubsection296.htm#284

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

on the page there is unevaluated result with no indication of
interface error. However, 1.3.8 gives me:

(1) -> setSimplifyDenomsFlag(true)

(1) false
Type: Boolean

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

(2)
+---+
| c
+---+ |- -
+-----+ | c \| d a d
(- d - c)x\|- b d |- - ellipticF(------,---)
\| d x b c
+
+---+
| c
+---+ |- - +----------+ +--------+
+-----+ | c \| d a d | 2 | 2
c x\|- b d |- - ellipticE(------,---) - d\|- b x - a \|d x + c
\| d x b c
/
b d x
Type: Union(Expression(Integer),...)

so FriCAS produces result in terms of elliptic functions (which
IIUC cause interface error). Or maybe the result is from 1.3.7?

Apparently the same holds for several integral in the file.

--
Waldek Hebisch

[Nasser M. Abbasi]

Hi Waldek,

this is the special function elliptic_ec issue I mentioned on

<https://groups.google.com/g/fricas-devel/c/SuIjkj9Xg2Y/m/bdRUUrSVGgAJ>

"
And on the subject of using Fricas integrate in sagemath, I've just
reported a new bug to sagemath due
to interface issues. This causes few integrals to fail running Fricas
integrate in sagemath, when they should not have failed because
Fricas can do them. But this is out of my control.

Hopefully when these are fixed, will re-run CAS integration tests
again for Fricas 1..3.8. It is due to translation of elliptic special function names.
"

Here is link to the ticket

https://trac.sagemath.org/ticket/34058

Here is trying it again
==================================

>sage
┌────────────────────────────────────────────────────────────────────┐
│ SageMath version 9.6, Release Date: 2022-05-15 │

│ Using Python 3.10.5. Type "help()" for help. │
└────────────────────────────────────────────────────────────────────┘
sage: var('d x c a b')
sage: integrate((d*x^2+c)^(1/2)/(-b*x^2-a)^(1/2),x, algorithm="fricas")

TypeError: Symbolic function elliptic_ec takes exactly 1 arguments (2 given)
================================

As to why the test report does not show it is F(-2) and just F to indicate it
is an interface exception, I have to look into that and see why it did not
catch this exception as it should have.

But this interface issue seems to have been fixed now and once
sagemath 9.7 is out in 2-3 months, will rerun all of the tests again
and update all the pages.

--Nasser

[Nasser M. Abbasi]

On 7/11/2022 8:11 PM, anti...@math.uni.wroc.pl wrote:
>

> Hmm, looking at
>
> https://www.12000.org/my_notes/CAS_integration_tests/reports/summer_2022/test_cases/1_Algebraic_functions/1.1_Binomial_products/1.1.2_Quadratic/20_1.1.2.3-a+b_x%5E2-%5Ep-c+d_x%5E2-%5Eq/reportsubsection296.htm#284
>

....

>
> so FriCAS produces result in terms of elliptic functions (which
> IIUC cause interface error). Or maybe the result is from 1.3.7?
>
> Apparently the same holds for several integral in the file.
>

<https://www.12000.org/my_notes/CAS_integration_tests/reports/summer_2022/test_cases/1_Algebraic_functions/1.1_Binomial_products/1.1.2_Quadratic/20_1.1.2.3-a+b_x%5E2-%5Ep-c+d_x%5E2-%5Eq/reportsubsection296.htm#284>

Thanks for noticing this. (You might want to refresh this page in your browser
to see the updated version).

I found the problem. It only affected the HTML pages, not the PDF.
The PDF's are all correct.

This is what happened: I've installed TexLive new on a new Virtual box,
and it turned out it had a bug in tex4ht which generates the HTML:

<https://tug.org/pipermail/tex4ht/2022q3/003248.html>

But this was quickly fixed few days ago. So I just updated TexLive
on my Linux VBox, and now the HTML files are building OK. Before they
did not refresh and the HTML files were actually an older version that
was not updated.

It will take me 2 weeks to rebuild all the HTML pages.

But for now, I just build file #20 which you linked to, and now you see
it is update to date, the same output as in the PDF.

I see these Fricas integrals all failed with F(-2) (interface exception most
likely, unless it is internal exception, I have not checked each).

166-178
181-186
195-197
199-213
258-289
295
297-300

This is about 20% of all the integrals in the file. I have not checked
each one is this exception or something else

TypeError >> Symbolic function elliptic_ec takes exactly 1 arguments (2 given)

But if they are all due to this elliptic conversion problem, then Fricas
score should be 20% higher than it is shows now. So instead of
58.45% it should be about 78.45%.

Hopefully when sagemath 9.7 is out, these all will then pass.

--Nasser

[Nasser M. Abbasi]

On 7/12/2022 3:42 AM, Nasser M. Abbasi wrote:

> Hopefully when sagemath 9.7 is out, these all will then pass.
>

fyi,

The fix for Fricas translation of elliptic functions
is now in sagemath 9.7 beta 5.


https://groups.google.com/g/sage-release/c/FezzF5Q7Wt4

38b2bf7529 Trac #34058: sage 9.6 special function translation issue with fricas. elliptic_ec


--Nasser

[Nasser M. Abbasi]

On 7/11/2022 8:36 PM, Nasser M. Abbasi wrote:
>
> Here is link to the ticket
>
> https://trac.sagemath.org/ticket/34058
>
> Here is trying it again
> ==================================
>> sage
> ┌────────────────────────────────────────────────────────────────────┐
> │ SageMath version 9.6, Release Date: 2022-05-15 │
> │ Using Python 3.10.5. Type "help()" for help. │
> └────────────────────────────────────────────────────────────────────┘
> sage: var('d x c a b')
> sage: integrate((d*x^2+c)^(1/2)/(-b*x^2-a)^(1/2),x, algorithm="fricas")
>
> TypeError: Symbolic function elliptic_ec takes exactly 1 arguments (2 given)
> ================================

Fyi, just finished building sagemath 9.7 beta 5.

This is to confirm that it now handles Fricas elliptic functions OK and
does not generate any exceptions

=============================
>./sage
┌────────────────────────────────────────────────────────────────────┐
│ SageMath version 9.7.beta5, Release Date: 2022-07-10 │

│ Using Python 3.10.5. Type "help()" for help. │
└────────────────────────────────────────────────────────────────────┘

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Warning: this is a prerelease version, and it may be unstable. ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

sage: var('d x c a b')

(d, x, c, a, b)

sage: integrate((d*x^2+c)^(1/2)/(-b*x^2-a)^(1/2),x, algorithm="fricas")

(b*c^2*x*elliptic_e(arcsin(sqrt(-c/d)/x), a*d/(b*c)) - sqrt(-b*x^2 - a)*sqrt(d*x^2 + c)*sqrt(-b*d)*d*sqrt(-c/d) - (b*c^2 + b*c*d)*x*ellipticF(sqrt(-c/d)/x, a*d/(b*c)))/(sqrt(-b*d)*b*d*x*sqrt(-c/d))
=================================

This will improve Fricas score when using sagemath 9.7 instead of 9.6.

--Nasser

[Nasser M. Abbasi]

FYI,

(Posted at https://groups.google.com/g/fricas-devel and
https://groups.google.com/g/sci.math.symbolic)

Independent CAS integration tests summer 2022 edition is now complete.
(It took about 5 months since I initially started working on it!)

<https://www.12000.org/my_notes/CAS_integration_tests/reports/summer_2022/index.htm>

The following is summary of changes in this version
compared to last year's edition
========================
1. Number of integrals increased to 85,479 from 71,994.

The integrals are made of the following 210 files:

a. Rubi test suite. Files 1 to 208. Thanks to Alert Rich.
Downloaded from <https://github.com/RuleBasedIntegration>
b. IntegrateAlgebraic test file. File 209. Thanks to Sam Blake.
c. Fricas test file. File 210. Thanks to Waldek Hebisch.

2. CAS version changes:
Maple 2021.1 -> 2022.1
Mathematica 12.3 -> 13.01
Giac 1.7.0 -> 1.9.0-13
Sympy 1.8/python 3.8.8 -> 1.10.1/Python 3.10.4
Maxima 5.44 -> 5.46
FriCAS 1.3.7 -> 1.3.8
Sagemath 9.3 -> 9.6

No version change for Mupad at Matlab 2021a and Rubi at 4.16.1
but Rubi was run again on the current Mathematica 13.1 version.

3. General improvements to Latex and other formatting.

4. Flow chart of the test program at
<https://www.12000.org/my_notes/CAS_integration_tests/images/design.svg>

5. Links to download all the 85,483 integrals in plain text in
Mathematica, Rubi, Maple, Mupad, Sympy, and Sagemath (Fricas, Maxima, Giac)
formats are at introduction page of the main page.

6. Regression reports comparing results in 2022 edition to 2021 edition
are also now available. These reports show integrals that failed
in current versions compared to last versions per CAS.

<https://12000.org/my_notes/CAS_integration_tests/reports/summer_2022/REGRESSION_REPORTS/index.htm>

Regression per CAS
------------------
This table below gives the number of integrals that failed in
this test (could be due to timeout, exception or not solved) but
are solved in summer 2021 for each CAS.

Number of regression per CAS is (less is better)

Fricas: 16
Maxima: 17
Mathematica: 98
Maple: 114
Giac: 363
Sympy: 379

Tables give details about each integral that failed in regression.

7. Sympy, Sagemath (Fricas, Maxima, Giac) were all run on Linux
inside Oracle Virtual Box. Maple, Rubi, Mupad and Mathematica were
run on windows 10. All on same PC with 128 GB RAM with
Intel Core i9-12900K 3.20 GHz.

RESULTS
=======

Overall solved percentage in summer 2022 edition
=========================================
1. Mathematica 13.1 97.99 %
2. Rubi 4.16.1 94.21 %
3. Maple 2022.1 84.53 %
4. Fricas 1.3.8 79.33 %
5. Giac 1.9.0-13 58.37 %
6. Maxima 5.46 56.86 %
7. Mupad 2021a 56.1 %
8. Sympy 1.10.1 41.89 %

Grading results
=================
Note that mupad is not graded. Default grade of B is given for
any passed integral.

1. Rubi 91.50 %
2. Mathematica 78.58 %
3. Maple 56.34 %
4. Fricas 53.78 %
5. Maxima 43.57 %
6. Giac 42.36 %
7. Sympy 28.49 %
8. Mupad* N/A

Time and leaf size Performance
==============================
Sorted by time performance in average time used per integrals (seconds).

Note for Maple(*) timing: the option method=_RETURNVERBOSE was used
which made Maple run through all integration methods increasing
average time used. For example in summer 2021 edition which did
not use this option, Maple had 0.79 seconds average time on
a slower PC also than the one used for the current tests.

1. Rubi 0.3 (sec)
2. Maxima 0.49 (sec)
3. Giac 0.75 (sec)
4. Fricas 1.17 (sec)
5. Mathematica 2.38 (sec)
6. Mupad 2.75 (sec)
7. Maple* 3.33 (sec)
8. Sympy 5.24 (sec)

General notes
==============
1) Maxima, Fricas and Giac were called via Sagemath. Some integrals
could have failed due to interface issues. These will have F(-2)
error code in the section "Detailed conclusion table per each
integral for all CAS systems" per each report and also in the actual
integral page with the actual exception name shown.

This allows one to see if the cause of the failure is due to
interface issue or internal error from the CAS itself.

For an example, the integral on

<https://12000.org/my_notes/CAS_integration_tests/reports/summer_2022/test_cases/4_Trig_functions/4.7_Miscellaneous/139_4.7.5_x%5Em_trig-a+b_log-c_x%5En-%5Ep/reportsubsection69.htm#53>

Has F(-2) on Fricas output, but looking at the exception

integrate(x*sin(a+b*log(c*x^n))^(1/2),x, algorithm="fricas")

"Exception raised: TypeError >> Error detected within library code:
integrate: implementation incomplete (has polynomial part)"

So this is not interface issue with Sagemath. The exception comes
from Fricas itself.

But this integral

<https://12000.org/my_notes/CAS_integration_tests/reports/summer_2022/test_cases/4_Trig_functions/4.7_Miscellaneous/139_4.7.5_x%5Em_trig-a+b_log-c_x%5En-%5Ep/reportsubsection57.htm#41>

Has F(-2) on Giac result, and looking at the exception it says

integrate(x^2*sin(a+log(c*x^n)*(-1/n^2)^(1/2))^3,x, algorithm="giac")

"Exception raised: NotImplementedError >>
Unable to parse Giac output:
((-9*i)*sageVARn^4*sageVARx^3*exp((-3*i) *sageVARa)*
exp((3*sageVARn*abs(sageVARn)*ln(sageVARx)+3*abs(sageVARn)*
ln(sageVARc))/sageVARn^2)+27*i*sageVARn^4*sageVARx^3*exp((-i)"

Which indicates it is an interface issue this time. This is
verified by running this integral directly in giac and it is
solved with no error.

CAS integration test program currently does not distinguish
between an exception generated due to a sagemath interface problem
or an exception generated from the CAS itself. I am not
sure if there a robust way to do this for Maxima, Fricas
and Giac. If a way can be found, will add it.

But there seems to be less of these interface problems in the
current Sagemath version than the last one used.

2) The section "List of integrals sorted by grade for each CAS" in each
report shows list of integrals for each grade per CAS. This allows
one to quickly find integrals with specific grade.

3) Also as mentioned before there are a number of integrals for Maxima
which fail when it asks a question in order to complete the
integration as this is not supported by Sagemath or by the
CAS integration test program. If an option can be added to
turn this feature off that will be a good thing and will improve
Maxima score.

4) Any bugs found or problems please let me know and will try my best
to fix them.

--Nasser

[nob...@nowhere.invalid]

"Nasser M. Abbasi" schrieb:

Here's how the percentages of integrals solved relate to last year's:

system 2022 2021
===============================
Mathematica 97.99 % 98.39 %
Rubi 94.21 % 99.52 %
Maple 84.53 % 83.58 %
Fricas 79.33 % 68.70 %
Giac 58.37 % 52.43 %
Maxima 56.86 % 52.72 %
Mupad 56.10 % 52.55 %
Sympy 41.89 % 34.47 %
===============================

The number of integrals has increased from 71,994 to 85,479, mainly
because, I suppose, new suites of 3,154 elementary algebraic integrands
by Sam Blake and of 10,335 elementary transcendental integrands by
Waldek Hebisch have been added.

Can we assume that the extended tests a better measure of the
integrator performance one needs in practice?

Rubi's performance drops by more than 5% - understandably, since a
rule-based approach is not well suited to cope with many of the
integrands designed to exercise Sam's heuristic integration algorithm
for algebraic integrals, or many of Waldek's integrands obtained by
differentiation of random transcendental functions.

Strangely, Mathematica loses 0.4% - in spite of having incorporated
the heuristic algorithm for algebraic integrals, and in spite of its
claim to field a Risch implementation that is able to handle any
transcendental integrand.

Maple, meanwhile, gains 1% - perhaps because the integrator invocation
on each test integrand also activates Maple's Risch-Trager algorithm
for algebraic integrands this time, but didn't last time.

FriCAS gains more than 10% - it should be performing fairly well on the
new suite of algebraic integrands, and of course perfectly well on that
of random transcendental ones.

Mupad, Maxima, Giac, and Sympy (in this order) gain from 3.5% to 7.5%.
I wonder why?

Also, two regression failures in FriCAS 1.3.8 appear worth noting,
where integrals with elementary solutions are returned unevaluated. One
is (expressed in Derive notation):

INT(((x^2 - 3*x - 4)*LOG(1 + x) + ((- x^3 + 3*x^2 + 4*x)*EXP(x + 7)
+ 3*x^2 - 10*x - 8)*LOG(x) + (- x^2 + 3*x + 4)*EXP(x + 7)
+ x^3 - 4*x^2 - 5*x)/(x^3 - 3*x^2 - 4*x), x)
= x - LOG(4 - x) + LOG(x)*(- EXP(7 + x) + LOG(x) + LOG(1 + x))

which is being discussed on fricas-devel already. The antiderivative
returned by Derive 6.10 involves DILOG. And the other is:

INT(SEC(d*x + c)*(a + b*SIN(d*x + c))^(5/2), x)
= - (a - b)^(5/2)*ATANH(SQRT(a + b*SIN(c + d*x))/SQRT(a - b))/d
+ (a + b)^(5/2)*ATANH(SQRT(a + b*SIN(c + d*x))/SQRT(a + b))/d
- 4*a*b*SQRT(a + b*SIN(c + d*x))/d
- 2*b*(a + b*SIN(c + d*x))^(3/2)/(3*d)

where Derive 6.10 returns a correct elementary result.

Martin.

[anti...@math.uni.wroc.pl]

clicl...@freenet.de <nob...@nowhere.invalid> wrote:
>
> "Nasser M. Abbasi" schrieb:

> >
> > Independent CAS integration tests summer 2022 edition is now complete.
> > (It took about 5 months since I initially started working on it!)
> >
> > <https://www.12000.org/my_notes/CAS_integration_tests/reports/summer_2022/index.htm>
> >

>

> Here's how the percentages of integrals solved relate to last year's:
>
> system 2022 2021
> ===============================
> Mathematica 97.99 % 98.39 %
> Rubi 94.21 % 99.52 %
> Maple 84.53 % 83.58 %
> Fricas 79.33 % 68.70 %
> Giac 58.37 % 52.43 %
> Maxima 56.86 % 52.72 %
> Mupad 56.10 % 52.55 %
> Sympy 41.89 % 34.47 %
> ===============================
>
> The number of integrals has increased from 71,994 to 85,479, mainly
> because, I suppose, new suites of 3,154 elementary algebraic integrands
> by Sam Blake and of 10,335 elementary transcendental integrands by
> Waldek Hebisch have been added.

71_994 + 3_154 + 10_335 = 85_483

so 4 interals are gone.

> Can we assume that the extended tests a better measure of the
> integrator performance one needs in practice?
>
> Rubi's performance drops by more than 5% - understandably, since a
> rule-based approach is not well suited to cope with many of the
> integrands designed to exercise Sam's heuristic integration algorithm
> for algebraic integrals, or many of Waldek's integrands obtained by
> differentiation of random transcendental functions.
>
> Strangely, Mathematica loses 0.4% - in spite of having incorporated
> the heuristic algorithm for algebraic integrals, and in spite of its
> claim to field a Risch implementation that is able to handle any
> transcendental integrand.
>
> Maple, meanwhile, gains 1% - perhaps because the integrator invocation
> on each test integrand also activates Maple's Risch-Trager algorithm
> for algebraic integrands this time, but didn't last time.
>
> FriCAS gains more than 10% - it should be performing fairly well on the
> new suite of algebraic integrands, and of course perfectly well on that
> of random transcendental ones.

Well, according to per file results FriCAS can do 76.69% from older
testuite, so main improvement is here. On 3154 algebraic integrands
FriCAS can do 72.035%, so below its average performance.

> Also, two regression failures in FriCAS 1.3.8 appear worth noting,

<snip>

> And the other is:
>
> INT(SEC(d*x + c)*(a + b*SIN(d*x + c))^(5/2), x)
> = - (a - b)^(5/2)*ATANH(SQRT(a + b*SIN(c + d*x))/SQRT(a - b))/d
> + (a + b)^(5/2)*ATANH(SQRT(a + b*SIN(c + d*x))/SQRT(a + b))/d
> - 4*a*b*SQRT(a + b*SIN(c + d*x))/d
> - 2*b*(a + b*SIN(c + d*x))^(3/2)/(3*d)
>
> where Derive 6.10 returns a correct elementary result.

Well, this one works in developement version. There was a bug
in algebraic integration part which could randomly wrongly
claim integral as non-elementary.

--
Waldek Hebisch

[Nasser M. Abbasi]

On 8/22/2022 4:48 PM, anti...@math.uni.wroc.pl wrote:
> clicl...@freenet.de <nob...@nowhere.invalid> wrote:
>>
>> "Nasser M. Abbasi" schrieb:
>>>
>>> Independent CAS integration tests summer 2022 edition is now complete.
>>> (It took about 5 months since I initially started working on it!)
>>>
>>> <https://www.12000.org/my_notes/CAS_integration_tests/reports/summer_2022/index.htm>
>>>
>
>>
>> Here's how the percentages of integrals solved relate to last year's:
>>
>> system 2022 2021
>> ===============================
>> Mathematica 97.99 % 98.39 %
>> Rubi 94.21 % 99.52 %
>> Maple 84.53 % 83.58 %
>> Fricas 79.33 % 68.70 %
>> Giac 58.37 % 52.43 %
>> Maxima 56.86 % 52.72 %
>> Mupad 56.10 % 52.55 %
>> Sympy 41.89 % 34.47 %
>> ===============================
>>
>> The number of integrals has increased from 71,994 to 85,479, mainly
>> because, I suppose, new suites of 3,154 elementary algebraic integrands
>> by Sam Blake and of 10,335 elementary transcendental integrands by
>> Waldek Hebisch have been added.
>
> 71_994 + 3_154 + 10_335 = 85_483
>
> so 4 interals are gone.
>

The 4 integrals were causing current version of sagemath trouble due
to changes they made. They are from file #55 from Rubi's test suite.
There were integrals numbers 763..766 Here is a link to the first
one from last year's build

<https://12000.org/my_notes/CAS_integration_tests/reports/summer_2021/test_cases/2_Exponentials/2.3_Exponential_functions/rese762.htm#x766-7900003.762>

Here they are:

{F0[x]/(F0[x] + x), x, 2, x - CannotIntegrate[x/(x + F0[x]), x]}
{F0[x]/(F0[x] + x^2), x, 2, x - CannotIntegrate[x^2/(x^2 + F0[x]), x]}
{F0[x]/(F0[x] + x)^2, x, 2, -CannotIntegrate[x/(x + F0[x])^2, x] + CannotIntegrate[1/(x + F0[x]), x]}
{F0[x]/(F0[x] + x^2)^2, x, 2, -CannotIntegrate[x^2/(x^2 + F0[x])^2, x] + CannotIntegrate[1/(x^2 + F0[x]), x]}

Removed them since they now give in sage an error unless the F0 is
defined correctly as function and not as a var as used to be the
case before:

------------------------
sage: var('F0 x')
sage: integrate(F0(x)/(x+F0(x)),x,algorithm="fricas")
TypeError: Substitution using function-call syntax and unnamed arguments has been removed.
-----------------------

It has now to be done this way

-----------------------
sage: var('x')
sage: function('F0')
sage: integrate(F0(x)/(x+F0(x)),x,algorithm="fricas")
integral(F0(x)/(x + F0(x)), x)
-----------------------

The problem is that the CAS test function which translates Maple
input files to Sage input files is not smart enough to know which
is var and which is a function in the input integrals, so it
makes everything a var for sagemath purposes.

This works for all the input files and all integrals, except the above 4.

So the easy solution for now was just to remove these 4 integrals
instead of writing a completely new translator. These were the
only 4 integrals out of the 85,000+ that used Functions and not just
variables in the integrand, and these 4 were all not integrable anyway,
so they cause no adverse effect on CAS systems results by removing them.

--Nasser

[Nasser M. Abbasi]

On 6/6/2022 3:35 AM, Nasser M. Abbasi wrote:
> FYI,
>
> A new CAS integration test build started. This is summer 2022 edition.
>
> <https://www.12000.org/my_notes/CAS_integration_tests/reports/summer_2022/index.htm>

FYI;

Posted also at:

<https://groups.google.com/g/fricas-devel/c/1egf0EkBMH4>

A small update is made for the summer 2022 edition
for CAS integration tests that only affects only Fricas, Maxima
and Giac to verify some result related to timeouts.

This below is the result for Fricas as it just finished. The others are
still running.

The following are the 9 integrals that fail in 1.3.8 vs. 1.3.7

In these, The integrals that fail due to time out is because of
the setting of setSimplifyDenomsFlag to true. Otherwise they
complete immediately.
========================================

integrate(x*(e*x^3+d)/(c*x^6+b*x^3+a),x) (time out due to flag)
integrate((e*x^3+d)/(c*x^6+b*x^3+a),x) (time out due to flag)
integrate((F^((-a*x+1)^(1/2)/(a*x+1)^(1/2)))^n/(-a^2*x^2+1),x) (not solved)
integrate(F^(3*(-a*x+1)^(1/2)/(a*x+1)^(1/2))/(-a^2*x^2+1),x) (not solved)
integrate(F^(2*(-a*x+1)^(1/2)/(a*x+1)^(1/2))/(-a^2*x^2+1),x) (not solved)
integrate(F^((-a*x+1)^(1/2)/(a*x+1)^(1/2))/(-a^2*x^2+1),x) (not solved)
integrate(sec(d*x+c)*(a+b*sin(d*x+c))^(5/2),x) (not solved)
integrate(cot(f*x+e)^2*(c+d*tan(f*x+e))^(1/3),x) (time out due to flag)
integrate(((x^2-3*x-4)*log(1+x)+((-x^3+3*x^2+4*x)*exp(x+7)+3*x^2-10*x-8)*log(x)+(-x^2+3*x+4)*exp(x+7)+x^3-4*x^2-5*x)/(x^3-3*x^2-4*x),x) (not solved)

The report is at

<https://12000.org/my_notes/CAS_integration_tests/reports/summer_2022/REGRESSION_REPORTS/fricas/report.htm>

There is also now a new _reverse regression report_. This shows
all integrals that were solved in Fricas 1.3.8 but failed in 1.3.7.

5,647 such integrals were found for Fricas. Many seem to be solved now
using the new weierstrass, weierstrassZeta, weierstrassPInverse
special functions introduced in 1.3.8.

The report at

<https://12000.org/my_notes/CAS_integration_tests/reports/summer_2022/REVERSE_REGRESSION_REPORT/fricas/report.htm>

It will take another 2-3 weeks to finish building the full
website again and all the individual reports for the other CAS systems
(each will have regression and reverse regression report also)
and the SQL database. Will make a post when done.

Any bugs/problems found please let me know.

--Nasser

[nob...@nowhere.invalid]

"Nasser M. Abbasi" schrieb:
>
> [...]

>
> The report is at
>
> <https://12000.org/my_notes/CAS_integration_tests/reports/summer_2022/REGRESSION_REPORTS/fricas/report.htm>
>
> There is also now a new _reverse regression report_. This shows
> all integrals that were solved in Fricas 1.3.8 but failed in 1.3.7.
>

"Reverse regression" should equal progression: A progress report?

> 5,647 such integrals were found for Fricas. Many seem to be solved now
> using the new weierstrass, weierstrassZeta, weierstrassPInverse
> special functions introduced in 1.3.8.
>
> The report at
>
> <https://12000.org/my_notes/CAS_integration_tests/reports/summer_2022/REVERSE_REGRESSION_REPORT/fricas/report.htm>
>

> [...]
>

Martin.

[Nasser M. Abbasi]

On 9/17/2022 6:19 AM, clicl...@freenet.de wrote:
>

>
> "Reverse regression" should equal progression: A progress report?
>

Sure. Will rename these to "progress report" next time I rebuild everything.

-Nasser

[Nasser M. Abbasi]

On 6/6/2022 3:35 AM, Nasser M. Abbasi wrote:
> FYI,
>
> A new CAS integration test build started. This is summer 2022 edition.
>
> <https://www.12000.org/my_notes/CAS_integration_tests/reports/summer_2022/index.htm>
>

Fyi,

The Regression and progress reports are now complete
(after the updated that was needed for the summer 2022 edition).

Links to these are now working on the above page. Here are the results

Regression summary
==================
Lower number is better. This gives number of integrals
that were not solved in current version but were solved
in previous version

Fricas 1.3.8 (sbcl 2.2.11.debian) via sagemath 9.6 vs. Fricas 1.3.7 via sagemath 9.3
9

Maxima 5.46 SBCL 2.0.1.debian via sagemath 9.6 vs. Maxima 5.44 via sagemath 9.3
13


Mathematica 13.1 vs. Mathematica 12.3
98

Maple 2022.1 vs. Maple 2021.1
114


Sympy 1.10.1 under Python 3.10.4 vs. Sympy 1.8 under Python 3.8.8
379

Giac 1.9.0-11 via sagemath 9.6 vs. Giac 1.7.0 via sagemath 9.3
379


Progress report
================
Higher number is better. This gives number of integrals
that were solved in current version but were not solved
in previous version

Fricas 1.3.8 (sbcl 2.2.11.debian) via sagemath 9.6 vs. Fricas 1.3.7 via sagemath 9.3
5647

Giac 1.9.0-11 via sagemath 9.6 vs. Giac 1.7.0 via sagemath 9.3
2866

Mathematica 13.1 vs. Mathematica 12.3
780

Sympy 1.10.1 under Python 3.10.4 vs. Sympy 1.8 under Python 3.8.8
379

Maxima 5.46 SBCL 2.0.1.debian via sagemath 9.6 vs. Maxima 5.44 via sagemath 9.3
300

Maple 2022.1 vs. Maple 2021.1
271

Any problems found please let me know so I can correct it.

The main reports and main web page still have not been updated
as it is still building now and will take about one week to finish.

Will post note when it is done, and that will be the end
of this summer 2022 edition as no more changes are needed
after that unless a new problems are found.

--Nasser

[Nasser M. Abbasi]

Opps, sorry, copied the wrong number below for SYMPY.

>
> Progress report
> ================

>
> Sympy 1.10.1 under Python 3.10.4 vs. Sympy 1.8 under Python 3.8.8
> 379

The above number should be 861 not 379. Copied the number from
the regression instead of progress page.

Here is the corrected list again.

Progress report
================
Higher number is better. This gives number of integrals
that were solved in current version but were not solved
in previous version

1. Fricas 1.3.8 (sbcl 2.2.11.debian) via sagemath 9.6 vs. Fricas 1.3.7 via sagemath 9.3
5647

2. Giac 1.9.0-11 via sagemath 9.6 vs. Giac 1.7.0 via sagemath 9.3
2866

3. Sympy 1.10.1 under Python 3.10.4 vs. Sympy 1.8 under Python 3.8.8
861

4. Mathematica 13.1 vs. Mathematica 12.3
780

5. Maxima 5.46 SBCL 2.0.1.debian via sagemath 9.6 vs. Maxima 5.44 via sagemath 9.3
300

6. Maple 2022.1 vs. Maple 2021.1
271

--Nasser

[Nasser M. Abbasi]

On 6/6/2022 3:35 AM, Nasser M. Abbasi wrote:
> FYI,
>
> A new CAS integration test build started. This is summer 2022 edition.
>

FYI;

The first update to summer 2022 edition of CAS integration test
is now complete.

<https://12000.org/my_notes/CAS_integration_tests/reports/summer_2022/index.htm>

Number of integrals remain the same at 85,479.

This update was needed for the following:
=====================================

1. Added new check on Fricas result to detected 0 result
as failed. Before it was counted as passed. There was 124
such case (one of these is valid as integrand is zero)

sqlite> select COUNT(*) from main where fricas_anti=0;
125

This reduced Fricas % pass score by only 0.15 %. Hopefully
these integrals will be fixed in the next version of Fricas.

2. re-run all of Fricas/Giac/Maxima tests to make sure there was
no false time out by improving the sagemath script. Only few such
false timeouts were found and corrected.

3. Reduced the size of the pdf's and web pages by only showing
small part of the anti-derivative for a very long result (which
used to take many pages before). There is an issue with sagemath
interface to Fricas which causes this on some integrals. This
should be fixed in sagemath 9.8.

4. Updated the SQL database for current update.

CAS tested
=================
Mathematica 13.1 (June 29, 2022) on windows 10.
Rubi 4.16.1 on Mathematica 13.0.1 on windows 10.
Maple 2022.1 on windows 10.
Maxima 5.46 using Lisp SBCL 2.1.11.debian via sagemath 9.6.
Fricas 1.3.8 based on sbcl 2.1.11.debian via sagemath 9.6.
Giac/Xcas 1.9.0-13 via sagemath 9.6.
Sympy 1.10.1 Using Python 3.10.4 on Linux.
Mupad using Matlab 2021a on windows 10.


Percentage solved (compared to summer 2021 build)
2022 2021
===== ======

Mathematica 97.99 % 98.39 %
Rubi 94.21 % 99.52 %
Maple 84.53 % 83.58 %

Fricas 79.27 % 68.70 %
Giac 58.45 % 52.43 %
Maxima 56.88 % 52.72 %

Mupad 56.10 % 52.55 %
Sympy 41.89 % 34.47 %

Fricas had the best improvement followed by Sympy and Giac from last year.

Maxima can improve the score more if there is a way to eliminate it
asking question during the integration which cause it to fail
in those cases.

Grading %
===========
System A B C F
------- ----- ----- ---- ----
Rubi 91.5 1.95 0.75 5.79
Mathematica 78.58 6.21 13.18 2.01
Maple 56.34 18.53 9.66 15.47
Fricas 53.82 19.55 5.9 20.73
Maxima 43.57 11.69 1.62 43.12
Giac 42.41 14.98 1.06 41.55
Sympy 28.49 9.81 3.6 58.11
Mupad* 4.15 51.95 0. 43.9

(*)Mupad is not graded. B is given as placeholder
for now.

Average Time per second
=========================
Rubi 0.26
Maxima 0.53
Giac 1.55
Fricas 1.97
Mathematica 2.38
Mupad 2.74
Maple* 3.33
Sympy 5.24

Maple(*) timing: the option method=_RETURNVERBOSE was used
which made Maple run through all integration methods increasing

its average time used.

The regression, progress and SQL database can be accessed from the main
page. Here are the direct links

<https://12000.org/my_notes/CAS_integration_tests/reports/summer_2022/REGRESSION_REPORTS/index.htm>
<https://12000.org/my_notes/CAS_integration_tests/reports/summer_2022/REVERSE_REGRESSION_REPORT/index.htm>
<https://12000.org/my_notes/CAS_integration_tests/reports/summer_2022/DATA_BASE/index.htm>

Hopefully no more updates will be needed unless problems are found.

--Nasser

[Валерий Заподовников]

How is that possible 0 was not compared against correct antiderivative?
Was that always wrong? Fricas-devel topic?

Also did you check not solved by Wolfram 13.1 whether those are fixed by
changing the timeout for IntegrateAlgebraic to 100 seconds??

[Nasser M. Abbasi]

On 9/29/2022 3:14 AM, Валерий Заподовников wrote:
> How is that possible 0 was not compared against correct antiderivative?
>

This was discussed before. Verification of CAS anti-derivative
is only done for Rubi and Mathematica. All other CAS systems
that finish in time and do not echo back its input, or the output
do not have unevaluated integrals, then its assumed to have
"solved" the integral and masked as solved.

Grading does not verify the correctness. It only applies
some criteria to the anti-derivative found using the
optimal result as a benchmark. All of these are described
on the web pages:

<https://12000.org/my_notes/CAS_integration_tests/reports/summer_2022/indexchapter1.htm#x2-30001.2>
<https://12000.org/my_notes/CAS_integration_tests/reports/summer_2022/indexchapter1.htm#x2-90001.7>

Now the 0 antiderivative is explictly checked for and marked as failed if
detected.

> Was that always wrong? Fricas-devel topic?

Fricas developers know about this and this was mentioned here
also before sometime ago.

"the problem of zero result for antiderivative instead of not solved"
<https://groups.google.com/g/fricas-devel/c/OcHBQgoBONM>

Hopefully this will be fixed in a future version of Fricas.

> Also did you check not solved by Wolfram 13.1 whether those are fixed by
> changing the timeout for IntegrateAlgebraic to 100 seconds??

> SetSystemOptions[
> "IntegrateOptions" -> {"IntegrateAlgebraicTimeConstraint" -> 100}];

No. There are no changes made to any integration options
specific to any one integral. Whatever the default the CAS uses, then
that is what is used.

There is a ticket submitted to WRI on this. Hopefully these
few regressions in Mathematica Intergate will be fixed in a future version.

<https://mathematica.stackexchange.com/questions/263247/why-these-integrals-fail-to-evaluate-in-v-13-compared-to-v-12-3>

--Nasser

[Nasser M. Abbasi]

Fyi,

With the help of the SQL database I am using now for CAS integration tests,
I was able to generate some more interesting observations.

Added new statistic section called "Performance based on Rubi rules"

<https://12000.org/my_notes/CAS_integration_tests/reports/summer_2022/indexchapter1.htm#x2-50001.3>

This section basically looks at how percentage solved by each CAS
correlate to how many rules and how many steps Rubi itself used
to solve the same integral.

I also added histograms showing distribution of leaf size of anti-derivatives
for each CAS.

Hope this is something that is useful to see.

--Nasser

[Валерий Заподовников]

"few regressions in Mathematica Intergate will be fixed in a future version."

No, as we discussed increasing the timeout for IntegrateAlgebraic can fix unsolved integrals. Try

e.g. Integrate[x/Sqrt[x^4 - 2 x^3 + 3 x^2 + 4 x + 1], x]

It only makes sense to use it on integrals that were not solved or were solved with not elementary functions,
when we know elementary antiderivatibe exists.

[nob...@nowhere.invalid]

"Nasser M. Abbasi" schrieb:

Interesting indeed.

The performance of Mathematica, Maple, and FriCAS in dependence on the
number of distinct rules used by Rubi exhibits a plateau or even a rise
over the range from 4 to 7 rules. May this be caused by some
peculiarity in the construction of the Rubi test suite in particular,
rather than by features of the integration algorithms fielded by the
three competitors? The other four systems show a fairly steady decrease
with the number of rules.

The performance in dependence on the total number of steps used by Rubi
also shows a diffrence between the behavior of Mathematica, Maple, and
FriCAS, and that of Giac, Maxima, Mupad, and Sympy: a gradual decrease
for the first three systems, versus a small increase at two steps that
changes to a relatively fast decrease up to 8 or 10 steps that is
followed by a plateau for the last four systems. Again, two groups of
algorithms appear to react differently to the overall testsuite.

In the histograms of the number of integrals solved versus leaf size of
the antiderivative, Rubi is exceptional in that the first bin (of sizes
below 40 leaves) does not hold significantly more integrals than the
next one (from 40 to 80 leaves) contains, whereas all bins for all
other systems conform to a general decrease with leaf count. Could this
be caused specifically by Rubi's poor performance on Waldek's integrals
based on 10'000 random antiderivatives?

Martin.

[Nasser M. Abbasi]

On 10/9/2022 12:12 PM, clicl...@freenet.de wrote:

>
> Interesting indeed.
>
> The performance of Mathematica, Maple, and FriCAS in dependence on the
> number of distinct rules used by Rubi exhibits a plateau or even a rise
> over the range from 4 to 7 rules. May this be caused by some
> peculiarity in the construction of the Rubi test suite in particular,
> rather than by features of the integration algorithms fielded by the
> three competitors? The other four systems show a fairly steady decrease
> with the number of rules.
>
> The performance in dependence on the total number of steps used by Rubi
> also shows a diffrence between the behavior of Mathematica, Maple, and
> FriCAS, and that of Giac, Maxima, Mupad, and Sympy: a gradual decrease
> for the first three systems, versus a small increase at two steps that
> changes to a relatively fast decrease up to 8 or 10 steps that is
> followed by a plateau for the last four systems. Again, two groups of
> algorithms appear to react differently to the overall testsuite.
>
> In the histograms of the number of integrals solved versus leaf size of
> the antiderivative, Rubi is exceptional in that the first bin (of sizes
> below 40 leaves) does not hold significantly more integrals than the
> next one (from 40 to 80 leaves) contains, whereas all bins for all
> other systems conform to a general decrease with leaf count. Could this
> be caused specifically by Rubi's poor performance on Waldek's integrals
> based on 10'000 random antiderivatives?
>
> Martin.

If anyone has suggestions of other useful statistics to generate, feel
free to let me know.

With SQL, it is much much easier to generate all sorts of statistics
than before because I can just do SQL command to obtain any sort
of information I want now. Before, I had to code all these things
manually.

I just do not now what other useful stats I could ask. But If
I think of other things, will add them.

--Nasser