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.0will blow the users mind and they won't understand it. Would
4.15.2.xxbe acceptable so that I can increase
xxto my liking and
4.15.2points to the engine version?
126.96.36.199and 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
PacletUpdateunderstands 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.
Simplifythat 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.