@billpage It's a very interesting question/situation! It seems that the elementwise (tilde) operators have been optimized to work with float[8] rtables so that they're even faster than map[evalhf]. So what we need is a way to automatically convert the operators in an expression to elementwise operators. I think that the way to do this may involve ToInert. Consider

f1:= x-> 2*x*cos(x^2):
f2:= x-> 2*x*~cos~(x^~2):
ToInert(eval(f1));
ToInert(eval(f2));

Now think about what would be required to transform the first to the second. The transformations could be done with subsindets. The transformed function tree can be converted into a regular procedure with FromInert.

@brian bovril Your matrix can't possibly be a distance matrix (in any number of dimensions, under any metric) because it violates the triangle inequality. The distance from point 1 to point 2 is 4, the distance from point 2 to point 8 is 6, but the distance from point 1 to point 8 is 11: dist(1,2) + dist(2,8) < dist(1,8). The triangle inequality is a formal expression of the common-sense notion that you can't a shorten a trip by making an intermediate stop.

Let's write such a procedure. A good starting place would be an explicit description of an example problem.

Vote up. The work is very impressive, as is the improvement in resolution over implicitplot3d.

After a brief look, I think that your procedure is a great candidate for optimization via evalhf, Compiler, and/or Threads. In all cases, the fsolve would need to be replaced. Am I correct that the equation being fsolve'd is linear (I only looked at it briefly)?

Your final example, (x^2+y^2-1)^2+(z+sin(x*y+z))^4-120, doesn't immediately appear to be star-convex wrt the origin (or any other interior point). Is it?

@tsunamiBTP It's zip(`^`, A, 2), not ZIP("^", A, 2). Capitalization and the type of quotes matter.

@John Fredsted There's also the more-efficient

map(`^`, A, 3);

It's more efficient because it doesn't repeatedly use any Maple-level procedures (such as x-> x^3); it only uses the kernel-level procedure `^`.

@tsunamiBTP To cube (for example) every element of a Matrix A in Maple 12, do

zip(`^`, A, 3);

That'll still work in modern Maple, but it can also be abbreviated to A^~3. All the elementwise operators are regular operators followed by ~. If one of the pair is a singleton, like the 3 in this case, then it is the element that is paired with every element of the other member of the pair.

When you're entering a Question, there's a check-off for "Product", where you selected Maple for this Question. Then there's a pull-down list where you can select your Maple version. It'd be very helpful to the people who answer your Questions if you'd check off the appropriate version, so that it'll be clearly displayed in the Question's header. This'll save both of us, and the other readers, a lot of time, display space, confusion, and aggravation going back and forth suggesting that you try things that you can't and that you read help pages that don't apply to your version.

@Preben Alsholm Yes, I'm certain that they came with Maple 13. They are now a fundamental part of the syntax for me, so much so that I think in terms of them now. I don't think that there've been any major enhancements to the syntax since then. There've been some minor enhancements to modules with option object.

For me, Maple 6 and Maple 13 have been the only versions that have made major enhancements to the language itself. (I started with Maple Vr4.) If the time interval between major enhancements stays the same, we're due for another one this upcoming release. (Recall that 9.5 was a major yearly release, so it was eight years from Maple 6 to Maple 13.)

@Kitonum Thanks. Actually, I was looking for a way to do it just with the Matrix(...) constructor or with the angle bracket constructors, and I couldn't quickly find one. The syntax is not very flexible when you're trying to put matrices in a Matrix. But it looks like you found a way.

@rlopez And I encourage the OP to use those plots to figure out why the limits of integration are as they are in each of my five integrals.

Dr. Robert Lopez: Wishing you all the best in your retirement, and looking forward to your future contributions to MaplePrimes.

@Christopher2222 It seems to me that doing

e:= exp(1);
protect('e');

does everything that you could want from e, both symbolic and numeric. It's not appropriate in Maple---a language for symbolic computation---that a symbol such as Pi or e evaluate to floating point unless that is specifically requested.

@tomleslie You've made a few mistakes in computing the volume. One mistake is that you subtract the volume of the cylinder from that of the sphere. You also need to subtract the spherical endcaps of the cylinder. I don't understand your integral for the volume of the sphere, or even understand why you use an integral rather than a geometric formula.

Do you mean that you want to save a Maple worksheet, or part of a worksheet, as a video? If so, do you mean that you want to save an animated plot? Or do you mean that you want a video, like a Youtube video, that tells you how to save your Maple project?

@John Fredsted If one were to save all the variables to the same file, then they couldn't all be named a. So I can conceive of some reasons why one would want different files. Another reason is that they may not all be able to fit in memory at the same time. But, I think that you were right to inform the OP of the possibility in case they weren't aware of it.

That's very useful---to separately color the two sides of a surface. Your code is quite lengthy, and the resulting surface is so densely populated (by polygons, I think) that it is difficult to rotate. I don't know whether this is because of the complexity of the surface itself or because of your side-separation technique. Would it be possible to apply your technique to a simpler (but nontrivial) surface?

Note that for many surfaces it is trivial to achieve this by a lateral transformation, such as this plot of a hemisphere:

S1:= plot3d([1, theta, phi], theta= -Pi..0, phi= 0..Pi, coords= spherical):
S2:= plottools:-transform((x,y,z)-> [x, y + .01, z])(S1):
plots:-display(
   plots:-display(S1, color= red), plots:-display(S2, color= green), 
   scaling= constrained, orientation= [45,60,0]
);

Note that all plots are stored in Cartesian coordinates, so plottools:-transform always uses Cartesian coordinates, regardless of the coordinate system used by the original plot command. (I know that you already know that; this paragraph is intended for other readers.)