Julia is the future of RUBI !

[Peter Luschny]

... and some other things. Exciting news.

https://juliasymbolics.org/roadmap/

[nob...@nowhere.invalid]

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.

[Nasser M. Abbasi]

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

[Axel Kramer]

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.

[nob...@nowhere.invalid]

"Nasser M. Abbasi" schrieb:

>
> On 3/3/2021 11:13 AM, clicl...@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.

[Peter Luschny]

> 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?

[Nasser M. Abbasi]

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

[nob...@nowhere.invalid]

Axel Kramer schrieb:

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.

[Axel Kramer]

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

[Richard Fateman]

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

[nob...@nowhere.invalid]

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.

[Nasser M. Abbasi]

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

[nob...@nowhere.invalid]

"Nasser M. Abbasi" schrieb:

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.

[Nasser M. Abbasi]

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

[Peter Luschny]

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.

[nob...@nowhere.invalid]

Peter Luschny schrieb:

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.