Are you trying to say that you want it substituted by sigma literally, or that you just want a factor of Ls pulled out of the particular subterm?

Download question20200618_ac.mw

The dsolve parameter list is wrong in several places, and contains hidden 2D Input characters. That problem might also occur for the A in the initialvalues list passed to Minimize, and possibly also for the parameter sequence in the definition of procedure sse. You may be able to correct it in 2D Input by deleting the A character insteances and typing it in again. You'd likely be better off not using 2D Input mode, as it's clearly problematic for you.

You seem to be missing initial conditions, because the input line which assigns to ic has several statements broken by colons. You very likely should change those to a comma-separated sequence of equations instead.

The add call inside your sse procedure is not set up to handle the case that the result from select is an empty list. (In that case, it would pass NULL to rhs and throw an error.) It looks as if your select call might be an attempt to extract just one of the dsolve results solution procedures, is that right? Iso, then which one? Is it C(T)?

You may need to specifiy ranges for the parameters, in the call to Minimize.

You may need to adjust procedure sse so that it handles the case of a singularity in the numeric solution. (try..catch and return a large value? Something else?)

Your worksheet has a colon terminating the line with the call to Minimize. You likely would be better off not supressing that output, to see how it does.

You could apply this command.

Download SPCSq.mw

Look at the computations and figure out what purpose they might serve in addressing any of the questions.

Download saddle_extr.mw

See the Help page for Topic object,function_mechanism which discusses some special situations of invoking methods.

Your process example in particular (a collision with another module in the namespace) can also be handled via the function syntax.

This might also assist you with a releated case which you have not yet covered in your Questions, involving mapping the same name (of method functions) across multiple objects. (See examples in the page.) In that case you might specifically want to not refer to the name as the export of any particular one of the objects.

Download object_function.mw

You could adjust the datatype to also include a specified default fill value.

Or you could specify a dummy instance of your object as a default fill value -- even if the fill value never gets used explicitly.

As an example of the former idea:

Download Array_dt_fill.mw

The former idea looks a little uglier when set up, and interferes a little as it relaxes the strictures that usually come for free from a proscriptive datatype. But the latter idea could be unsatisfactory if you really didn't want any instance to exist strictly outside of when instances were stored. (Such a circumstance could be contrived, albeit artificial.)

Also, the awkwardness is not specific to object types.

Array(datatype=prime);
Error, unable to store '0' when datatype=prime

A:=Array(datatype=prime, fill=2):  # distasteful
A(3):=7;  # ugh
             A := [2, 2, 7]

A:=Array(datatype=prime, storage=sparse):
A(3):=7;  # sigh
Error, unable to store '0' when datatype=prime

A:=Array(datatype={prime,identical(0)}, storage=sparse):
A(3):=7;
             A := [0, 0, 7]

@nm You wrote,

   "It would be much more natural to do something like
     my_car[set_name]("toyota") or my_car:-set_name("toyota")

    And then my_car:-get_name() since in these, the object itself
    is upfront, instead of being passed as an argument."

You can do this:

Download car_class.mw

Of the 8 root formulas (in v[c]) there are two that are real-valued for all real b[2].

You could plot them using the implicitplot command. Or you could plot the explicit formulations of just those two. Or you could plot the real and imaginarty parts of the explicit forumulations. You could investigate the discriminant, if you so wish.

What makes you think that you are missing out on some details? I see no evidence that you're missing out of some regions of b[2] for which there are additional nontrivial purely real solutions. Did I miss it?

note. I don't advise trying to think of matching up the explicit formulas (or their real and imaginary components) with particular connect curves, unless you want to wade into deeper water. (This relates to the blue vertical noice connecting curves in two of the plots.)

note. I have not tried to do anything along the lines of RootFinding:-Parametric, even with an approximation for Pi.

Download ComplexPlotQuestion_ac.mw

Download ComplexQuestion_ac.mw

There are other ways to accomplish this kind of thing.

I'm not sure which you would consider as best, in part because I know little details about your actual examples or requirements. (Are they all numeric, are float results ok, is it supposed to be highly efficient or just easy, etc.)

Download LSunder.mw

If your results have additional symbolic names in them (ie. that are present in the input, and are not just the introduced free parameters) then it is easy to adjust the evalindets 2nd argument (the type) to match only the introduced names. (With the base of the introduced parameter names under one's control there is no need to check also with a set intersection.)

Download LSunder2.mw

You can access data structures directly using OpenMaple. You could go via a C extension to python.

Using the cmaple interface is not the really the right interface for the kind of interprocess memeory interaction you're describing.

I am not sure how you got in that bind, but here are a few adjustments (still using Equation Labels, etc), but with eval and unapply.

I used Maple 2018.2, to match your major version.

Download units_issue_ac.mw

Do either of the attempts in this attachment work in your Maple 13?

Clutch_Modell_ac.mw

It's a little difficult for us, since the odeplot that seems problematic in your Maple 13 works in later versions (eg. Maple 16, Maple 2020).

I see that you've ignored my comment in your earlier duplicate of this topic, where you might consider another mechanism for the piecewise function than the unevaluated call to the unknown function(s).

Your procedure Basenwechsel itself uses the name Basenwechsel in two different ways.

Firstly, it assigns to the name Basenwechsel. as if to use it as a local variable. But secondly, it calls Basenwechsel in a function call (perhaps an attempt at a recursive call to itself).

Perhaps you can instead make Basenwechsel act recursively by using the procname syntax instead . See the attachment below.

Also, you have calls to with inside your procedures. That won't work properly. You could utilize the uses syntax within the procedures, or even more move them to the top level.

I suggest that you explicitly declare all the intended locals of your procedures, so that you know what they are doing. Don't rely on impliciat local declarations. And don't try and use the same name in two different ways.

Check whether this works as you hoped: Basenwechsel_ac1.mw

Did you mean that you wanted to shade the curve itself, or the area between y=0 and the curve, or something else?

If you just want to shade the curve with a single color then pass the color option, eg, color="Blue", etc.

  plot(x*ln(x), x=0..1, color="Blue");

If you want to shade the region between y=0 and y=x*ln(x) then pass the filled option.

If you want to shade the curve itself in a varying manner then you can pass an appropriate colorscheme option.

For example,

Download 2D_curve_shade.mw

There are other variations of coloring, etc.