@tayyab107 If you simply omit the discont option from the plot command, then the vertical line segment will appear.

@Preben Alsholm Thank you. Your information helped me to make a new diagnosis. See my next Answer.

The Elliptic and Jacobi functions are not handled by evalhf.

Does the existence in Maple of the function InverseJacobiSN help your situation (see ?InverseJacobiSN)?

I don't understand why long conditions would prevent you from using piecewise. If it's simply a stylistic issue, then assign the conditions to variables to shorten the piecewise command. For example:

r:= sin(x)+x*cos(x) < 1/2:
f:= piecewise(r, sin(x), cos(x));

Note that the assignment of an inequality to a variable doesn't force it to evaluate to true or false.

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