@MichaelVio 

In the PlanckML.mw there was as assignment,
    E(nu) := %;
that was actually in 2D Input (despite being in red). That gets parsed as a procedure/operator definition in 2D Input mode. But the rest of your code (and other sheets) do it with the intention of being a forced (remember table) assignment to E(nu).

That's a reason why I'd like to know whether the plots are expected, in at least a qualitative sense. I am distrustful of this function call approach.

In all three sheets there were a few things related to working-precision and accuracy.

PlanckML_ac.mw
Aud2e_ac.mw
plkG_ac.mw

@eithne The Delete (as) Spam facility is not working since the outage, unfortunately.

That mechanism disables the account of the poster, so that they cannot so easily re-post. It also removes the user Profile (which often has additional spam URLs in it.)

ps. While I'm at it, there is another recent problem with the site, unrelated to the outage, but I don't know how to report it effectively: Answers with no votes (or the same number of votes) are now wrongly ordered top-to-bottom in reverse wrt the date posted. For years it worked properly, but now it's wrong. It's "top-posting" them, putting the most recent one at the top.

What do you think is the value of E(0)?

What is the relationship you are trying to use, between say v(k+1) and v(k)? Is it a recursive formula?

You haven't provided either an intended formula (recursive or not) or a sample of the expected series (output values). Please supply the relevant details.

ps. Let us know whether you're using 2D Input mode, because then preliminary values could be code in a conditional within the procedure instead of using suntax like v(k):=1 which gets parsed as a clobbering procedure definition.

@ashy In Maple 18 it does not do all additional simplification steps in the same way.

Download end_M18.mw

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