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 Rubi
I am using V 12.1 of Mathematica on windows 10. Rubi 4.16.1
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
Log[r+s*x]/(s*t); whereas Mathematica returns
$RubiVersionreturns the string
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.
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[Rubi`Private`lst$55217=Rubi`Private`FractionalPowerOfLinear[#1,Rubi`Private`lst$55217[],Rubi`Private`lst$55217[],x]],Throw[False]]&)[1/10].
But if I uncomment
c=2 then it works OK. No problem then.
RationalFunctionExpandresults in a sum a term of which is as complicated as the original integrand, thus causing the infinite recursion bug.
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.
@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).
@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.
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.
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.
@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