Carl Love

## 26827 Reputation

11 years, 280 days
Himself
Wayland, Massachusetts, United States
My name was formerly Carl Devore.

## solve(..., allsolutions)...

In your Case 2, solve chose (somewhat arbitrarily) two different branches of LambertW, but any branch would work. If you change all instances of solve(...to solve(..., allsolutions), I think you'll understand what's happening. If not, I'll explain further.

## plots:-animate...

First, pick a value of Kr to use. I chose 0.1. Then do

Kr:= 0.1:
F:= [f, Theta, Phi](eta):
Frame:= Inf-> plots:-odeplot(
dsolve({OdeSys, eval([Cond], 10= Inf)[]}, numeric),
`[]`~(eta, F), legend= F
):
plots:-animate(Frame, [Inf], Inf= 0.1..10, frames= 50, size= 500*[2,1]);

## convert(..., list, nested)...

All you need is

(A,B):= convert~(Solution, list, nested)[]: print('A'=A, 'B'= B);

## Procedure for it...

6Here's a procedure for it:

```#Bins takes a histogram and its data sample and returns a list of "bin-bounds" = count.
Bins:= (
H::And(specfunc(PLOT), patfunc(specfunc(POLYGONS), anything)),
S::{rtable,list}(numeric)
)->
local `&<`:= curry, `&>`:= rcurry;
(Statistics:-TallyInto &< S &> _rest @ (op&<[1,1]..op&<[2,1])~)(
[indets(op(1,H), And(listlist(numeric), 4 &under nops))[]]
)
:
```

Applying it to the histogram in your worksheet:

Bins(Q,A);

## max(0, ...)...

• I am unable to add a constraint with if statement.

The if syntax that you were using isn't allowed in 2D Input. Anyway the same thing can be better expressed with max because it'll remain symbolic until the solver supplies values for the variables, whereas an if evaluates immediately.

eq1:= Q2 = max(0, d*h*(x - delta*(alpha+beta)));

• I have to minimize the function TRC, i am unable to do.

You need a comma after the I2 = 0..8.

• Check whether i have represented I1 and I2 with respect to alpha and beta right or wrong.

I think that I'd need substantial background information on the problem to answer that.

Anyway, making the two minor syntax changes that I've given, the solver will at least return an answer, which is a step in the right direction, even though the ensuing discussion indicates that there are still some logic errors to work out.

## Same mistakes as before...

You've been making the same mistakes over and over, for years now. In your 2D Input, you need to remove any spaces after displaytextplot, and draw. Also, the arguments to display need to be in parentheses, not square brackets, just like all other procedural commands. These are exactly the same problems as the last Question of yours that I Answered.

## Even a crystal ball can't solve nonsense...

Even a crystal ball cannot solve a nonsensical problem. You cannot simultaneously solve n equations for more than n variables (n=1 in this case). That is a fundamental principle of mathematics. It is beyond being an undecidable problem (such as the Continuum Hypothesis or the propositions whose existence is guaranteed by Godel's Theorem). It makes no sense at all.

## Statistics:-LinearFit...

Following the directions given on the Wikipedia page "Weibull distribution", section "Parameter estimation", subsection "Ordinary least square using Weibull plot", I only made a single small change to your computation: I changed (i - 0.5)/n to (i - 0.3)/(n + 0.4). Anything else that may appear to be a change is merely a mathematically equivalent simplification. (In particular, there's no need to use both sort and Rank; using either one is sufficient.) Then I used Statistics:-LinearFit to do the regression.

 > restart :
 > St:= Statistics:
 > S:= -<-255.172, -235.249, -196.935, -132.567, -77.3946, -32.1839, -0.766284>;

 > n:= St:-Count(S);

 > lnpof:= map(i-> ln(-ln(1-(i-0.3)/(n+0.4))), St:-Rank(S)^+);

 > lnsigma:= ln~(S);

 > plot((data:= ), style= point);

 > PV:= St:-LinearFit([1, ln_x], data, ln_x, output= parametervector, summarize);

Summary:
----------------
Model: -2.4778919+.47999708*ln_x
----------------
Coefficients:
Estimate  Std. Error  t-value  P(>|t|)
Parameter 1   -2.4779    0.4212     -5.8834   0.0020
Parameter 2    0.4800    0.0931      5.1576   0.0036
----------------

 > k:= PV[2]; lambda:= exp(-PV[1]/k);

On the Maple help page ?Weibull, k is called c, and lambda is called b.

 > X:= St:-RandomVariable(Weibull(lambda,k)):
 > plot(St:-PDF(X,t), t= 0..9);

 >

## Mathematical vs. Syntactic equality...

This Answer is fundamentally the same as the one by @nm ; I just want to give some background information.

The command evalb, when applied to an equation, checks whether the two sides of the equation are syntactically identical; but you want to check whether the two sides are mathematically equivalent.

Two expressions are syntactically identical if they are stored in exactly the same way in the computer's memory. (In Maple, in practice, this means that only one copy is actually stored at all.) Via a process that Maple calls automatic simplification, some expressions which are typed in differently will become syntactically identical:

evalb(sin(a+b) = sin(b+a));

true

I think that you (and most other readers here) already understand basically what it means for two expressions to be mathematically equivalent. Let me try to be more precise (although this is still not a perfect definition): Two expressions are mathematically equivalent if they are numerically equal for all possible numeric substitutions of their variables for which they're both defined and which satisfy the "current assumptions". The "current assumptions", if unspecified, are all complex numbers. In Maple, assuming or assume can be used to specify assumptions.

Of course, if two expressions are syntactically identical they are also mathematically equivalent. But the converse isn't true. It can be proven (see Richardson's Theorem) that it's impossible to create a perfect algorithm to determine mathematical equivalence. So, whether you use isexpandsimplify, or numerous other commands, there will always be undecidable cases. However, one may hope that in the cases where the equivalence is already established via a well-known and elementary theorem (such as the case you present), Maple will be able to verify it. The best command to try first is is:

is(sin(x + y) = sin(x)*cos(y) + cos(x)*sin(y));
true

The reason that is is the best first choice is that it will give up and return FAIL if after some reasonable amount of time it cannot decide true or false. Other commands may run for an infeasible amount of time.

Regarding checking integrations: Suppose that f is the expression that you want to integrate (let's say with respect to x), and is your proposed antiderivative that you want to check. Then do

is(f = diff(F,x));

You may need to include assumptions on x. Appropriate assumptions are likely obvious. For example,

is(f = diff(F,x)) assuming x > -1, x < 1;

There's usually no need to exclude isolated singularities such as specific values of x that make a denominator 0.

Keep in mind that the default assumption in Maple is "all complex numbers", not "all real numbers". The calculus of functions of complex variables is sufficiently similar to that of real variables that you usually do not need to make the distinction.

## Complete extensively commented solution...

Level curves and orthogonal trajectories via numeric solution of an ODE

Author: Carl Love <carl.j.love@gmail.com>, 2024-May-24

 > restart :
 > interface(prompt= "") :

We are working with the level curves in the plane for this function:

F:= (x,y)-> x*y^2 - x^2 - y^2;

In other words, the curves specified implicitly by the equation

F(x,y) = k;

for any real constant k. Trajectories orthogonal to the level curves are important because they are the projections into the coordinate plane of the paths of steepest ascent/descent on the corresponding surface. Slopes of orthogonal trajectories are the negative reciprocals of the implicit derivative dy/dx, which we find by partial differentiation: dy/dx = - (dF/dx)/(dF/dy), so the orthogonal direction is (dF/dy)/(dF/dx). An unknown (aka dependent) function needs to be expressed "as a function of" its independent variable (x in this case). In other words (i.e., without symbolic-computation jargon), we need to change y to y(x).

Tj_ode:= diff(y(x),x) = (D[2]/D[1])(F)(x, y(x));

Note that when using D operator for partial derivatives, you don't specify the differentiation variable directly; instead, you specify its position in the function's argument sequence. So, D[2] is the derivative with respect to (w.r.t.) y, and D[1] is w.r.t. x.

 >

It's reasonable to guess that Maple can solve this ODE symbolically, but it can't do it directly:

dsolve(Tj_ode);

The NULL response to the above command shows that Maple cannot solve it symbolically, unless, perhaps some other options are given. I choose not to pursue that possibility, because a numeric solve is totally adequate for this.

I name the starting point (x0, y0) and ask dsolve to construct a numeric solver for this generic starting point:

Tj_sol:= dsolve({Tj_ode, y(x0)=y0}, numeric, parameters= [x0, y0]);

Note that the order in which I specified the parameters will be important later. Maple's cryptic response to the above command simply means everything is fine and the numeric colver has been constructed.

Get a 2D contour plot, choosing somewhat arbitrary ranges for x and y:

plots:-contourplot(
(Cspec:= (F(x,y):= lhs(C)), (x_rng:= x= -2..2), (y_rng:= y= -2..2))
);

The color bar shows the value of k for the level curve of the corresponding color.  The color bar clutters the final plot (IMO), so I remove it, and I add some additional k values to fill in the center. Suitable values of k can be guessed by mosuing over the above plot (clickiing on any level curve shows its k value).

Cplot:= plots:-contourplot(
(Cspec:= Cspec, 'contours'= [seq(-0.4..-2, -0.4), seq(-3..-15, -2)]),
'colorbar'= false, thickness= 0.7
);

Even without the color bar, clicking on level curves still shows their k values.

A 3D-plot will help with understanding what a "steepest path" means:

surf_plot:= plot3d(Cspec, 'style'= 'surfacecontour', 'transparency'= 0.3);

Make up any two starting points (there's no limit on how many points you use), and record the count of them for convenience:

Pts:= [[-1, 1/2], [1, -1]]:
npts:= nops(Pts);

Plot the orthogonal trajectories in the coordinate plane:

plots:-display(  #command to merge plots
Cplot,
(
#Iterate over Pts, setting P= [x0, y0] and setting j to the numeric
#position of P in Pts:
for j,P in Pts do
Tj_sol('parameters'= P);  #Reset 'parameters' for each point.
plots:-odeplot(  #plotter for numeric dsolve solutions
Tj_sol, [x,y(x)], x_rng,
'thickness'= 3, 'linestyle'= 'dash',
#Use pure chromatic colors ("HUEs") evenly spaced on the
#visible spectrum:
'color'= 'COLOR'('HUE', 0.86*(j-1)/npts),
'legend'= 'typeset'(
``(x[0],y[0]) = P[],
#Punctuate _between_ legends, but not at end:
`if`(j<npts, ";   ", "")
)
)
od
),
'view'= rhs~([x_rng, y_rng]),
#Scale so that right-angle intersections display "true":
'scaling'= 'constrained',
'title'= 'typeset'(
"Level curves of ", F(x,y), "and some orthogonal trajectories"
),
'titlefont'= ['TIMES', 'BOLD', 16],
'caption'= "trajectories for starting points",
'captionfont'= ['TIMES', 14],
'size'= [800\$2]  #800x800 pixels
);

By doing essentially the same thing, we can plot the corresponding "steepest-descent paths" on the surface

plots:-display(
surf_plot,
(
for j,P in Pts do
Tj_sol('parameters'= P);
plots:-odeplot(
Tj_sol, [x,y(x),F(x,y(x))], x_rng,
'thickness'= 2, 'color'= 'COLOR'('HUE', 0.86*(j-1)/npts)
)
od
),
'view'= [rhs~([x_rng, y_rng])[], -16..0]
);

 >

## Environment variables; kernelopts(level)...

printlevel is an "environment variable". That means that if its value is changed within a procedure, then it is automatically reset to its previous value when the procedure exits. Thus, you don't need to store the previous value or reset printlevel yourself.

What you're calling the "depth" can be measured by kernelopts(level).

## Limitations of assuming...

I ignore your weird use of RETURN. Without it, the second integral gives true*x, whereas I'd expect false*x. There are reasonable limitations on the "depth" within an expression to which assuming can penetrate. Compare:

(coulditbe(y=1) assuming y>=0, y<=x) assuming additionally, x>0, x<1;

true

coulditbe(y=1) assuming y>=0, y<=x, x>0, x<1;

false

The first case seems more akin to your integral.

## ListTools:-Classify...

Your graph_list can be partitioned into a table of equivalence classes under isomorphism by

ListTools:-Classify(g-> [seq](op(4, GraphTheory:-CanonicalGraph(g))), graph_list)

## unapply...

Define the function with unapply:

f:= unapply(a*x, x)

A synonym for unapply is MakeFunction.

## Extra spaces in 2d input...

I assume that you're using 2D Input which you've converted to 1D for posting here. If so, then you need to remove any space characters you have after displaytextplot, and draw. Also, the arguments to display need to be in parentheses. If I change your display command to

```display(
textplot(
[
[coordinates(S)[], "S"], [coordinates(P)[], "P"], [coordinates(H)[], "H"],
[coordinates(K)[], "K"], [coordinates(M)[], "M"]
], font = [times, bold, 16], align = [above, right]
),
draw([
delta(color = blue), deltap(color = blue), D(color = red), c1(color = black),
S(color = black, symbol = solidcircle, symbolsize = 16),
P(color = black, symbol = solidcircle, symbolsize = 16)
]),
scaling = constrained, axes = none, view = [-15 .. 15, -15 .. 15]
);```

then I get this plot (for which you'll likely want to change some of the sizes):

 1 2 3 4 5 6 7 Last Page 2 of 385
﻿