Richard Fateman schrieb: > > I'm not sure what the relevance is of DERIVE's performance, since the > program is neither supported nor distributed at this time, but the > syntax looked almost identical to Macsyma (commercial, not supported > or distributed) so I tried to run it through Macsyma 2.4.0
Yes, this must be largely to my own satisfaction, although there should be other Derive users around still (the situation for Macsyma may be similar). Judging from the activity on their website, Reduce also seems to have very few users even though it is officially supported. For the community of Sympy users and developers, however, results from this test suite should be of considerable interest (is anybody there listening?). After all, a serious bug in FriCAS has already been uncovered and repaired (for versions > 1.2.0) in this way.
> > [...] > > 1. I found expressions in the test suite of the form > > integrate(A,x) = B = C > > which do not parse properly since B=C makes sense in Macsyma > if B and C are algebraic. It does not make sense in Macsyma > to ask (A=B) = C since A=B is logical not algebraic. > > That is almost beside the point though. What is the test suite > supposed to be used for? Testing the simplification of B=C? > Is either answer, B or C supposed to be OK for the integration? > Is one supposed to verify the answer by differentiating B?
Derive simplifies A = B = C to A = B AND B = C (as does Mathematica, I believe). So this notation is adequate if equality is assumed to hold only up to (piecewise) constants - in other words, to hold only after differentiation. Unfortunately, in Derive, an expression A = B = C cannot be differentiated (it is not simplified beyond DIF(A = B AND B = C, x)), although I see no reason why this should be forbidden (what about Mathematica?).
> > [...] > > Running through the examples, Macsyma paused in a number of places > to ask (for example) is a*b pos or neg; is a nonzero; is x >0, is > n+1 nonzero.. > > So I added assumptions such as assume(a>0, b>0, x>0 n>0) and ran the > test again. > > The test went through without any burps that I noticed except for > > integrate(asin(x/a)^(3/2)/sqrt(a^2-x^2),x) > which was not integrated. This appears to be the same as the first > clumsily restated expression in the original posting.
I suppose you are referring here to my entries for Timofeev's examples 47 and 64 (as taken from my current file):
I agree that much of this looks ugly compared to Timofeev's evaluations, but such clumsiness often cannot be avoided if an evaluation is to pass when the integration variable (as well as any parameters) are allowed to be complex (assuming a framework of strictly single-valued complex functions as implemented in Maple, Derive, and Mathematica, for instance). Integrals in the suite have been handled as follows:
The integrands are without modification from Timofeev's book, apart from occasional integrals whose accompanying evaluation implies a minor misprint in the integrand, which are corrected. His evaluations, on the other hand, are (barring oversights of mine) always modified to make them hold on the complex domain where the original ones do not. They are also modified if simpler forms could be found, or if the original ones were seen to exhibit artificial discontinuities. In fact, I am trying to establish that all antiderivatives in the book can be written such that no unexpected discontinuities appear on the real axis (assuming real parameters), while also remaining simple and "natural"-looking. In this, I think, I have been successful so far. Where I saw no clear reason to prefer one evaluation variant over another, both forms are given.
> [...] > > The test suite as used > > integrate(1/(a^2-b^2*x^2),x); > integrate(1/(a^2+b^2*x^2),x); > [...]
The integral you lost was not hard to hunt down: After your line 14, which reads integrate(sin(2*x)/(b^2*sin(x)^2+a^2),x), insert integrate(sin(2*x)/(b^2*sin(x)^2-a^2),x). Your suite will then have 86 lines, or 86 integrals.