This is one sort of Maple inconsistency that interests me. Why should the first example behave like evalf(Int(...)) and call `evalf/int` while the second example does not?
> restart:
> infolevel[`evalf/int`]:=1:
> int(sin(x),x=12/10..3.4);
Control: Entering NAGInt
Control: trying d01ajc (nag_1d_quad_gen)
d01ajc: result=1.32915594705613516
1.329155947
> restart:
> stopat(`evalf/int`):
> infolevel[`evalf/int`]:=1:
> int(1.0*sin(1.0*x),x=12/10..34/10);
1.329155947
One can see the difference, that one has floats in the definite integration range, while the other has floats in the integrand. But why should that make a difference, mathematically?
acer
Comments
Numeric integration (or not)
I cannot speak for the developers, but I can see a distinction in the two cases. When there are no floats in the integrand, it could be reasonable to look for a symbolic antiderivative. Whereas, when the integrand contains floating point numbers, it can be assumed that numerical integration is what is desired.
I hope someone with more direct involvement with the design of this "feature" can confirm or refute this, and add to the discussion.
Doug
interesting
That's a interesting view, Doug. (I realize that it's a suggestion for a possible interpretation, and may not be what you yourself hold fast to.) But doesn't it describe the opposite state of affairs from what Maple does now?
I might make another suggestion on how to interpret such problems: in both cases the integrand (or antiderivative) must be evaluated at floating-point values. So numeric stability is desired. Numeric quadrature routines are often designed with that goal in mind. (Simple example: spurious nonzero imaginary artefacts seem to quite often occur when evaluating exact antiderivatives at approximate values under fixed precision, while numeric quadrature might produce strictly real evaluations.) So maybe Maple should do numeric quadrature in both situations originally posted above.
acer
Guilty, as charged
Acer,
Yes. My reasoning is exactly the opposite to what Maple does. I'm sure I could have found a way to argue for the current situation, but I do prefer what I did write.
I think there are explicit examples to support each of our positions. I do not believe one position is "right".
While I do like it when Maple makes good choices for me, I prefer it when Maple gives me the opportunity to decide what it should do. Defaults have to be chosen. But, I'd like it if Maple was more transparent about how it was evaluating (in this case) a definite integral - and if it were more convenient to modify those defaults.
Doug
evalf(Int(.. or evalf(int..
I think I follow Acer's example, but I'm not sure.
For this case:
f:=x->-cos(1/x)/x^2;
a:=1/10000;
evalf(int(f(x),x=evalf(a)..2/Pi));
I would expect Maple to use the antiderivatve sin(1/x). But instead it hauls off into quadrature, without much success. So in this case, evalf(int.. is acting like evalf(Int...
This is to be contrasted with my recollection that dsolve typically converts all of the floating point coefficients and initial conditions in a diffeq to rationals before attempting to solve:
dsolve({diff(g(x),x)=f(x),g(evalf(a))=0});
returns sin(1/x)-sin(1000) instead of something with floats.
not quite
example