Yes, in MapleV R5 (released in the year 1998) the command 0^0 produces "Error, 0^0 is undefined".

But in Maple 6 (released in the year 2000) and later versions, it produces 1.  And 0.0 raised to 0.0 produces Float(undefined). There is a practical balance between throwing an error and raising an exception (or setting an exception flag), and that is meant to reflect the need to allow numeric programming to be done while preventing or flagging invalid operations.

See vv's Answer for a link to more explanation.

@Adam Ledger The global name :-phi is unassigned and using it in a function call returns unevaluated. It doesn't compute anything.

It is a bug in Maple 16 that accessing an Equation Label that contains the unassigned global name :-phi will insert something with the rebound name. In your example (where you did with(numtheory) and so rebound the name), it is a bug that the global name :-phi gets inserted from the Equation Label as numtheory:-phi.

So you original only "worked" when using the Equation Label due to that bug. Maple 2018.0 doesn't have that bug, as far as I see.

Note that in your example the Math Container contained calls to just the unadorned name phi. When you extract the expression from that component the result contains just global :-phi even if you have loaded numtheory.  (It is moot whether that's the best behavior.)

Given that behavior of Math Conponents, these two workarounds are possible.
1) Substitute :-phi=numtheory:-phi into the expression extracted by GetProperty (as I showed).
2) Put numtheory:-phi explicitly into the Math Container (which you may find less visually attractive).

You may notice that there was no need for calls to simplify. Even in your original "working" instance, via the Equation Label, the simplify did nothing. Evaluate the Equation Label alone, as input, and you'll see the list of zeroes directly (because it picks up the rebound phi).

If you set up FTest to use an expression containing numtheory:-phi instead of :-phi then the calls to that will immediately resolve for posint arguments.

What platform are you using?

Is it 32-bit Maple on MS-Windows?

@abhilashun It wasn't clear (to me) that you wanted the inner portion, sorry.

It can be obtained, with the same kind of approach, using F1[3] and F1[4]. I'll try to find time for it later in the day.

The outer shell was made as an intersection. Would you want the inner shell as a union?

@JBrew13 

That's interesting because when I execute your Document (either block by block, or with the menbar's `!!!`) it works OK.

I wonder how you were attempting to execute that convert input. Was it just mouse focus, and hitting Enter? Or by selecting part or all of it? Execution from the entry in the right context-panel, or via Edit->Execute from the menubar, or keyboard acceleration like Ctl-=?

Is this Windows (32 or 64bit), OSX, or Linux?

Could you upload a worksheet/document that contains the problem? (big green up arrow in mapleprimes editor).

@Kitonum I deliberately did it the way I did, despite knowing several direct one-liners for it.

I made that choice partly because the OP on stackexchange wrote he already knew the result, but just needed to be able to enter it in Maple.

I'll note that I also wrote several sub-steps separately, deliberately repeating operations.

I was trying to illustrate the `@@` syntax (for the functional inverse), and demonstrate that Maple's `diff` command understands it, more than explain how to obtain the answer directly.

Apart from Kitonum's fine answer below, you could also see previous answers here. 

See my answer here.

@Muhammad Usman You may want to check the signs (plus, minus) in the T[w]-T[infinity] and -C[w]+C[infinity] , since your DE6 had them with both the same sign. I'm guessing that you intended a subtraction, so I changed in in DE6 below. 

Download Help_2_ac.mw

@mehran rajabi So you are back-substituting the approximate root into the original expression, to see whether the result is small. Sometimes that computed value is called the residual, or the forward error.

The plot of the expression is very steep near the larger roots. That means that any small change in the root approximation will result in a large change in the computed residual (even if the back-substitution itself is performed a very high precision).

Truncation of the approximate root (ie, rounding it to d digits) incurs such a change away from the true root. So the residual computed using only say d digits of the approximate root may be significantly larger than the residual computed using more than d digits of approximation of the root.

In the following attachment I generate approximations of the root near 22.3, with successively more digits in the approximated result. Each of these is back-substituted into the original expression, and the residual computed. It demonstrates how a more accurate approximation of that root is needed in order to get a smaller residual.

resid.mw

I notice that the curve in your image is not straight, between the first and second data points.

Are you asking about curve-fitting (ie, regression or interpolation, etc)?

Afaik an animation can only show a single `background` image, taken as the last available from all the frames.

But it should be possible to produce a heatmap in an alternative format.

For example the images could be float[8] images ie. float[8] Arrays which could be used to shade density plot GRID structures instead. Those can be more memory intensive, however.

A modest number of shaded polygons would also likely serve, if you don't need a very fine granularity, and be cheaper still.

@Adam Ledger Just because unapply sometimes provides the convenient way to construct a procedure from an expression doesn't mean that it's always the right thing to use. It's not the right thing to use with the code snippet I gave in my answer.

The best way to turn my answer into a re-usable procedure is to simply wrap it in proc()...end proc. I'll do so below. I'll change some of the names in the proceduce (params or locals) so that they are not confusingly the same as their equivalents at the higher level.

I originally used _seq with an underscore as a cheap way to use a name to which one would likely not have assigned a value. In the procedure version below I'll use s.  Kitonum used S in the procedure version he posted after me. The similarity is because we were both just working around the issue by using a dummy name for the foldl call.

restart;

Gen:=proc(f, r::list(posint))
  local n,i,j,p,s;
  n:=nops(r);
  op(eval(subs(s=seq,
               [foldl(s, f(seq('i'[j],j=1..n)),
                      seq(i[p]=1..r[p],p=1..n))])));
end proc:

Gen(F, [2,1,3]);

  F(1, 1, 1), F(2, 1, 1), F(1, 1, 2), F(2, 1, 2), F(1, 1, 3),
  F(2, 1, 3)

Gen(F, [7,2]);

  F(1, 1), F(2, 1), F(3, 1), F(4, 1), F(5, 1), F(6, 1), F(7, 1), F(1, 2),
  F(2, 2), F(3, 2), F(4, 2), F(5, 2), F(6, 2), F(7, 2)

Your original question was about how to use foldl and seq to generate all the possible F calls. There are, of course, other ways to generate those F calls, and some of the other ways are reasonably simple. I was deliberately answering the question of how you could use foldl and seq to do it.

@mweisbr I could have tested for <>1 or <0 , as you stated, but <10 happened to work since all other day was larger. It was just less typing.