That does obscure the gridlines.

@ThU I guess that by "converted to radicals" you mean radicals without I. If so, then no, it cannot be thus converted. There are subexpressions essentially of the form

convert(sin(arctan(x)/3), exp);

The 1/3 coefficient of the arctan makes all the difference.

@ThU I guess that by "converted to radicals" you mean radicals without I. If so, then no, it cannot be thus converted. There are subexpressions essentially of the form

convert(sin(arctan(x)/3), exp);

The 1/3 coefficient of the arctan makes all the difference.

In order for "greatest common divisor" to be well defined, you need to have a concept of divisor and an ordering of the divisors so that you can determine which is greatest (the degree is used to order polynomials).

So, can you show some examples of what you would mean by divisor and explain what you would use instead of the degree?

@lettie079 

Like this:

L:= [1,2,3,1,2,3]:
[L[1..-4][], {L[-3..-1][]}];
                      [1, 2, 3, {1, 2, 3}]

@lettie079 Yes, you could use an Array instead. An Array would be especially appropriate in a situation where you want the final list to be in a certain order and you know a close upper bound on the final number of elements.

@lettie079 Yes, you could use an Array instead. An Array would be especially appropriate in a situation where you want the final list to be in a certain order and you know a close upper bound on the final number of elements.

@Christopher2222 Without the assume, it complains that it cannot determine whether X and Y are distinct points.

@Christopher2222 Without the assume, it complains that it cannot determine whether X and Y are distinct points.

@J4James Looking at any standard Numerical Analysis textbook, you will find numerous proofs of the accuracy of numerical schemes. These proofs put upper bounds on the errors. But you originally asked about residuals, not upper bounds. The residuals cannot be known unless the exact solution is known.

@J4James Looking at any standard Numerical Analysis textbook, you will find numerous proofs of the accuracy of numerical schemes. These proofs put upper bounds on the errors. But you originally asked about residuals, not upper bounds. The residuals cannot be known unless the exact solution is known.

PatrickT wrote:

rhs(g[1]);
The above works also directly with a sequence (without the []).

Except that it doesn't work when the sequence has only one element. Moral: When is doubt, use lists instead of sequences.

PatrickT wrote:

rhs(g[1]);
The above works also directly with a sequence (without the []).

Except that it doesn't work when the sequence has only one element. Moral: When is doubt, use lists instead of sequences.

While the discussion of the mathematical properties of the integrals is interesting, the main question remains: Why is _method= _Sinc using a linearly increasing amount of time (so that the overall loop time is quadratic in the loop size) for randomly chosen integrals? Yes, I definitely think that there's a bug! Even running your test twice in sucession without a restart shows the times starting where the previous loop had finished.

@samiyare I think that fsolve is slow because it is trying to get a solution that is guaranteed accurate to the full value of Digits, which is ridiculous in this situation because dsolve's solution is not as precise. (The BVP solvers have a default absolute error tolerance of 1e-6 regardless of Digits. See ?dsolve,numeric,BVP .) And fsolve does not have any way for the user to set a more lenient error tolerance. This is very often a problem with fsolve. AFAIK, fsolve is Maple's only major numeric command that does not allow the user to set error tolerances. Note that Preben's solution used a tolerance option to Student:-NumericalAnalysis:-Secant.