@Markiyan Hirnyk The resolution (or granularity) of the Maple clock is so large that CPU times less than about 0.05 sec can't accurately be measured directly. That resolution is system dependent, but on every system that I've ever used (mostly Windows), it's been exactly 1/64 = 0.015625 seconds. To measure small times more accurately, use the iterations option to CodeTools:-Usage. This will execute the code multiple times and report the average time.

You can verify what I say about the resolution by measuring a variety of small times with kernelopts(cputime). For example, you can execute the following:

st:= kernelopts(cputime):
for k do t:= kernelopts(cputime); if t > st then break end if end do:
t-st, k;

     0.015625, 9731

That means that for the first 9730 iterations of the loop, the measured time was exactly zero. You can repeat this code any number of times. The number of iterations will vary wildly, but the first number---the first nonzero time measured---will be constant.

@yader 

Yes, I said that it wouldn't work with nested floats. Here's an improvement using frontend (which prevents it from seeing anything inside a function call, such as sin) that will work:

Cancel10s:= proc(E::algebraic)
local T,P,N,D;
     T:= And(float,Not(identical(0.)));
     if not frontend(hastype, [E], [{`+`,`*`}, {}], T) then return E end if;
     P:= 10^ilog10~(frontend(indets, [E], [{`+`, `*`}, {}], T)[1]);
     N:= numer(E)/P;
     D:= denom(E)/P;
     N/D
end proc:

I can't explain the error that you got earlier except to say that the big "1/" in your prettyprinted output is suspicious.

@yader 

I used Maple 18. I wonder if there has been an unintentional fundamental syntax change in Maple 2015. It'd be a very bad thing if so. The big "1/" in the prettyprinted version of the procedure in your Reply is very suspciious. Or, I wonder if it's a 1-D / 2-D difference. Try the following bloated version of the procedure:

Cancel10s:= proc(E::algebraic)
local T,P,N,D;
     T:= And(float,Not(identical(0.)));
     if not hastype(E, T) then return E end if;
     P:= 10^ilog10~(indets(E, T))[1];
     N:= numer(E)/P;
     D:= denom(E)/P;
     N/D
end proc:

@Al86 The u example that I used satisfies that PDE, so the identity still doesn't hold.

@Kitonum It means the same thing as does NaN (Not a Number) in the IEEE 754 standard for (double-precision) floating-point arithmetic that Maple uses. See the Wikipedia page on NaN. In this case, I suspect that it comes from computing the difference of two very large positive numbers whose difference is very small. If you increase Digits to 15, the problem will go away.

@ 

Changing int to Int should substantially reduce the computation time. I don't have time to test it right now. As it is, it is attempting a symbolic integration every time YFD is called with numeric input.

@Markiyan Hirnyk Replace your map with map[inplace, evalhf] and you should get about a factor-of-10 time reduction.

@tomleslie 

• Yes, I meant assign (original Answer corrected).
• Yes, AFAIK, all of Maple's solving commands treat algebraic expressions as equations equated to 0.
  
• The process you describe is esentially equivalent to using eliminate, where one can clearly see that the reduced equations (the second returned set) are inconsistent.

@Bendesarts The embedded semicolons make this problem more difficult than something that can be handled with some simple StringTools commands. Maple does have it's own Matlab-to-Maple translator: Matlab:-FromMFile (see ?Matlab,FromMFile). It does have some limitations on the complexity of the Matlab code that it can handle, but I think that it can handle what you've presented above. 

I believe that the embedded prompt (>) symbols on copy-and-paste are due to a bug in Maple 2015 that's already been corrected in Maple 2015.1. I'm not sure about that. Hopefully someone else here will comment on that. It that's not the problem, I can come up with a StringTools solution for that problem.

@erik10 Adding an icosahedrom wireframe is much easier than your Reply suggests. Starting with Kitonum's PlotFootball, do

FB:= PlotFootball([red,yellow]);
plots:-display(
     FB,
     geom3d:-draw(geom3d:-icosahedron(Icosa, C, 1.2), style= wireframe, thickness= 4)
);

@tomleslie There is a worksheet link at the bottom of the Question, and it's been there since the Question was first posted.

@Markiyan Hirnyk Even plots is not needed for this.

restart:
with(geom3d):
draw(TruncatedIcosahedron(football, point(C,(0,0,0)), 1));

@acer Can I take your lack of mention of my reformulation of the Question to mean that, as far as you know, it isn't possible to use external files with Maple Player?

@tomleslie Oh, I forgot to say that I applied simplify to the integrand. Sorry about that. I updated my Reply. So, using your formulation,

int(simplify(expr), z= 0..infinity);

@tomleslie Thank you for your response to my Question. Yes, &under is obscure and difficult to look up in the help. It's documented at ?type,structured in the last paragraph of Description and the last four Examples. Its action is completely controlled by the easy-to-understand one-line procedure `type/&under`. Your guess as to its meaning was spot on. Unfortunately, your proposed workaround doesn't help me because I need the expressions as they are before they are converted.

I think that &under is only tangentially related to the cause of the problem. I say that because if I execute trace(`type/&under`) before making the erroneous indets call, I see that the procedure is never called for the missing derivative. Preben's and Acer's analyses make me think that the error is more closely related to the convert.