Your attempt to get the overall vertical min&max with,

   plottools:-getdata(A)[3][.., 2]

is faulty because you have multiple curves structures in the plot.

But rather that fix that approach (ie. get the min&max for each and then compare/combine) you could use the rangesonly option of getdata which will figure out the overall min&max in both directions. Ie,

   ymin, ymax := op(plottools:-getdata(P, rangesonly)[2])

vertical_and_horizonatl_line_help_ac.mw

If I plot the surface at a higher grid resolution, in only a narrow strip close to x=-1 then it appears that the surface is discontinuous along x=-1, for y>1.5.

Using implicitplot instead of contourplot seems to provide a useful mechanism for getting the contours to agree with the surface in that region.

I'll leave it to you to figure out whether the apparent discontinuities are (perhaps?) due in part to numeric roundoff issues due to the complicated scaling of factors (ie. exp calls, and very large/small coefficients). I don't see offhand how symbolic manipulation of the expression (even with exact rationals) sheds light there.

sai_1_ac.mw

You seem to have omitted to supply a value for y.

For example,

UnivariateBarGraph(beta, [seq(0..1, 0.2)],
                                   [Q = 1.3015, lambda = 0.9989, x = 0, Br = 1, y=1/10], "Chartreuse");

Is this the kind of plot you had in mind?

Test_date_ac.mw

Naturally, you can apply additional options and adjust the axis labels, etc.

@2cUniverse You can fix your problem with the first Button press by doing any of the following:

1) Move the calls to with(...) to before the use...end use, but keep them inside the Button's "click action" code.
pb-App_0.1_ac1.mw
This is somewhat inefficient since it calls with() each and every time the Button is pressed -- which is unnecessary since that's just an initialization step which only needs doing once per restart.

2) Move the with(...) calls outside of the Button altogether, to someplace else in the worksheet. Here I put it in the worksheet's Startup region, so that it's not visible when looking at the worksheet's body. (I'm guessing that you won't people being being distracted by the code, whether its outright visible or even just buried in some Code-Edit Region.)
pb-App_0.1_ac2.mw
For fun I've thrown in a call to randomize() here, which has the effect of making a different set of random values (and, here, plots) be generated after any restart or reopening of the sheet. This make the first plot be different from the previous session's first plot.

You could use the ParseTime command in the StringTools package.

For example,

Download ParseTime_ex0.mw

Adjust as needed. (You could also add a separator between the year and the hour, or add more fields, etc.)

The axis labels part can be had by,

  labels=[`x `(InertForm:-Display(10%^8,inert=false)*Unit(m)),
                `t `(s)]

which gets upright Roman m, italic x,s,t, a space before the opening brackets, and 10^8 in upright Roman without automatic simplification to 100000000.

Using `10`^8 is shorter to type, but the concession is that the 10 is in italics. Alternatives which also show the 10 in upright Roman include,
  InertForm:-Display(10)^8
  `#mn("10");`^8
  Typesetting:-mn("10")^8

The following solutions found by solve can be tested by resubstituting and simplifying.

Download help_c_solve.mw

Here's one way. I tried to focus on making it easier to understand, instead of using fancy terse syntax or making it super efficient.

Download minhthien_s1.mw

[edit] This is also not efficient. But, since you asked, it uses the prime notation for differentiation in 2D Input, and applies at argument 2 (instead of evaluating at point x=2).
minhthien_s2.mw

I did not look for any pattern in the entries of mylist (as a possible shortcut to the solutions, say). I don't know whether you have any rules for forming those entries.

Here's one way to get a more accurate plot. See attachment.

This is an interesting plot. (Is it meaningful, in terms of the as-yet unstated background theory here?)

Reza_Tchno_v3_ac.mw

Have you investigated the system symbolically, possibly using exact rationals? That might possible be able to demonstrate the feasible bounds for alpha, or piecewise explicit formulae, etc.

Do you know whether there is only ever a single solution that satisfies all the constraints?

Do you know for sure that it wouldn't be possible to churn out a relatively simple piecewise solution (in terms of alpha, say), that might be super fast to compute/plot?

Are you interested in finding the critical alpha values?

Have you considered trying to use purely floating-point optimization (eg. alpha->1 as constant objective, and the rest as mixed equality/inequating constraints, thus leveraging Optimization:-Minimize to compute/find a feasible point), for better speed?

Here's one way to handle your given polynomial example.

Download sgn_ex.mw

ps. You gave the target form as x^3 - (m-1) x^2 - (4m + 3) which isn't equivalent to your input expression. And so I have guessed as to what you wanted to accomplish with the coefficients.

Download Applying_identities_from_FunctionAdivisor_ac.mw

Download auto_simp_ex.mw

note: A little bit more on automatic simplification can be had in Section 3.4 "Unevaluated Expressions" of Chapter 3 of the Programming Guide, in the subsection "Evaluation and Automatic Simplification".

This question pops up now and then. This old Reply contains a couple of other approaches, including using MakeInert instead of %*.

Another alternative is to wrap one of the factors in a call to ``(...). For example,
   content(expr) %* ``(primpart(expr))
as shown also in that very same linked old Reply of mine. I don't generally prefer that approach over using InertForm. I also dislike how its results can sometimes get display with extra brackets in output, even though that doesn't occur for this particular example. I generally prefer how InertForm works, over the ``(...) approach.

With so many floating-point evaluations of those special functions the internal memory management system (gc) may collect some of the computed results from evalf's remember table.

But your expressions have two pairs of repeated special-function calls, ie. to WeierstrassZeta and to WeierstrassPPrime.

By forcing the computed values to be remembered (even when gc occurs) I get about another factor of two speed up here.

Download WZ.mw

An alternative way to speed it up would be to parallelize the population of the float[8] Array inside the resulting MESH plotting structure. [see below]

Here is the most that I am able to recover.

Basismat_2_noter_acc.mw

I suspect that it is missing just two inputs, which I'd guess are 2D Math Matrices that occurred here:
1) just after "Løsning er da:"
2) just before "Bytter række 2 og 3:"

I suggest that you try to use Maple 2023 instead of your current Maple 2022. This kind of worksheet corruption appears (so far) to be much less common in 2023.