Obviously you intended for the above to be a Reply to Joe Riel's Answer to your previous Question: 'trasfer funtion plot tmdumper". Please copy it there.

@Vic You asked:

Do you think having them as lists is a bad idea?

Yes, given that you have millions of them.

should I use Array?

No, there's a better way.

Is there away that I could get the cartesian products one at a time and work on them without them taking up huge memory space?

Yes, indeed. It's called an iterator. In Maple 2016, it is handled by package Iterator. In Maple 2015, it can be done with a minor modification of the code I have above:

L:= convert(A, listlist):
J:= combinat:-cartprod(L):
to mul(nops~(L)) do
     j:= J[nextvalue]();
     if CheckCondition(j) then
          do_whatever(j)
     end if
end do;
 

@acer 

A difference between the subs method and the unapply method is shown when g depends on f and f depends on z. Both methods are immune to changes of f, but only the unapply method is also immune to changes of z, if z has an assigned value when g is defined.

Example:

z:= 1:
f:= (x,y)-> x+y+z:
g:= subs(_dummy= eval(f), x-> _dummy(x,1)):
G:= unapply(f(x,1), x):
(g,G)(1);

     3, 3

z:= 2:
(g,G)(1);

     4, 3

@acer Yes, I'd like to see your evalr and shake, though I think that the following pretty much tells the whole story:

f:= x-> (1+1/x)^x:
for n from 10 to 15 do
     Digits:= n;
     Range:= op(evalr(f(shake(31536000.))));
     print(evalf[10](Range), 'Digits'=n)
end do:

            2.658111700 .. 2.743273694, Digits = 10
            2.717442509 .. 2.726025763, Digits = 11
            2.717442510 .. 2.718299617, Digits = 12
            2.718213894 .. 2.718299617, Digits = 13
            2.718273900 .. 2.718282473, Digits = 14
            2.718281615 .. 2.718282473, Digits = 15

@acer Yes, it's 15-16 digits; I was wrong saying that it was 17-18. Specifically 53*log[10](2) = 15.95..., the 53 being the number of bits of "significand" that are stored.

@taro Every calculus textbook that I've ever used (and there have been many) has divided the FToC into the two parts, although which is considered the first part and which the second varies from book to book. My favorite calculus textbook is Thomas'.

I wonder why someone removed the vote up that they had given me for this Answer.

@taro 

One part of the FToC, usually called the first part, says, essentially, that the derivative of the definite integral (with appropriate limits) is the original function. The other part, usually called the second part, says, essentially, that the definite integral of the derivative is the original function (evaluated between the limits of integration).

@Kitonum 

Can you confirm that your reformulation of the computation has any beneficial effect? I believe that all that's significant is that you've set Digits to 20, which I wouldn't call a "workaround" because it's the issue.

The following works for me:
B:= 1.417313842*Q^(5/6)*hypergeom([-5/2,1/2], [-3/2], .9779060952/Q^(1/3));
plot(B, Q= 1..5);

The next point is:

memory used=89.25MiB, alloc change=0 bytes, cpu time=2.18m, real time=2.18m, gc time=171.88ms
2.5    .1305720815

The point after that took even longer, and I didn't have the patience to wait for it. One weird thing about the last point computed: The garbage-collection time was substantially less than the other points, even though the overall time was substantially longer.

@vv Brilliant technique. Vote up. But I'd like to know how you chose n and nx. And why a polynomial rather than a rational function? I haven't been able to change any of those and get anywhere near your infnorm.

Your exp(xt) should be exp(x*t). That being said, there's no direct way to solve integro-differential equations in Maple. Someone may be able to come up with a ad hoc method.

@tomleslie These are ODEs, not PDEs, so Maple's dsolve can determine the value of omega by the inclusion of one more boundary condition. For this purpose, it's better to use omega in the equation in place of omega^2, and then to take the square root of the resulting value.

@taro Personally, I don't like the new toolbar. They've completely removed the use of red, which makes the icons harder to find. There are only two colors in the new toolbar: grey and blue. At the very least, the stop sign should be red!

@Henk Although evalf gives a somewhat meaningful result in your example, the more-usual way to convert Sum to sum is the value command:

Sum(2^j, j= 0..9):  % = value(%);

This uses exact computation rather than numeric approximation.