## Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
##### People
• • • • • • • • • • • • • • • • • • • • • • • • • ##### Activity edmontz
@edmontz
Maybe the version of maxima I'm using.I've found it necessary to replace the likes of atan(b,c) with atan(c/b) in the rubi rules for maxima. That has made the lst[] loadable; whereas the previous 1/(1+sin(x)^6) example produces a divide by zero error when I attempt to load it.There is an integral for that available in maxima, however the likes of 1/(1+sin(x)^8) don't have an integral in maxima.Symja now produces a result, that's almost correct; the (-1)^(1/3) +1 has now been changed so as not to produce the divide by zero error. Hello; Why sometimes Rubi shows "removeContent" from Steps command on some integrals? For example, from clean kernel

     << Rubi
Steps[Int[Sin[2*x]/(a^2 - b^2*Sin[x]^2), x]]

Gives the above screen shot. This does not show all the time, I just noticed it on this one. May be it is normal for this to show up sometimes. I just wanted to check.

btw, how does one find the version number of Rubi they are using? Is there something like RubiVersionNumber[] command?

I am using V 12.1 of Mathematica on windows 10. Rubi 4.16.1 Albert D. Rich
@AlbertRich
@nasser1 Hi Nasser. Rubi wraps RemoveContentaround the arguments of logs occurring at the top-level of antiderivatives to remove unnecessary factors independent of the integration variable. For example, for the integrand 1/(r*t+s*t*x) Rubi returns Log[r+s*x]/(s*t); whereas Mathematica returns Log[r*t+s*t*x]/(s*t).
$RubiVersion returns the string "Rubi 4.16.1.0". Albert D. Rich @AlbertRich @edmontz I just responded on sci.math.symbolic to your post requesting how to verify correct optimal antiderivatives in the test-suite. Like I imply there, the antiderivative of 1/(1+sin(x)^6) has been verified correct by Mathematica. I don't know why Maxima can't also verify this elementary antiderivative correct. Nasser M. Abbasi @nasser1 fyi, I do not think I saw this before, but on V 12.1.1 this seems to make it take long time then gives error messages. I thought may be worth looking into why <<Rubi ClearAll[c, a, b, x, f1, f2]; f1 = (x^(-c))*(c*x^(c - 1) + b)/(x^c + b*x); f2 = (1 + (Log[x^c + b*x])^2)^(-(a + 1)/2); expr = f1*f2; expr = Simplify[expr] a = 1; b = 1/10;(*c=2;*) Int[expr, x] gives after about few minutes time $RecursionLimit::reclim2: Recursion depth of 1024 exceeded during evaluation of (If[AtomQ[RubiPrivatelst$55217=RubiPrivateFractionalPowerOfLinear[#1,RubiPrivatelst$55217[],RubiPrivatelst\$55217[],x]],Throw[False]]&)[1/10].

But if I uncomment c=2 then it works OK. No problem then. Albert D. Rich
@AlbertRich
@nasser1 Thanks for pointing out this infinite recursion bug.
You can investigate such bugs by single stepping through the problem. That's how I found the much simpler example that forces the same bug:
Int[1/((1 + x^2)*(1 + x^(1 - c))), x]
Single stepping shows that the utility function RationalFunctionExpand results in a sum a term of which is as complicated as the original integrand, thus causing the infinite recursion bug.
It's hard to distinguish such bad expansions from the good ones so they can be filtered out, but I'll work on it. Patrick Scheibe
@halirutan
@AlbertRich We're cited:
Rewriting using a database is perhaps most likely to be successful for specific tasks and in combination with advanced hand-written search heuristics (or heuristics generated via machine learning). A prominent example of the hand-written approach is Rubi  which uses a decision tree of thousands of rewrite rules to simplify indefinite integrals. Albert D. Rich
@AlbertRich
@halirutan Great! But I take issue with the implication that Rubi uses "search heuristics". Per Wikipedia:
A heuristic technique, or a heuristic, is any approach to problem solving or self-discovery that employs a practical method that is not guaranteed to be optimal, perfect, or rational, ...
The FunGrim article goes on to say correctly that Rubi uses a decision tree to select the appropriate rule. Rubi's decision tree is deterministic and does not use heuristics or back-tracking (ug). Patrick Scheibe
@halirutan
@AlbertRich Yes, I saw that and I knew you would criticise this :)

@AlbertRich I don't like this paragraph:

FunGrim uses a similar approach to that of WFS, but does not depend on the proprietary Wolfram technology. Indeed, one of the central reasons for starting FunGrim is that both DLMF and WFS are not open source (though freely accessible).

I acknowledge that Wolfram stuff is proprietary, but the language spec and all docs are freely available. And nowadays you can get even a Kernel for free. Wolfram has one of the most powerful symbolic engines and each function is documented... but no, let's use Python. 1 reply Patrick Scheibe
@halirutan
I don't say it's not a valid argument, but it simply sounds like the things you have to say in a paper. Instead, they could have written, "we use Python because we like it and have worked on SymPy, although we acknowledge that Python is vastly inferior compared to other prominent symbolic engines" :) Nasser M. Abbasi
@nasser1
"Python is vastly inferior compared to other prominent symbolic engines" :)" I assume you mean "sympy" there, which ofcourse is written in Python. I agree. I tried sympy and do not like it for symbolic. Whenever one adds symbolic layer on top of a language not designed from scratch for symbolic processing, it is always awkward. This is the same for Matlab's symbolic toolbox. Patrick Scheibe
@halirutan
@nasser1 Yes, only for symbolics. Python has definitely its place in other areas. Ax Kr
@axkr
@halirutan I think the discussion about which programming language to choose is not fruitful. IMO it often depends on the application case. For example for "the special case of small devices", Java (or Java derived languages) are better supporting the developing process of a core engine. Some users for example have created small devices app for Android with Rubi rules inside: https://play.google.com/store/apps/details?id=com.duy.calculator.free and with the help of the J2ObjC https://github.com/google/j2objc converted the core engine to iOS https://apps.apple.com/us/app/ncalc-scientific-calculator/id1449106995 Ax Kr
@axkr
In general "statically-typed languages" have advantages in these development cases IMO. Ben Mares
@bmares_gitlab
Hey all, this is a really impressive project! Is there any hope for future versions of Rubi to be able to solve more general differential equations? (In the sense of Mathematica's DSolve?) Nasser M. Abbasi
@nasser1
@bmares_gitlab Mathematica's DSolve? May be you meant Mathematica's Integrate? Rubi does integration, not solving odes. Ben Mares
@bmares_gitlab
Hi @nasser1, yes I do mean DSolve. By the fundamental theorem of calculus, integration is equivalent to solving a differential equation (namely the antiderivative equation). I was wondering if anyone has considered if/how the techniques of Rubi could be adapted to the context of solving differential equations more general than the antiderivative equation. Albert D. Rich
@AlbertRich
@bmares_gitlab Yes, as I've argued in my essay Organizing Math as a Rule-based Decision Tree, Rubi is proof-of-concept that "the techniques of Rubi could (and should) be adapted" to automate large swaths of mathematics.
This not only includes solving differential and regular equations, but the surprisingly much more difficult task of simplifying arbitrary expressions. My hope is mathematicians will take up the challenge in their area of expertise... Nasser M. Abbasi
@nasser1

@bmares_gitlab Integration is needed for one and very limited class of ode's, those of type quadrature. If solving ODE's was just integration, then there will be no need for the whole research that goes into solving ode's.

Integration can be needed as one step in the overall process of solving some ode's (and it is not always needed).

But it is only one step and for some specific types of odes. My point is that you can't make general purpose ODE solver if all what you have is an integrator. That will only be able to solve very limited ode's. There are many many more components needed. Patrick Scheibe
@halirutan Patrick Scheibe
@halirutan
@AlbertRich And here is another preprint citing Rubi: https://inspirehep.net/literature/1816700 Albert D. Rich
@AlbertRich
@halirutan Citation  in the preprint Revisiting the top quark chromomagnetic dipole moment in the SM at arXiv.org. Patrick Scheibe
@halirutan
@AlbertRich It's a bit frightening that Rubi is cited in something where I don't understand a single word. Albert D. Rich
@AlbertRich
@halirutan Rubi is just a tool others use to build complex structures. One doesn't have to know how to build the Golden Gate Bridge in order to make a hammer. Nasser M. Abbasi
@nasser1

I wonder if any thought was given to porting Rubi to Maple? Since Maple has a package that translates Mathematica expressions to Maple expressions? https://www.maplesoft.com/support/help/Maple/view.aspx?path=MmaTranslator/FromMma

But it will not be able to translates something if there is no equivalent in Maple, so the pattern matching commands could be the tough ones to translates. Other commands will not be such a problem. Here is an example. It can translate command it known, but not one with MatchQ and pattern
Since there is no MatchQ in Maple, it keeps it as is and the resulting Maple expression will not run in Maple. But will translate others like Table and loops, etc... to Maple commands since it knows these. Albert D. Rich
@AlbertRich
@nasser1 Rubi 4.n requires efficient pattern matching to select which of Rubi's 7000+ rules to apply to a given integrand.
Maple's pattern matching ability is only rudimentary at best. Therefore, porting Rubi 4.n to Maple is not feasible.
However Rubi 5 will use an if-then-else decision tree to select the appropriate integration rule. This is more than an order-of-magnitude more efficient than pattern matching, and only requires the host CAS support a nested if-then-else control construct. This will make it relatively easy to port Rubi 5 to Maple and other math systems. This looks really interesting. Is there any possibility for a Julia version or wrapper? This could be a very naive question Albert D. Rich
@AlbertRich
@AshtonSBradley All I know about Julia is the Wikipedia article on the programming language. Obviously to do symbolic integration using Rubi 5, it has to support symbolic mathematics. Nasser M. Abbasi
@nasser1

Julia can access sympy using SymPy.jl. Rubi 4.* has been ported to sympy but the port is not fully working. I have not tried it on sympy 1.6.2 yet, but as of sympy 1.5, rubi port to sympy had problems.

So in theory, if rubi 5.0 is ported to sympy/python, you can access it from Julia using the SymPy.jl interface. is rubi 5.0 being actively ported to sympy?
is there a good way to check SymPy.jl rubi? Is it used for all integrals, or is there a way to enable it? Nasser M. Abbasi
@nasser1

@AshtonSBradley I do not use Julia much. Just played with it a little. But if you can install and use the SymPy.jl interface to access sympy (you can check documentation on this) then you can use Rubi in sympy as follows

>python
Python 3.7.3 (default, Mar 27 2019, 22:11:17)
[GCC 7.3.0] :: Anaconda, Inc. on linux
>>> from sympy import *
>>> x = symbols('x')
>>> from sympy.integrals.rubi.rubimain import rubi_integrate
>>> rubi_integrate(x, x)
Integral(0, x)
>>>

But as you can see, it does not work. As far as I know, there is no one currently maintaining Rubi port in sympy but you can ask the sympy folks in sympy forum or here sympy/sympy#12233

The above uses Rubi 4.* port ofcourse done about 1-2 years ago. The first call to integrate takes long time (may be 10 minutes, this is because it loads all the rules first time. Then it will faster next time. But this is a moot point now, since the call to rubi_integrate does not work.

You'd have to find how to call sympy from Julia first to do the above from inside Julia using that interface Albert D. Rich
@AlbertRich
Is Rubi 5.0 being actively ported to sympy?  