• fyi, a new CAS integration file added. IntegrateAlgebraic

    From Nasser M. Abbasi@21:1/5 to All on Thu Aug 26 04:24:20 2021
    fyi;

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

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

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

    The following is link to test results

    The following systems were tested on this file:

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

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

    Any problems, please let me know.

    --Nasser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From nobody@nowhere.invalid@21:1/5 to Nasser M. Abbasi on Thu Aug 26 18:56:19 2021
    "Nasser M. Abbasi" schrieb:

    fyi;

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

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

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

    The following is link to test results

    The following systems were tested on this file:

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

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

    Any problems, please let me know.


    And these are the results from the 2nd link:

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

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

    Martin.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nasser M. Abbasi@21:1/5 to clicliclic@freenet.de on Mon Aug 30 17:36:33 2021
    On 8/26/2021 11:56 AM, clicliclic@freenet.de wrote:


    And these are the results from the 2nd link:

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

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

    Martin.


    Hello Matrin;

    was its Trager method really activated?

    I really do not know. I looked at help in

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

    and it says

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

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

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

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

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

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

    --Nasser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From nobody@nowhere.invalid@21:1/5 to Nasser M. Abbasi on Tue Aug 31 18:07:04 2021
    "Nasser M. Abbasi" schrieb:

    On 8/26/2021 11:56 AM, clicliclic@freenet.de wrote:

    And these are the results from the 2nd link:

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

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


    was its Trager method really activated?

    I really do not know. I looked at help in

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

    and it says

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

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

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

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

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

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


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

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

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

    Martin.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nasser M. Abbasi@21:1/5 to clicliclic@freenet.de on Tue Aug 31 11:27:52 2021
    On 8/31/2021 11:07 AM, clicliclic@freenet.de wrote:


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

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

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

    Martin.


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

    For an example, I can change Maple test to do

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

    Which gives

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

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

    summer_2021/test_cases/9_Blake_problems

    test and see if Maple result improves or not.

    regards,
    --Nasser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From nobody@nowhere.invalid@21:1/5 to Nasser M. Abbasi on Tue Aug 31 19:16:25 2021
    "Nasser M. Abbasi" schrieb:

    On 8/31/2021 11:07 AM, clicliclic@freenet.de wrote:


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

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

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

    Martin.


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

    For an example, I can change Maple test to do

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

    Which gives

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

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

    summer_2021/test_cases/9_Blake_problems

    test and see if Maple result improves or not.


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

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

    Martin.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nasser M. Abbasi@21:1/5 to clicliclic@freenet.de on Wed Sep 1 12:58:25 2021
    On 8/31/2021 12:16 PM, clicliclic@freenet.de wrote:


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

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

    Martin.


    I just finished re-running the 3154 problems in

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

    Just on Maple, by adding

    method = default,trager]

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

    The score for Maple went down!

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

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

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

    returns unevaluated.

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

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

    but this works

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

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

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

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

    Help says

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

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

    The method option was updated in Maple 2021.

    I am using Maple 2021.1 on windows 10.

    --Nasser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nasser M. Abbasi@21:1/5 to All on Wed Sep 1 13:19:03 2021
    fyi, here is another what looks like a bug in Trager

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

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

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

    Maple 2021.1, windows 10.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From antispam@math.uni.wroc.pl@21:1/5 to Nasser M. Abbasi on Thu Sep 2 00:45:43 2021
    Nasser M. Abbasi <nma@12000.org> wrote:
    On 8/31/2021 12:16 PM, clicliclic@freenet.de wrote:


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

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

    Martin.


    I just finished re-running the 3154 problems in

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

    Just on Maple, by adding

    method = default,trager]

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

    The score for Maple went down!

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

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

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

    returns unevaluated.

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

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

    but this works

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

    Have you tried

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

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

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

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

    --
    Waldek Hebisch

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nasser M. Abbasi@21:1/5 to antispam@math.uni.wroc.pl on Wed Sep 1 20:22:53 2021
    On 9/1/2021 7:45 PM, antispam@math.uni.wroc.pl wrote:
    Nasser M. Abbasi <nma@12000.org> wrote:
    On 8/31/2021 12:16 PM, clicliclic@freenet.de wrote:


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

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

    Martin.


    I just finished re-running the 3154 problems in

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

    Just on Maple, by adding

    method = default,trager]

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

    The score for Maple went down!

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

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

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

    returns unevaluated.

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

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

    but this works

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

    Have you tried

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


    yes, I tried it, but it returns unevaluated

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

    same input is echoed back. Same using method=Trager

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

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

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



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

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

    So it looks that it is similar to _DEFAULT:

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

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

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

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

    regards,
    --Nasser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From antispam@math.uni.wroc.pl@21:1/5 to Nasser M. Abbasi on Thu Sep 2 10:34:12 2021
    Nasser M. Abbasi <nma@12000.org> wrote:
    On 9/1/2021 7:45 PM, antispam@math.uni.wroc.pl wrote:
    Nasser M. Abbasi <nma@12000.org> wrote:
    On 8/31/2021 12:16 PM, clicliclic@freenet.de wrote:


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

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

    Martin.


    I just finished re-running the 3154 problems in

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

    Just on Maple, by adding

    method = default,trager]

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

    The score for Maple went down!

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

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

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

    returns unevaluated.

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

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

    but this works

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

    Have you tried

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


    yes, I tried it, but it returns unevaluated

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

    same input is echoed back. Same using method=Trager

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

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

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



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

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

    So it looks that it is similar to _DEFAULT:

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

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

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

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

    Probably better to use _RETURNVERBOSE, then it will be clear
    which method worked.

    --
    Waldek Hebisch

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From nobody@nowhere.invalid@21:1/5 to Nasser M. Abbasi on Thu Sep 2 18:16:41 2021
    "Nasser M. Abbasi" schrieb:

    [...]

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


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

    Martin.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nasser M. Abbasi@21:1/5 to clicliclic@freenet.de on Fri Sep 3 13:21:42 2021
    On 9/2/2021 11:16 AM, clicliclic@freenet.de wrote:

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

    Martin.


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

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

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

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

    But

    int(integrand,x);

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

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

    I send bug report on the above to maplesoft.

    Maple 2021.1 on windows 10.
    --Nasser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nasser M. Abbasi@21:1/5 to Nasser M. Abbasi on Fri Sep 3 16:04:00 2021
    On 9/3/2021 1:21 PM, Nasser M. Abbasi wrote:
    On 9/2/2021 11:16 AM, clicliclic@freenet.de wrote:

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

    Martin.


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

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

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

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

    But

    int(integrand,x);

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

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

    I send bug report on the above to maplesoft.

    Maple 2021.1 on windows 10.
    --Nasser


    I am starting to think that int() with method=_RETURNVERBOSE is not a
    superset that includes the result obtained when just using int()

    Here is another strange result that I do not understand

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

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

    But

    int(integrand,x);

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

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

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

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

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

    Maple 2021.1

    --Nasser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From nobody@nowhere.invalid@21:1/5 to Nasser M. Abbasi on Sat Sep 4 20:28:08 2021
    "Nasser M. Abbasi" schrieb:

    On 9/3/2021 1:21 PM, Nasser M. Abbasi wrote:
    On 9/2/2021 11:16 AM, clicliclic@freenet.de wrote:

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

    Martin.


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

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

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

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

    But

    int(integrand,x);

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

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

    I send bug report on the above to maplesoft.

    Maple 2021.1 on windows 10.
    --Nasser


    I am starting to think that int() with method=_RETURNVERBOSE is not a superset that includes the result obtained when just using int()

    Here is another strange result that I do not understand

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

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

    But

    int(integrand,x);

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

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

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

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

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

    Maple 2021.1


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

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

    Martin.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From antispam@math.uni.wroc.pl@21:1/5 to Nasser M. Abbasi on Fri Sep 17 21:41:45 2021
    Nasser M. Abbasi <nma@12000.org> wrote:
    fyi;

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

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

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

    The following is link to test results

    The following systems were tested on this file:

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

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

    Any problems, please let me know.

    I puzzled by some FriCAS results in your report.

    2: I get

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

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

    you report timeout.

    2892:

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

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

    --
    Waldek Hebisch

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nasser M. Abbasi@21:1/5 to antispam@math.uni.wroc.pl on Fri Sep 17 18:37:13 2021
    On 9/17/2021 4:41 PM, antispam@math.uni.wroc.pl wrote:

    Results and statistics are given in the above link in PDF and HTML format. >>
    Any problems, please let me know.

    I puzzled by some FriCAS results in your report.

    2: I get

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

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

    you report timeout.

    2892:

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

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


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

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

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

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

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

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

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

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

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

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

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

    --Nasser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From antispam@math.uni.wroc.pl@21:1/5 to Nasser M. Abbasi on Sun Sep 19 01:22:37 2021
    Nasser M. Abbasi <nma@12000.org> wrote:
    On 9/17/2021 4:41 PM, antispam@math.uni.wroc.pl wrote:

    Results and statistics are given in the above link in PDF and HTML format. >>
    Any problems, please let me know.

    I puzzled by some FriCAS results in your report.

    2: I get

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

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

    you report timeout.

    2892:

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

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


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

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

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

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

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

    Thanks for info. I looked at few other cases and AFAICS in
    those cases timeout was justified. So I do not expect
    significant change to results. For me it is more important
    to understand what happened.

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

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

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

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

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

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

    --
    Waldek Hebisch

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nasser M. Abbasi@21:1/5 to antispam@math.uni.wroc.pl on Sat Sep 18 23:27:40 2021
    On 9/18/2021 8:22 PM, antispam@math.uni.wroc.pl wrote:
    Nasser M. Abbasi <nma@12000.org> wrote:
    On 9/17/2021 4:41 PM, antispam@math.uni.wroc.pl wrote:

    Results and statistics are given in the above link in PDF and HTML format. >>>>
    Any problems, please let me know.

    I puzzled by some FriCAS results in your report.

    2: I get

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

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

    you report timeout.

    2892:

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

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


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

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

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

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

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

    Thanks for info. I looked at few other cases and AFAICS in
    those cases timeout was justified. So I do not expect
    significant change to results. For me it is more important
    to understand what happened.

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

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

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

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



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


    Fricas is called from sagemath. The call to Fricas is made from
    the child process that is created in the script above
    in order to do the timeout.

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

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

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

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

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

    This has to be done in 3 minutes.

    So for each integral, 2 processes are created.

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

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

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

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

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

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

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

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


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

    Best regards,
    --Nasser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dr Huang@21:1/5 to Nasser M. Abbasi on Fri Oct 22 18:25:30 2021
    On Thursday, 26 August 2021 at 19:24:26 UTC+10, Nasser M. Abbasi wrote:
    fyi;

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

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

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

    The following is link to test results

    The following systems were tested on this file:

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

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

    Any problems, please let me know.

    --Nasser

    Which system can integrate(x^x,x)?
    May I suggest you add MathHand.com to test?
    10. MathHand.com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From nobody@nowhere.invalid@21:1/5 to Dr Huang on Sat Oct 23 19:37:55 2021
    Dr Huang schrieb:

    [...]

    Which system can integrate(x^x,x)?

    [...]

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

    Martin.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)