@vv Your symbolic solution using RootOf is very clever. It would be great if that could be generalized to an arbitrary division into subintervals. In my work, I'm attempting to deal with taking the derivative wrt the parameter of parametrized definite integrals whose integrands are nested piecewise functions whose conditions depend on both the parameter and the variable of integration.

@vv Yes, my solution was only intended for numeric procedures. For symbolics, I think that piecewise is the best available alternative, even though it has numerous deep and very difficult-to-correct flaws. But don't use is for piecewise's conditions. It uses its own version called PiecewiseTools:-Is, which handles the case of symbolic variables much differently than is. This would perhaps address your comment "Maple should do much better in such situations". This PiecewiseTools:-Is is undocumented; however its code is brief and easy to understand.

@vv It's definitely not a bug. The statement is(x > 0), for example, correctly returns false under the default assumptions for x.

Would you please do each of the integrals in both Maple versions and post the results? My first hunch is that the multi-story nature of the integral on the left has something to do with why it transcribes better.

@Kitonum Your procedure can be simplified to use a table and thereby avoid a loop.

getCoeff:= proc(P, t, T::{list,set}(name):= indets(P, name))
local h, L:= coeffs(P, T, h);
   table([h=~L])[t]
end proc:

Now also the [a,b,c] can be removed from the calls as it is now the default for parameter T.

Do a trace on your procedure to make sure that it returns floating-point values in all cases. For example, if the procedure is P, do trace(P) and then run NLPSolve.

If you still have trouble, please post the code.

@Kitonum Trigonometric functions of exact rational multiples of Pi can be converted to algebraic numbers via convert(..., RootOf). Then they can be handled by the very powerful evala command.

Example: convert(cos(667/345*Pi), RootOf)

@akhmeteli No one yet has provided any evidence whatsoever that anything other than garbage collection triggers status-line updates. Consider these facts:

• The documentation says explicitly that garbage collection causes status-line updates.
• My program verifies that the above statement is true.
• Nowhere else in the documentation is it mentioned that anything other than garbage collection causes status-line updates.
• No one has mentioned any other thing that could possibly trigger status-line updates. If someone suggests such a thing, I'd be happy to test it.

So, given all that, why would anyone believe that anything other than garbage collection triggers status-line updates? It seems to me that there is no evidence whatsoever that any other thing triggers them.

@Markiyan Hirnyk Have you read the help for kernelopts(gctimes)?

Your failure to understand my program doesn't constitute a valid refutation of what I wrote. You said that you have some evidence that the status line is "updated independently" of garbage collections. Please present that evidence.

@akhmeteli Of course my program can't provide an ironclad mathematical proof that garbage collection is the only process that updates the status line (only viewing the Maple kernel code can do that), but it's pretty convincing: there's an exact bijective correspondence between the status-line updates and the output of my program. Note that my program is not forcing the garbage collections, it is merely observing when the "natural" garbage collections occur. Every time one occurs, there is an update, and there are no extra updates at other times.

Markiyan: If you have evidence that what I said is wrong, then it's your duty to present that evidence (to "base" your statement). Your asking me to "base" my statement doesn't constitute a refutation of my statement. This is not a question of mathematical proof or criminal law where only one side has the "burden of proof".

@Markiyan Hirnyk Why do you think that I misunderstood it rather than that you misunderstood it? The following code verifies what I said:

GctimesS:= kernelopts(gctimes):
Gctimes:= GctimesS:
to 2^23 do
   G:= kernelopts(gctimes);
   T:= kernelopts(cputime);
   if G > Gctimes then
      Gctimes:= G;
      printf(
         "%2d: Memory: %7.2fM  Time: %7.2fs\n", 
         G - GctimesS, kernelopts(bytesalloc)/2.^21 - 0.005, T - 0.005
      )
   end if
end do:

Before you press enter to execute the code, put your eye on the status line. Then press enter. Count how many times the status line is updated. Compare with the output of my program. You'll also notice a correspondence between the values printed by my program and the values printed on the status line.

@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?