@Anthrazit See also the first paragraph of the Description section of the Help page for the parse command,

"The parse command takes a Maple string and parses the string into a Maple expression as if it had been entered or read from a file."

Another example, where I have a file names file.mpl in my home directory, whose contents are just the single line,
   a;

Download parse_ex3.mw

@mmcdara I had written it at first with convert,base .

Then I did some perfomance stress testing and noticed that Explode was slightly faster (for the sizes I considered).

@jasser 

Download fl_op.mw

Note that in your earlier examples the log10 of the repeating part can be used to indicate which is the last decimal position occupied by the non-repeating part. So trailing zeroes needn't get in your way there.

So, for example, if you wanted the number of decimal places (to the right of the dot, including zeroes to its left) taken up by the fractional part of the non-repeating part, then you could compute that as 1 less than the decimal place in which the repeating part started.

Download rep_dec_2.mw

Please put your close followup queries here, instead of spawning wholly separate new Question threads for such.

The dsolve command expects its first argument to be a list or set of both the differential equations and the initial conditions, together in a single list. But your attempt is passing those as two separate lists.

Instead, try something like this:

   SOL := dsolve({EL[V][], IC[V][]}, [r[V](t), theta[V](t)], numeric, output = listprocedure):

ps. Are polar coordinates best here? By what proportion might you expect r to vary? (If varying by only a very small proportion, would extra working precision be necessary?)

@MaPal93 Please don't start another thread for this.

@ceeeb It wasn't just a hint, IMO. I explicitly explained that the 2D Input sigma' instances were different (and how).

ps. I deleted the eight extra copies of your response.

Please stop posting multiple Question threads on this.

If you have followup queries then please put them here, instead of spawning wholly separate new Question threads on this.

@Jack D Well, the first thing is that I used fsolve instead of solve.

The maxsols option of fsolve currently works for a finite range, so I supplied such, admittedly based on a visual plot. (I could also have used m=-100..100. It's generally faster if it's not unnecessarily wide. Seems I could have used -10^6..10^6 as well.)

No, I didn't specify a starting point.

@dharr Another possibility is,

   simplify(convert(bdifxzero - bdif1xzero, abs))

Since your conditions are that re>0 and im>0 and im+re<1 then why make it work harder for the ranges out as far as re=10 and im=10?

The triangular domain can be handled with a special wrapping procedure for the plotted function. Instead, a variable range end-point can be used.

plot_NULL_warn_etc.mw

ps. It's not always necessary but it's a good practice to put interface calls in a separate paragraph or execution group than a restart. Sometimes it is necessary, for the GUI to adhere to it.

@JAMET You have some syntax mistakes.

For example,

    display*[textplot*(

Those are multiplications, not the start of function calls.

@jalal I have deleted a duplicate Question thread of this.

@Ronan You are free to do what you wish, since it's your procedure.

But note that you haven't informed us completely what the specification of your procedure ought to be. I also didn't see anything in the Questions original code or description that would make an extra argument like name foo be invalid. Maybe there are more problematic cases, in your actual, motivating project.

I don't know why you want to force argument `foo` (a name) to be processed as if it ought to be checked against the specification of parameter c. I mean, you can if you want to. For example,  coercion_ex2b.mw
But suppose you have several optional ordered parameters. It might get confusing. If you're specifiying a optional parameter with a base type and a default value (as you did, originally, GeomClr) then why must any argument be checked against its spec and throw an error if not coerced? What if that argument is supposed to be used for another parameter later down the line? I'm not saying all that would definitively be wrong. But I don't know your final goals and requirements in all detail.

One alternative for handling unexpected parameters is to write $ at the end of the parameter specifications. That makes an error get emitted if there are any arguments left over (after parameter processing against the specs...). The error message is reasonably legible, IMO.

Download coercion_ex3.mw

I realize that we're just discussing possibilities. But if have more complications to pose then I suggest that you first write down and specify the exact behavior you're after, for all parameters of your actual problem, in full. Then, if you have problems attaining that behavior, show it all.

Here is one way of getting an error emitted. You may customize it.

Download coercion_ex2.mw