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