@halirutan At the risk of asking for way too much :smile:, even better would be drop-down menus that appear when you hover over "Algebraic", "Exponential", etc that lead directly to the pdf files in the repository.
Such nested drop-down-menus are realy old-school and not used anymore nowadays. But more importantly, all we do at the moment is a compromise between two things: (1) Having a clear design and all information in one place (that is used by almost all today's developers) and (2) simplicity so that you can easily grasp how to change and edit things without learning too much useless web-dev stuff. Such a nested drop-down is certainly possible, but it would mean that I have to re-create the web-site on each change. I would very much not go this way :)
The current menu is a bit of a hack and I'm using buttons that are originally not meant to be a menu, but it looked great when I tested it and therefore I used it. So for the website, I would like to keep this simple "one level" menu where each entry either leads directly to a repository or it has exactly one page behind it. Therefore, this
@halirutan I would like to encourage the development of definite integration rules in addition to indefinite integration rules. To that end, should we add two subsections under IntegrationRules named DefiniteIntegrationRules and IndefiniteIntegrationRules?
is absolutely fine when it stays on one page. I'm not sure I completely understood this though. The current state is that Rubi only has indefinite integration rules, right?
@AlbertRich In addition to the Mathematica package update, I added the following things to the web-page:
The "Home" page needs a bit more content, but I would like to announce everything this week, as I'm on vacation a week later.
major.minor[.maintenance[.build]]
. I didn't want to complicate things as deeply nested version numbers might be confusion, so I increased the minor version with each new package that contained changes.
4.15.2:1.0
will blow the users mind and they won't understand it. Would 4.15.2.xx
be acceptable so that I can increase xx
to my liking and 4.15.2
points to the engine version?
4.15.2.1
and the reason for that is simple: I do not know if Mathematica can interpret more exotic version numbers correctly in their Paclet and we need to ensure that PacletUpdate
understands which version is the newest.
@Nasser @halirutan Patrick wrote:
What I would like to see in the Wiki is a page that explains, how we can possibly verify the results of Rubi, Mathematica, ...
I use two different methods to test the validity of a candidate antiderivative produced by the various systems, including Rubi:
Depending on the size of the candidate, one of these methods may take an inordinate amount of time to decide while the other would quickly succeed. Also, sometimes the first method will succeed only if you Simplify or FullSimplify the candidate before differentiation; sometimes it will succeed only if you do not Simplify or FullSimplify the candidate before differentiation.
Also sometimes the first method will succeed only if you Simplify or FullSimplify the result of the differentiation before subtracting the integrand; sometimes it will succeed only if you do not to Simplify or FullSimplify until after subtracting the integrand.
Similarly, the second method succeeding sometimes depends on when the candidate and intermediate results are simplified. So the test program should use time slicing, or better parallel processing, to try the numerous permutations of these two verification methods. As you can see good antiderivative verification is a difficult research project...
Of course, if you don't trust me, the validity of the optimal antiderivatives in the test suite should be verified correct by the first method above. That verification should be easy, since the optimal antiderivatives are relatively small. However, I had to manually help out Mathematica on verifying some optimal antiderivatives that involved nested radicals and/or fifth roots.
Finally note that these methods assume the CAS conducting the verification tests correctly differentiates, subtracts and simplifies expressions.
Simplify
that is able to transform the expression into the right form. Am i mistaken here when I say that the correct way for e.g. Maple would be to integrate the expression, but import the result back to Mathematica to make the advanced comparision?
@halirutan @Nasser Your remarks above suggest the WIki page on testing needs to clearly distinguish between
To receive a grade of A, a candidate does not have to equal, or be of the same form, as the optimal antiderivative. Rather it just has to be no more than twice the leafcount size of the optimal, and not involve higher level functions than the optimal. The function levels are ordered as elementary < special < hypergeometric.
For details on grading see Nasser's website. With his permission, perhaps some of the documentation there could be incorporated into the Wiki page on testing, along with my discussion above on verification methods.
@halirutan I think your question
Am I mistaken here when I say that the correct way for e.g. Maple would be to integrate the expression, but import the result back to Mathematica to make the advanced comparison?
refers to validity testing rather than quality grading. Assuming so, it could be argued that validity testing should include the ability of a CAS to differentiate its own antiderivatives back to the integrand.
Also there is a Tower of Babel problem since Maple and Mathematica define some functions (e.g. the elliptic integral functions) differently. So differentiating a Maple antiderivative in Mathematica would not equal the integrand; however differentiating the Maple antiderivative in Maple would equal the integrand.
@nasser1 You wrote
How could candidate and optimal difference not be free of integration variable, yet difference differentiates to zero? ... Could you please give an example of the above case? Thanks
Here's an example: For the optimal antiderivative of 1/(1+x^2) the test suite gives ArcTan[x]. However, some CAS might give - ArcCot[x] which is also a perfectly valid antiderivative, as differentiation shows. The difference of these two antiderivatives is ArcTan[x]+ArcCot[x] which is not free of x; however, it differentiates to 0. As plotting ArcTan[x]+ArcCot[x] shows, it is not a constant; however, it is a piecewise constant; so its derivative equals 0 and therefore -ArcCot[x] is a valid antiderivative of 1/(1+x^2).
@halirutan You wrote on June 24th:
The "Home" page needs a bit more content, but I would like to announce everything this week, as I'm on vacation a week later.
Simultaneously with your announcement, I would like to announce the availability of Rubi on GitHub on sci.math.symbolic, email several power users of Rubi about it, and provide a link to the GitHub site on Rubi's current homepage. Therefore, please let me know before you announce, and what user groups you plan to send it to. Also, I would appreciate your sending me a copy of the text so we can coordinate our descriptions of GitHub Rubi, including its proper name.