# What's the hardest integral Mathematica running Rubi can find?

Posted 5 years ago
9552 Views
|
|
14 Total Likes
|
 Rubi (Rule-based integrator) is an open source program written in Mathematica's powerful pattern-matching language. The recently released version 4.15 of Rubi at http://www.apmaths.uwo.ca/~arich/ requires Mathematica 7 or better to run. Among other improvements, Rubi 4.15 enhances the functionality of its integrate command as follows: Int[expn, var] returns the antiderivative (indefinite integral) of expn with respect to var. Int[expn, var, Step] displays the first step used to integrate expn with respect to var, and returns the intermediate result. Int[expn, var, Steps] displays all the steps used to integrate expn with respect to var, and returns the antiderivative. Int[expn, var, Stats], before returning the antiderivative of expn with respect to var, displays a list of statistics of the form {a, b, c, d, e} where a) is the number of steps used to integrate expn, b) is the number of distinct rules used to integrate expn, c) is the leaf count size of expn, d) is the leaf count size of the antiderivative of expn, and e) is the rule-to-size ratio of the integration (i.e. the quotient of elements b and c). The last element of the list of statistics displayed by Rubi's Int[expn, var, Stats] command is the number of distinct rules required to integrate expn divided by the size of expn. This rule-to-size ratio provides a normalized measure of the amount of mathematical knowledge Rubi uses to integrate expressions. In other words, this ratio can be used as a metric showing the difficulty of solving indefinite integration problems. For example, the hardest problem in Rubi's 70,000+ test suite is integrating (a+b ArcTanh[c/x^2])^2 which has a rule-to-size ratio of 2.5. On Rubi's website are the terms of a challenge, for which there is a substantial prize, for the user who finds the hardest problem Rubi can integrate.
 Since your package came up in several discussions so far and most notably in this highly discussed post on StackExchange, I'd like to leave some words. There are two things I appreciate in your package and your work in general You seem to be one of the few experts on integration that does his work in the open and not behind closed doors. This is especially useful because your package lets the user inspect the integration rules that were applied. I'm pretty sure that one of the most asked questions of users is "I need a list of steps that show how Mathematica solved this integration." On StackExchange, we usually don't have a satisfying answer to these questions. On several occasions, I had to literally fill pages when trying to repeat some integrations with pen and paper; always having the Abramowitz/Stegun ready when I hit a dead end. Your approach of having 70k+ test-cases that you can check is simply awesome. There is no better word to put. It is almost hilarious when you write on your website "Numerous individuals have helped make this website possible." You, who seemed to need help setting up a website uses, in my opinion, the only right approach from a software developer's perspective: Test-driven development with 70000 test cases. That just blows my mind. Only through your work, we have an extensive database of integration rules that can be used virtually in any system, although we currently have it just in Mathematica code. I'm not sure if you are aware of this project, but Cory Walker is working on an open-source CAS that uses the same language as Mathematica which is called Expreduce. So while Cory only (!) had to implement the core system of replacement rules, he can now use Rubi's set of rules for integration.I have some suggestions for Rubi to make it more accessible. After downloading, I looked at your code and these are the points jumped into my eye I could not find a license. This might seem to be no big deal, but indeed it is the bread and butter when you share your code because, for one, it tells people what they can and cannot do with your work. Secondly, if you want people to participate, a license is a must. For most of my software, I'm using the very open MIT license which leaves very much freedom to use my work even in a commercial product. You can look at choosealicense.com and just decide which one you like. After that, it is as easy as putting a Licence.txt in your package and maybe mention it on your website. At the moment, it seems not possible to use your package as a real package, which means putting it into the Applications folder and loading it with <filename<>".m..."]; Get[FileNameJoin[{NotebookDirectory[],filename<>".m"}]]; NotebookDelete[object]; Null] NotebookDirectory uses the directory of the current notebook and this fails as soon as your notebook is (a) not saved and (b) not in the directory of your package. The fix is easy when you use this undocumented function inside your Rubi.m instead: DirectoryName[SystemPrivate\$InputFileName] Because what you actually want is the directory-name where your Rubi.m lives. Another thing that looks suspicious to me is in Integration utility functions.m in line 289 InverseFunctionQ[u_] := LogQ[u] || InverseTrigQ[u] && Length[u]<=1 || InverseHyperbolicQ[u] || Head[u]===Mods || Head[u]===PolyLog I might be wrong, but I cannot find any definition of Mods inside your code and it seems you wanted to write Mod. As a last minor point, inside the same file, you are defining many little helper functions like this (* If u is a power, SumQ[u] returns True; else it returns False. *) PowerQ[u_] := Head[u]===Power Besides that the comment seems the wrong one, why not turn all these comments into a ::usage message? It is good practice to have a usage message and there is no harm even to define them for internal functions. Additionally, it lets users quickly look-up what a function does when you used them