| 1 | initial version |
This is basically the same issue as the recent one with "D", which denotesfricas' derivative operator : "e" has special meaning for giac's parser.
Workaround :
sage: var('C B A variable_e d x')
(C, B, A, variable_e, d, x)
sage: Ex=SR("(C*x^2+B*x+A)*(-e^2*x^2+d^2)^(1/2)/(e*x+d)".replace("e","variable_e"))
sage: SR(repr(Ex.integral(x, algorithm="giac")).replace("variable_e","e"))
1/2*(C*d^3 - B*d^2*e + 2*A*d*e^2)*arcsin(x*e/d)*e^(-3)*sgn(d) + 1/6*sqrt(-x^2*e^2 + d^2)*((2*C*x*e^(-1) - 3*(C*d*e^3 - B*e^4)*e^(-5))*x + 2*(2*C*d^2*e^2 - 3*B*d*e^3 + 3*A*e^4)*e^(-5))
Such a sanitization, which can account for various parsesrs' quirks, can be applied by program to all your test database.
As far as I remember, Rubi's test database comes expressed in "Wolfram language" (a. k. a. Mathematica). This implies that this language's lexical and syntactic rules should be used to interpret both integrand and "reference functions". This can be problematic, since Mathematica implements many functions not directly known by other CASes : e. g. Hypergeometric0F1, Hypergeometric1F1 and Hypergeometric2F1 are all special cases of HypergeometricPFQ, whose translation to Sage is hypergeometric. See Trac#31902 for further input...
Copyright Sage, 2010. Some rights reserved under creative commons license. Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.