My guess is that you want a cone with an elliptical base, the ellipse having a given center c and eccentricity e, and the vertex being c+v where v is what you call the axis vector. Is that right? And, if so, do you want that ellipse to be in the xy-plane with its axes parallel to the coordinate axes? 

It doesn't seem possible, unless n = 0. Would you please post a worksheet where this happens?

@shadi1386 

Are your f(x) values in flist exact values, measured values, or approximations? If they're measured or approximate, do you have some general guess for the mathematical form of f(x), such as rational function, exponential, exponential with sinusoidal fluctuations, etc.? And is that guess based on theoretical considerations or just on eyeballing the scatter plot?

The only difference that I see between the two expressions in your original Question is that the latter has a "partial" d where the former has a regular d. Computationally, this makes not a whit of difference, and it boggles me that no one has pointed that out yet. Thus, I can only assume that your only issue is not computational, but rather formatting a document for display. Is that correct?

@Wadyan 

What you are calling an n-dimensional plot is ordinarily called an (n+1)-dimensional plot. I will continue to use the n+1 designation.

Note that the ways that you're animating the 2- and 3-D plots are not at all analogous. In the 2-D case, you're animating by increasing the domain of the independent variable from left to right. In the 3-D case, you're animating by scaling (rather than truncating) the dependent variable.

Both of my animations below are done by generating the final frame as static base plot and then generating each frame as a manipulation of that base plot.

U:= RandomTools:-Generate(float(method= uniform, range= 0..1), makeproc):

frames:= 2^5:
points:= 2^9:
P2:= plot(x-> abs(x)*U(), -5..5, adaptive= false, numpoints= points):
Pts:= plottools:-getdata(P2)[3]:
plots:-display(
     [seq(plot(Pts[..round(f*points/frames), ..]), f= 0..frames)],
     insequence, thickness= 0
);

frames:= 2^5:
points:= 2^7: #2^7 in each (x,y) dimension. Total points = 2^14.
P3:= plot3d((x,y)-> abs(x)*U()+abs(y)^2*U(), -5..5, -5..5, grid= [points$2]):
plots:-display(
     [seq(plottools:-scale(P3, 1, 1, f/frames), f= 0..frames)],
     insequence,
     shading= zhue, axes= frame, transparency= .5, style= wireframe, thickness= 0
);

In a worksheet, feel free to increase the FPS (Frames Per Second) for either of these.

@Spartan 

I already anticipated your most-recent followup question, and I was adding a paragraph about builtin commands to my most-recent Reply and you were writing it. So, go look at that Reply again.

While diff itself is builtin, the code which controls the differention of most functions isn't. See, for example,

showstat(`diff/sin`);

@Spartan 

