Okay, that answers the question as posed. It seems that no environment variable can be used as a parameter. There is another symbol that I had in mind, not an environment variable, that cannot be used as a parameter. If you try to use it, then you will not get an error on the procedure definition; but the procedure will not work correctly.

Okay, that answers the question as posed. It seems that no environment variable can be used as a parameter. There is another symbol that I had in mind, not an environment variable, that cannot be used as a parameter. If you try to use it, then you will not get an error on the procedure definition; but the procedure will not work correctly.

@erik10 I compiled, and I got nearly identical results to you: The compiled versions are about 3 times slower than the non-compiled evalhf versions.

@erik10 I compiled, and I got nearly identical results to you: The compiled versions are about 3 times slower than the non-compiled evalhf versions.

@Markiyan Hirnyk I didn't claim that interpolant wouldn't work for BVPs. It doesn't work for IVPs, which is what the Asker has. There is apparently an equivalent option for IVPs called interpolate, which seems to have been deactivated.

@emma hassan Your f contains a constant term c[1,0]. This term disappears when you take the derivative. Thus, it does not appear in any of the equations E[r]. Thus, fsolve does not provide any value for it. So, when you try to use u, it still has an unevaluated c[1,0] in it.

@emma hassan Your f contains a constant term c[1,0]. This term disappears when you take the derivative. Thus, it does not appear in any of the equations E[r]. Thus, fsolve does not provide any value for it. So, when you try to use u, it still has an unevaluated c[1,0] in it.

It seems that interpolant only applies to BVPs, whereas the quote about an option "interpolation" is on a help page for rkf45, an IVP method. There also seems to be an undocumented (as far as I can tell) and inactive (as far as I can tell) option interpolate. Here's my attempts to use the options.

restart:
dsolve({diff(y(x),x)=y(x), y(0)=1}, {y(x)}, numeric, method= rkf45, interpolant= false);
Error, (in dsolve/numeric/an_args/SC) keyword was 'interpolant', optional keyword must be one of 'abserr', 'differential', 'event_doublecross', 'event_initial', 'event_iterate', 'event_maxiter', 'event_pre', 'event_project', 'event_relrange', 'event_stepreduction', 'events', 'implicit', 'initstep', 'interpolate', 'interr', 'maxfun', 'maxstep', 'minstep', 'optimize', 'output', 'projection', 'range', 'relerr', 'startinit', 'steppast'

dsolve({diff(y(x),x)=y(x), y(0)=1}, {y(x)}, numeric, method= rkf45, interpolate= false);
Warning, the 'interpolate' option has been removed, ignored...
proc(x_rkf45)  ...  end;

Could you say precisely on which help page you saw this advice? Look at the title bar of help window. It should say something like "Maple 16 Help - [dsolve,numeric_bvp,advanced]".

Could you be more precise about what you mean by "huge matrix DE"?

That does obscure the gridlines.

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}]