• Julia is the future of RUBI !

    From Peter Luschny@21:1/5 to All on Mon Mar 1 14:57:21 2021
    ... and some other things. Exciting news.

    https://juliasymbolics.org/roadmap/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From nobody@nowhere.invalid@21:1/5 to Peter Luschny on Wed Mar 3 18:13:01 2021
    Peter Luschny schrieb:

    ... and some other things. Exciting news.

    https://juliasymbolics.org/roadmap/

    Nasser may have to revise his script if he wants to see how future
    RUBIs performs on the integration testsuite.

    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 Mar 3 11:26:03 2021
    On 3/3/2021 11:13 AM, clicliclic@freenet.de wrote:

    Peter Luschny schrieb:

    ... and some other things. Exciting news.

    https://juliasymbolics.org/roadmap/

    Nasser may have to revise his script if he wants to see how future
    RUBIs performs on the integration testsuite.

    Martin.


    Sure, will add Julia/Rubi if and when it gets ported to Julia. I have
    Julia 1.5.3 up and running on my Linux box, and use it symbolics occasionally just to learn the syntax.

    Albert Rich mentioned that he is working on changing Rubi to use
    If/then/else logic instead of patterns for the rules, so that Rubi
    can be more easily ported/converted to other systems.

    The port of Rubi to Sympy seems to have been abandoned now unfortunately,
    after a promising start in earlier versions of Sympy. May be due to lack
    of resources to finish the port.

    --Nasser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Axel Kramer@21:1/5 to peter on Thu Mar 4 04:36:56 2021
    peter schrieb am Montag, 1. März 2021 um 23:57:22 UTC+1:
    ... and some other things. Exciting news.

    https://juliasymbolics.org/roadmap/

    at least for Rubi Version 4.16 IMO, it's not so easy to port it to another language.

    From my experience you have to
    - implement the rewriting rules in the same order as they are used in MMA.
    - implement very special functions like for example: TimeConstrained and Defer - to get the same results for the JUnit tests you have to implement things like Simplify, FullSimplify, PossibleZeroQ,... very similar to MMA
    - bugs in recursive calls of the rule engine are difficult to fix (at least in the current state of the project, without a suitable debugger)

    This may be changing for the Rubi version with If/then/else logic ?

    In case someone is interested in the approach we've chosen, here is a short description:
    - https://github.com/axkr/symja_android_library/wiki/Porting-Rubi-Integration-rules-to-Symja

    The simple JUnit test cases which are described in the WIki should work with one exception.

    But the more complicated JUnit test cases in the following folder still contain a lot of bugs/timeouts:
    - https://github.com/axkr/symja_android_library/tree/master/symja_android_library/matheclipse-io/src/test/java/org/matheclipse/core/rubi/step02

    The JUnit test cases are partially generated from the Rubi test suite.

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

    On 3/3/2021 11:13 AM, clicliclic@freenet.de wrote:

    Peter Luschny schrieb:

    ... and some other things. Exciting news.

    https://juliasymbolics.org/roadmap/

    Nasser may have to revise his script if he wants to see how future
    RUBIs performs on the integration testsuite.

    Martin.


    Sure, will add Julia/Rubi if and when it gets ported to Julia. I have
    Julia 1.5.3 up and running on my Linux box, and use it symbolics
    occasionally just to learn the syntax.


    What is your impression of the range of symbolic capabilities available
    and of the maturity of their implementation?

    Martin.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Peter Luschny@21:1/5 to All on Thu Mar 4 12:54:39 2021
    From my experience you have to
    - implement the rewriting rules in the same order as they are used in MMA.
    - implement very special functions like for example: TimeConstrained and Defer
    - to get the same results for the JUnit tests you have to implement things like Simplify, FullSimplify, PossibleZeroQ,... very similar to MMA
    - bugs in recursive calls of the rule engine are difficult to fix (at least in the current state of the project, without a suitable debugger)
    This may be changing for the Rubi version with If/then/else logic ?

    I think the next big step has indeed to come from RUBI again: to get rid of all these implicit dependencies. After that, any porting, but especially one to Julia, should be quite fast doable and in fact happen quickly.

    Has Albert Rich already commented on the schedule for the 'logic'-version?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nasser M. Abbasi@21:1/5 to clicliclic@freenet.de on Thu Mar 4 16:29:35 2021
    On 3/4/2021 12:32 PM, clicliclic@freenet.de wrote:

    "Nasser M. Abbasi" schrieb:

    On 3/3/2021 11:13 AM, clicliclic@freenet.de wrote:

    Peter Luschny schrieb:

    ... and some other things. Exciting news.

    https://juliasymbolics.org/roadmap/

    Nasser may have to revise his script if he wants to see how future
    RUBIs performs on the integration testsuite.

    Martin.


    Sure, will add Julia/Rubi if and when it gets ported to Julia. I have
    Julia 1.5.3 up and running on my Linux box, and use it symbolics
    occasionally just to learn the syntax.


    What is your impression of the range of symbolic capabilities available
    and of the maturity of their implementation?

    Martin.


    Martin;

    I am still very much a newbie in Julia symbolics. They have few examples
    in

    https://symbolics.juliasymbolics.org/ under the Manual section.

    Only thing so far I found which I did not like too much, is
    when taking derivative of expression Z w.r.t say x, one
    has to define the derivative part w.r.t. x, on a separate line,
    then apply it on the expression on next line. Like this:

    ============
    @variables x y;
    D = Differential(x)
    ....few line later one can do....
    D(y) # Differentiate y wrt. x
    ==========

    One can't write on same line

    diff(y(x),x)

    as normally with say Maple or Mathematica, etc... which
    for me is more clear since one sees the expression and the
    variable x, on same line. May be there is a way around
    this.

    But it is easy to install if you like to try it.

    wget https://julialang-s3.julialang.org/bin/linux/x64/1.5/julia-1.5.3-linux-x86_64.tar.gz
    tar zxvf julia-1.5.3-linux-x86_64.tar.gz

    Then edit your .bashrc and the above created to folder to your PATH.

    Now type julia on the Linux command line. It will come up.
    add symbolics first time to install it:

    using Pkg
    Pkg.add("Symbolics")


    They have other symbolic packages. Please see

    https://symbolics.juliasymbolics.org/dev/#Installation-1

    It is still fairly new, and documentation is not extensive yet
    for symbolics.

    --Nasser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From nobody@nowhere.invalid@21:1/5 to Axel Kramer on Fri Mar 5 18:28:08 2021
    Axel Kramer schrieb:

    peter schrieb am Montag, 1. März 2021 um 23:57:22 UTC+1:
    ... and some other things. Exciting news.

    https://juliasymbolics.org/roadmap/

    at least for Rubi Version 4.16 IMO, it's not so easy to port it to another language.

    From my experience you have to
    - implement the rewriting rules in the same order as they are used in MMA.
    - implement very special functions like for example: TimeConstrained and Defer
    - to get the same results for the JUnit tests you have to implement things like Simplify, FullSimplify, PossibleZeroQ,... very similar to MMA
    - bugs in recursive calls of the rule engine are difficult to fix (at least in the current state of the project, without a suitable debugger)

    This may be changing for the Rubi version with If/then/else logic ?

    In case someone is interested in the approach we've chosen, here is a short description:
    - https://github.com/axkr/symja_android_library/wiki/Porting-Rubi-Integration-rules-to-Symja

    The simple JUnit test cases which are described in the WIki should work with one exception.

    But the more complicated JUnit test cases in the following folder still contain a lot of bugs/timeouts:
    - https://github.com/axkr/symja_android_library/tree/master/symja_android_library/matheclipse-io/src/test/java/org/matheclipse/core/rubi/step02

    The JUnit test cases are partially generated from the Rubi test suite.


    Your work concerns a port of Rubi to a symbolic extension of Java.

    There are 1092 failed symbolic integrations recorded in your log file failed_rubi_tests.txt. Did the tests involve the full problem suites
    from Albert's site, or just subsets, perhaps chosen for simplicity?

    A good estimate of a symbolic integrator's strength is already given by
    the percentage of the 705 integrals from the Timofeev suite that it can
    solve. How many of them can your present Rubi port handle?

    Martin.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Fateman@21:1/5 to All on Fri Mar 5 16:10:46 2021
    Since pattern matching in Mathematica can be used to invoke any computation possible in Mathematica, there is a superficial implausibility that all of Rubi can be moved without implementing a substantial chunk of Mathematica-simulation code -- say
    simplification of various sorts.

    Now if Albert and friends have arranged for Rubi's matching and replacement to be simply tree-traversals (checking the main operator, etc.) and tree substitutions, that would be really great.
    I think we are not there yet, and as Rubi grows, that goal may be retreating to the back burner.

    A few years ago I downloaded a bunch of Rubi files, ran them through my Mathematica parser (written in Common Lisp) and ran a bunch of tests successfully through my mma mathematica-like evaluator.

    There were glitches, and I set the project aside waiting for the version of Rubi that was promised to use just if-then-else. Still in the future, apparently. My code is freely available.

    I'd be happy to see Rubi in python, julia, c, Reduce, Axiom.... etc.

    Just mentioning that there is already
    at least one lisp system that can parse Mathematica, understanding the pattern syntax,
    and do rudimentary symbolic arithmetic (it could do more by using Maxima, just sitting by the side
    in this setup). So hearing Rubi can be done in X [not Lisp] means to me

    (a) Someone else (Albert? or X-fan) has translated the source code to a form Y that can be loaded into an X system
    (b) Someone has implemented a program that can read a test problem P and run it through the matching program comparing it to patterns in Y, and find /display a match if one is found.

    If the Rubi code includes calls to, say, SuperFullSimplify[..], then there is some extra work needed by the X-fans. I wasn't keen on that, mimicking exact results. Just saying.

    RJF

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Axel Kramer@21:1/5 to nob on Fri Mar 5 16:06:39 2021
    nob schrieb am Freitag, 5. März 2021 um 18:23:28 UTC+1:
    Your work concerns a port of Rubi to a symbolic extension of Java.

    There are 1092 failed symbolic integrations recorded in your log file failed_rubi_tests.txt. Did the tests involve the full problem suites
    from Albert's site, or just subsets, perhaps chosen for simplicity?
    No these are selected test cases, where Rubi uses only 1 or 2 times the integration rules so that we can see in development if the correct rule was used.

    A good estimate of a symbolic integrator's strength is already given by
    the percentage of the 705 integrals from the Timofeev suite that it can solve. How many of them can your present Rubi port handle?

    - Charlwood 19 from 50 tests fail
    - Timoveef 150 from 705 fail

    For these tests I've not analyzed if there are "false negatives", which can occur if the result isn't exactly the same as in the predefined Rubi tests.

    I've used the tests from here and converted them to JUnit test cases: https://rulebasedintegration.org/TestFiles/MathematicaSyntaxFiles/MathematicaSyntaxTestFiles.zip

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From nobody@nowhere.invalid@21:1/5 to Axel Kramer on Sun Mar 7 19:05:06 2021
    Axel Kramer schrieb:

    nob schrieb am Freitag, 5. März 2021 um 18:23:28 UTC+1:
    Your work concerns a port of Rubi to a symbolic extension of Java.

    There are 1092 failed symbolic integrations recorded in your log
    file failed_rubi_tests.txt. Did the tests involve the full problem
    suites from Albert's site, or just subsets, perhaps chosen for
    simplicity?
    No these are selected test cases, where Rubi uses only 1 or 2 times
    the integration rules so that we can see in development if the
    correct rule was used.

    A good estimate of a symbolic integrator's strength is already
    given by the percentage of the 705 integrals from the Timofeev
    suite that it can solve. How many of them can your present Rubi
    port handle?

    - Charlwood 19 from 50 tests fail
    - Timoveef 150 from 705 fail

    In view of last year's Timofeev test runs by Nasser:

    system solved failed
    ------------------------------------------
    Rubi %100.00 (705) %0.00 (0)
    Mathematica %100.00 (705) %0.00 (0)
    Fricas %92.20 (650) %7.80 (55)
    Maple %91.77 (647) %8.23 (58)
    Giac %80.00 (564) %20.00 (141)
    Maxima %76.88 (542) %23.12 (163)
    Sympy %59.86 (422) %40.14 (283) ------------------------------------------

    your Rubi port to SymJa already solving 555/705 = %78.72 of the
    Timofeev integrals and failing on 150/705 = %21.28 of them puts its
    integration strength between that of Giac and Maxima, and also (by an
    older test run) in front of that of:

    Mupad %76.74 (541) %23.26 (164)

    and of course well ahead of that of Sympy!


    For these tests I've not analyzed if there are "false negatives",
    which can occur if the result isn't exactly the same as in the
    predefined Rubi tests.

    I've used the tests from here and converted them to JUnit test cases: https://rulebasedintegration.org/TestFiles/MathematicaSyntaxFiles/MathematicaSyntaxTestFiles.zip

    Martin.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nasser M. Abbasi@21:1/5 to Nasser M. Abbasi on Tue Mar 9 20:51:51 2021
    On 3/4/2021 4:29 PM, Nasser M. Abbasi wrote:

    Only thing so far I found which I did not like too much, is
    when taking derivative of expression Z w.r.t say x, one
    has to define the derivative part w.r.t. x, on a separate line,
    then apply it on the expression on next line. Like this:

    ============
    @variables x y;
    D = Differential(x)
    ....few line later one can do....
    D(y) # Differentiate y wrt. x
    ==========

    One can't write on same line

    diff(y(x),x)

    as normally with say Maple or Mathematica, etc... which
    for me is more clear since one sees the expression and the
    variable x, on same line. May be there is a way around
    this.

    Ok, figured it out
    ==========================
    julia> using Symbolics;
    julia> @variables x y;
    julia> y=x^2*sin(x);
    julia> expand_derivatives(Differential(x)(y))


    cos(x)*(x^2) + 2x*sin(x)
    ============================

    So
    diff(y,x)

    translates to

    expand_derivatives(Differential(x)(y))

    --Nasser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nasser M. Abbasi@21:1/5 to clicliclic@freenet.de on Wed Mar 10 12:41:43 2021
    On 3/10/2021 12:35 PM, clicliclic@freenet.de wrote:

    "Nasser M. Abbasi" schrieb:

    On 3/4/2021 4:29 PM, Nasser M. Abbasi wrote:

    Only thing so far I found which I did not like too much, is
    when taking derivative of expression Z w.r.t say x, one
    has to define the derivative part w.r.t. x, on a separate line,
    then apply it on the expression on next line. Like this:

    ============
    @variables x y;
    D = Differential(x)
    ....few line later one can do....
    D(y) # Differentiate y wrt. x
    ==========

    One can't write on same line

    diff(y(x),x)

    as normally with say Maple or Mathematica, etc... which
    for me is more clear since one sees the expression and the
    variable x, on same line. May be there is a way around
    this.

    Ok, figured it out
    ==========================
    julia> using Symbolics;
    julia> @variables x y;
    julia> y=x^2*sin(x);
    julia> expand_derivatives(Differential(x)(y))

    cos(x)*(x^2) + 2x*sin(x)
    ============================

    So
    diff(y,x)

    translates to

    expand_derivatives(Differential(x)(y))




    This forces one to type 38 instead of 9 characters. I suspect that the "expand_derivatives()" can be replaced by some general-purpose command
    like "evaluate()", however.

    Does the system distinguish upper from lower case? Would "differential"
    or "Expand_derivatives" thus fail?

    Martin.


    It will fail yes, Julia is Case sensitive.
    The reason for expand_derivatives is because Differential
    is a "lazy" operator. So this causes it to evaluate.

    I agree, it is much more verbose than "diff(y,x)" or "D[y,x]"
    but that is the only way I found to have the expression and
    the differentiation variable show up on same line.

    I am sure one can write a function to wrap all this in,
    call it "diff(expression,variable)", to reduce the typing to do each time.

    --Nasser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From nobody@nowhere.invalid@21:1/5 to Nasser M. Abbasi on Wed Mar 10 19:35:58 2021
    "Nasser M. Abbasi" schrieb:

    On 3/4/2021 4:29 PM, Nasser M. Abbasi wrote:

    Only thing so far I found which I did not like too much, is
    when taking derivative of expression Z w.r.t say x, one
    has to define the derivative part w.r.t. x, on a separate line,
    then apply it on the expression on next line. Like this:

    ============
    @variables x y;
    D = Differential(x)
    ....few line later one can do....
    D(y) # Differentiate y wrt. x
    ==========

    One can't write on same line

    diff(y(x),x)

    as normally with say Maple or Mathematica, etc... which
    for me is more clear since one sees the expression and the
    variable x, on same line. May be there is a way around
    this.

    Ok, figured it out
    ==========================
    julia> using Symbolics;
    julia> @variables x y;
    julia> y=x^2*sin(x);
    julia> expand_derivatives(Differential(x)(y))

    cos(x)*(x^2) + 2x*sin(x)
    ============================

    So
    diff(y,x)

    translates to

    expand_derivatives(Differential(x)(y))


    This forces one to type 38 instead of 9 characters. I suspect that the "expand_derivatives()" can be replaced by some general-purpose command
    like "evaluate()", however.

    Does the system distinguish upper from lower case? Would "differential"
    or "Expand_derivatives" thus fail?

    Martin.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Peter Luschny@21:1/5 to nob...@nowhere.invalid on Sat Mar 13 12:57:41 2021
    nob...@nowhere.invalid schrieb:

    This forces one to type 38 instead of 9 characters.

    With respect, your comment makes me suspect that your
    computing environment is firmly rooted in the 80/90 years
    of the last millennium.

    Julia is only used in highly developed editors that suggest
    the name you are looking for as soon as you type in the first
    or second character. So you have to type only until
    the function name is unique. And then hit 'return'.

    Usually both together count well below 9 keystrokes.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From nobody@nowhere.invalid@21:1/5 to Peter Luschny on Tue Mar 16 19:03:27 2021
    Peter Luschny schrieb:

    nob...@nowhere.invalid schrieb:

    This forces one to type 38 instead of 9 characters.

    With respect, your comment makes me suspect that your
    computing environment is firmly rooted in the 80/90 years
    of the last millennium.

    Julia is only used in highly developed editors that suggest
    the name you are looking for as soon as you type in the first
    or second character. So you have to type only until
    the function name is unique. And then hit 'return'.

    Usually both together count well below 9 keystrokes.


    So your editor may suggest "Differential" once you typed enough letters
    of "differential" (although that won't help you if both are available).
    And while typing "expand_" (or "Expand_") you may get a list including
    things like "expand_polynomials" along with "expand_derivatives".
    Alright - but I would be surprised if nobody had thought of this back
    in the 80/90s.

    Your comment thus makes me suspect that you think something more
    substantial has improved in non-commercial Computer Algebra from the
    80/90s to the 00/10s. As Sage mostly is just a wrapper bundling many
    more or less specialized and more or less aged systems, a comparison of
    SymPy and Reduce suggests itself. Nasser's digging (on July 25 of 2017
    in the thread "oh dear") into Sympy's "apart" triggering a determinant calculation implemented without regard to efficiency suggests the
    opposite of improvement - as would his integration tests on the two
    systems, I assume.

    Martin.

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