@jalal Is this the kind of effect you're after?

S5_Périodique_Rôlede_C_ac.mw
 

ps. Here I am using the other kind approach that I mentioned at the start of my Answer, where the animating variable simply takes on integer values. The integer value gets scaled by the increment, wherever used.

pps. It's not most efficient to repeatedly call plot like this. You could instead simply call plot once, up front, and then translate the plot horizontally. But for this example it's not too slow to create the animation as you've done.

@Arya-S-AA Only you can explain what "best" means to you.

@Arya-S-AA For some choices of values for the parameters the expression might not be finite/defined for all x and y, or throw a division-by-zero.

If that happens at the end-points (some combinations of which Explore tries, up-front) then you see the warning generated when the plot3d returns empty or fails.

In your example you might just ignore that warning.

Or you could suppress all warnings (which I won't show; it might hide some more serious mistake, in your future attempts).

Or, for this example you might adjust some of the parameter ranges a little.
p-not_ac2.mw

@jalal I don't understand what you are saying, sorry.

Here's an idea: Forget all about animation, just for a moment. Show what you want (both blue and red curves) in a completely static plot, when C=Pi/4. And then show in another static plot what you want when C=5*Pi/3.

@Aixleft math You're welcome.

Those `solve` calls are not really necessary. We can see that the pairs of formulas are the same (apart from variable name).

There are other trig examples (same class of problem) for which equivalent sets might not have formulas which are so similar or identical in form. (eg. they might be complicated, with overlap in formulas covering one of the sets.)

So, another general technique is to take an arbitrary element (with parameter name) from A and show (`solve`,etc) that there exists some element in B equal to it. And then do the reverse, for an arbitrary element in B.

For some examples that technique can look like the former approach.

Naturally, these are ideas for proof, ie. formal verification.

@Joe Riel I had supposed that this was a code fragment that the OP $includes in a parent module.

Personally I'd prefer to mint the whole parent module rather than such a fragment, because doing so is more sensible, and since mint allows the same nice -I include option syntax as does the maple launch script.

I'd noticed that the strange characters don't appear if it isn't a named module, ie.
   export ODE := module() ...
works as expected. That throws the warning about the unexpected export.

I wouldn't call that "export" instance nonsensical. It might be unexpected, and a syntax mistake if taken on its own. But that's what mint is for; to report on syntax usage issues, not itself to choke on them.

One shouldn't have to clean up and fix syntax mistakes before being able to properly use the syntax-checker program to be able to analyze the code.

And without the export it's fine. It seems to just be the combination of unexpected export and named module that finds a hole in mint. A mint bug, then.

nb. I'm aware that the OP pushes his modules, and judging by past postings I'd guess that he is relying on named-module functionality.

That is a very nice read. I vote up.

A couple of brief notes on your Comment #4, if I may: fewnotes.mw

Also, someone (member nm?) suggested not too long ago that simplify ought to be able to cancel some common factors from both sides of an equation.

@Rouben Rostamian  Thanks. I should have given examples.

This is what I had in mind, with the first two variants being analogous to the latter two in the sense that the addresses of the various x instance are different, ie. they're distinct.

The first pair and the second pair are not exactly the same, but I figured that the analogy might serve as some kind of explanation.

Download misc_global_local_assumed.mw

@zenterix The purpose of the various choice for the second argument passed to the combine command is that they restrict it to only try/perform some manipulations.

If you don't pass a second argument then combine is free to do all that it can. And that's often how it gets used.

For example, combine(...,trig) will not attempt to combine radicals. And so on. It's relatively rarer that one wants to prevent certain flavors of combinings -- though of course it does come up.

Btw, your followup comment's worksheet doesn't do as much with radicals as what happens in your original worksheet. Eg, `s` and `s__2` don't have values, whereas in the original their values contain some radicals that may get combined in the subsequent steps that form the expressions assigned to `expr4` and `result`. So, while combine might not do so much of interest in your followup sheet, it does in my Answer's worksheet that addresses your original (as far as some radicals go).

You can adjust any of the lines that call combine, and do them in two steps: first create the expression (using eval or substituting or what have you), and then second apply the combine command. Then you can see the combing of radicals that occurred.

Not every construction of your expr2,expr3,expr4,result expressions need a combine call. I put some of them in only so that the progression of expressions would be more understandable and compact (if you change colons to semicolons, to see all intermediate results).

@nm Contrary to what you've just written, I was in no way suggesting a "workaround" with that mapped list example.

Rather, I was narrowing down how/when the behavior was lacking, by showing that mint is indeed sometimes able to handle a truly anonymous procedure; I showed that because you specifically asked whether it was failing because of the anonymous property. The answer to that query -- as demonstrated -- is no, it doesn't happen purely by virture of the procedure's being anonymous.

Yes, I think that mint could in principal do better with the special case of an anonymous procedure that is immediately applied, by analyzing it and producing output similar to the broader cases.

Your last comment's further justification/explanation attempt is not necessary, for me; you appear to have mistaken my understanding of the situation.

ps. A workaround might be to assign the inner procedure to a name. That could still be done in a nested manner (even though in one of you followups you didn't retain the nesting, yet you could). Note that it's more efficient to create "helper" procs just once, outside; creating the inner proc each time its's called and each time through the outer  proc is less efficient. Of course, don't know how many times you'll call it all, or whether proc creation is dwarfed by additional computations.

About your followup 2nd example, you wrote, "Also, I noticed it did not warn me that variable sol is global inside the proc."

The name sol is implicitly declared local within that anonymous procedure. Contrary to what you're written (in that direct quote), the name sol is not used as a global name in your Question's code example.

There is currently no attachment.

@Joe Riel Ignoring the mystery for now, at least this one looks legible:

restart;

kernelopts(assertlevel=2):

proc(x::coerce(set, proc(y::rtable)::set;
                      return convert(y, list);
                    end proc))
  x;
end proc(<0>);

Error, (in anonymous procedure) assertion failed, unknown expects its return value to be of type set, but computed [0]

@Joe Riel What as I missing here? I don't understand why the second of these throws the (expected) exception, while the first of them does not.

Download hmm_proc.mw

What's the end-goal here? What do you plan on doing with the result?

Is it only to get a more compact display, or do you eventually want to evaluate it at values for some/all variables and want that to be efficient?