> Conjecture: The integration error occurs due to a similar problem, but > in a less shielded way, so we get a less intelligible error message > about essentially the same problem. > > From a maxima perspective, I don't think anymore this really is an > error. I don't think you can expect the advanced integration routines > to work in the presence of floats, because polynomial arithmetic is > necessary and things like gcds are horrible to compute for polynomials > with float coefficients. Therefore, it is written with the assumption > that keepfloat:false holds, or at least that integration does not > encounter floats. With that assumption, they are free to set > "modulus", because the codepaths that are affected by it should not be > triggered.
Nice analysis. > Proposed bugfix: symbolic integration should reject floats. Yikes! So we wouldn't want sage: integrate(1.0*x,x,0,2) 2 to work any more? (Pace the error messages below.) Could we not instead try to catch this kind of error and recommend to the user that they use rationals? Or something... > (%i3) integrate(sin(t)^2/(1*cos(t) + 1.5)^2,t,0,2*%pi); > > CRECIP: attempted inverse of zero (mod 3) > -- an error. Entering the Maxima debugger. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