Diff is an inert function: It has no code; it's just a name. It serves as a placeholder for a differentiation operation which hasn't been performed, but which may be performed in the future. An inert function is converted to its active form by the command value. Other examples of predefined inert functions are Int, Eval, Limit, Sum, and Product. In each of those cases the active form is the corresponding lowercased command; however, it's neither necessarily true that an inert/active pair are capitalized/lowercased, nor that an inert function has any active form---indeed, most don't. (When they don't have active forms, they tend to be called unevaluated functions rather than inert functions, but this distinction has no practical significance.)

You can see that Diff is an inert/unevaluated function by doing eval(Diff). Since the result is simply Diff, it's inert.

Sometimes an inert function is used to achieve a certain prettyprinted display. In that case, there's a corresponding print procedure. In the case of Diff, the print procedure is `print/Diff`. The execution of the print procedure has no affect on the mathematical computation---it just affects the display. There are two ways that print procedures can be named: They can be named `print/...` (as with Diff), or, in the case of an object (a very recent invention), they can appear as a procedure named ModulePrint in the object's defining module.

There are a few hundred fundamental (and mostly low-level) commands that are builtin. These aren't written in Maple, and their code isn't viewable. The command diff is builtin. This can be detected by

showstat(diff);
Error, (in showstat) cannot debug built-in functions

However, int isn't builtin; it's written in Maple, and you can see its code.

@Markiyan Hirnyk Thank you for pointing out the error in my procedure. I had inadvertenty pre-evaluated the module's locals before testing the procedure, so I failed the see that in the general case they need to be evaluated inside the procedure. Please use the procedure in my most-recent Reply above.

Note that the corrected procedure is still ad hoc to the given module, which has no exports. With some minor updates, it'll handle exports and apply itself recursively to submodules.

@Spartan 

Not every module local or export is a procedure. Some of them are just unassigned names, just like the locals of most procedures. Or they can be any other Maple data structure. In the pristine state (i.e., just after a restart), currEqn is just an unassigned name. I suspect that if you recheck after actually running DiffTutor, it'll be assigned the expression that you were trying to differentiate.

I had intended that the procedure that I gave would actually print out all the procedures, not just list their names. But due to a dumb mistake, I wasn't in the pristine state when I tested. Here is what I intended for my procedure:

ModulePrint:= proc(M::`module`)
uses ST= StringTools;
local Ns, N;
     interface(verboseproc= 2);
     kernelopts(opaquemodules= false);
     try unwith(M) catch: end try;
     Ns:= eval~([op(3, eval(M))]);
     Ns:= ST:-Split(sprintf("%q", op(3, eval(M))), ",");
     for N in Ns do
          lprint(N);
          parse(sprintf("print(eval(%s))", N), 'statement')
     end do
end proc:

ModulePrint(Student:-Calculus1:-DiffTutor);

This'll list all the procedure code for you; you should need no other commands. If it doesn't, let me know.

@bpourhamzeh I doubt that I would've figured that out simply by looking at the menus.

If you have a restart command at the top of your worksheet (which is almost always a good idea), keep it in its own execution group.

@ecterrab 

Have you looked at the examples in my previous Reply? How do you explain them?

No, my question is not yet clear to you. I do not want the indices to start at different values! That would be ridiculous. But I am trying to show you that your system as currently implemented DOES cause the indices to start at different values even when that is not what the user intended. Did you think that the examples that I posted in my previous Reply represented how I wished the system to behave? No, they are examples of actual execution, of how it DOES behave.

What I want, if possible, is for both indices to start at 1. If they must start at 0, I can work with that.  But the behavior shown in my second example must be a bug, right?

You said:

where the lower limits are always determined by the value of the right-hand-side of the multi-index sum

This has me baffled. Did you mean the left-hand side? My first example above clearly shows that making the left-hand side 1 does NOT make the indices start at 1.

Haley,

I am very disturbed about not getting a reply from you. I put a lot of work into my Answer, and I think that it is generally useful. Does it answer your question?

@tomleslie You asked:

Maybe if someone could tell me for which type of argument my simple-minded overload gives a different answer from Carl's

Those types of arguments are named tables, named modules, and named procedures. This is because of the "last name evaluation" rule that applies to those (see ?last_name_eval). I could've also coded it as

proc(C::And(name, Not(last_name_eval)))...

I hope that this explains the &under concept once and for all: type(X, T &under P) if and only if type(P(X), T). In the case at hand, I don't simply want to require that C be of type name; I want to require that eval(C) be of type name.

Your "simple-minded" attempt was very good. It would've been thwarted by a named table argument, but this last name evaluation rule is a very special case.

You've been asking very similar Questions for a few weeks, as if you're not learning from the Answers that you've been given. So, what's going on? You should post your attempted Maple work. It helps us to see what you're doing wrong.

Excellent Question.

What is the density of the matrices (the proportion of nonzero entries)? Is there a highly structured pattern to the nonzero entries, such as tridiagonal? What is the average and maximal degree of the polynomials for the dimension = 674 case? Are the polynomials themselves sparse? If so, what is their average density? What is an upper bound for the integer coefficients? Does your algorithm require multiplying different such matrices or just raising matrices to powers?

Time the run of your 34-second example like this

CodeTools:-Usage(LinearAlgebra[MatrixMatrixMultiply](A,A)):

and report the results. (I'm particularly interested in the garbage collection time.) It doesn't need to be exactly the same example that you used earlier.