29498 Reputation

29 Badges

18 years, 146 days
Ontario, Canada

Social Networks and Content at

MaplePrimes Activity

These are replies submitted by acer

Is this the system that you want solved?



`Maple 2023.2, X86 64 LINUX, Nov 24 2023, Build ID 1762575`

eqn__0 := cos(x)*cos(y)*cos(x + y)
          = 2*(sin(x)*sin(y) - 1)*2*(sin(x)*sin(x + y) - 1)
            *2*(sin(y)*sin(x + y) - 1);

cos(x)*cos(y)*cos(x+y) = 8*(sin(x)*sin(y)-1)*(sin(x)*sin(x+y)-1)*(sin(y)*sin(x+y)-1)

eqn__1 := (cos(x + y) - (cos(x) + cos(y)) + 1)**2
          + 2*cos(x)*cos(y)*cos(x + y) = 0;

(cos(x+y)-cos(x)-cos(y)+1)^2+2*cos(x)*cos(y)*cos(x+y) = 0

solve({eqn__0, eqn__1, x+y>=0, x<=Pi, y<=Pi}, real);

{x = 0, y = (1/2)*Pi}, {x = (1/2)*Pi, y = 0}, {x = (1/2)*Pi, y = (1/2)*Pi}, {x = (1/3)*Pi, y = (1/3)*Pi}


@Carl Love Is a bug report submitted? If not, I could do so.

@KIRAN SAJJAN As you can see in the following attachment, this worked for me when I ran it in Maple 2018.2. That file has the system with f1(eta), but no f(eta).

So that handles your first file, as far as I can see. It makes a sequence of 3D contour plots, since that's what you earlier attempt clearly attempted to do. If you want some other style of 3D plot then adjust the style option, or state clearly what else you're after.

Your second file,, makes use of a procedure written I believe by Carl Love. It's going wrong when its ParamPlot3d procedure computes its L and U values as Float(undefined).

[edit] I have adjusted for that by changing the relevant min,max calls to min[defined] & max[defined].

@Carl Love I wonder if a rationale is that RootOf always turns its bound name into _Z.

RootOf(x - exp(x));

        RootOf(_Z - exp(_Z))

RootOf(_Z2 - exp(_Z2));

         RootOf(_Z - exp(_Z))

Hence querying indets(...,RootOf) provides any information and programmatic control that one would otherwise get if indets(...,name) were to return the _Z in use in some RootOf.

But for those other constructs, arbitrary names can be used. And so there's justification in saying that indets(...,name) should be able to query for them programmatically.

Where exactly is the piece of paper in your scenario?

It might be that the OP could get by with discerning whether the expression depends on the suffixed variables found.


r := discont(1/tan(x),x);

{Pi*_Z2, (1/2)*Pi+Pi*_Z1}

indets( r, And( suffixed('_'),
                satisfies(u->depends(r,u)) ) );

{_Z1, _Z2}

f := -(8*x*y^(5/3)+y)/x/(2*x*y^(2/3)-1):
L := discont(evalc(f),x);

{0, RootOf(4*abs(y)^(4/3)*_Z^2-4*_Z*abs(y)^(2/3)*cos((1/3)*(-1+signum(y))*Pi)+1)}

indets( L, And( suffixed('_'),
                satisfies(u->depends(L,u)) ) );



And if one does not prefer type `satisfies` then the type `suffixed` result could be sieved for `depends` by using `select`.

@NIMA112 In your latest worksheet it seems that phi[1] = 2*phi[2] along x=0. That would explain why the contours would not match there, since here phi[1] <> phi[2].

You could adjust by a factor of two, as in this attachment.

Also, sometimes you might get a contour mismatch when the close surfaces are quite flat near a specific contour. In that case you could omit the problem contour (or possibly? increase working precision Digits enough to get the needed accuracy) to avoid the appparent mistmatch. In one of your examples in this sheet it seems to suffice to use an even number of contours, thus avoiding having a contour in the (problematic) very middle of the range.

@sursumCorda That difference (in whether the second argument to solve is a set) is a very useful controller. There have been previous Questions involving simplification of relations in which it was the key element. 

And with the result being a set of relations, one could be very slightly terser here:

     `and`(solve(r1 or r2,{x})[])

For fun, one could also handle the equivalent RealRange's using OrProp, instead of throwing it all to solve.

In general I might first turn the active and into inert And, to reduce the risk of inadvertant evaluation to true/false, etc. 

r1 := -1 <= x and x <= 0;

-1 <= x and x <= 0

r2 := 0 <= x and x <= 1;

0 <= x and x <= 1

S := subsindets({r1,r2},`and`,And@op);

{And(-1 <= x, x <= 0), And(0 <= x, x <= 1)}

convert(x::OrProp( rhs~(convert(S,RealRange))[]),
        relation );

And(-1 <= x, x <= 1)


Did it work as described, for anyone interested?

I have corrected the "Product", from Maple 2018 to Maple 18 in which your attachment was last saved.

Those two versions are different, released in different years.

(No need to respond. I know that you are using Maple 18.)

@C_R The evalf inside F is not actually required there. The commands plot, Maximize, and fsolve will evalf themselves.

You also asked why the following did not work (without substitution y=Y, or :-y=y if you use lowercase y as the name of the parameter of F).

F := y->evalf(Int(unapply(op(1,ig),x),rhs(op(2,ig))));

The y that is the parameter of procedure F is not the same as the global name y already present in op(1,ig).

Even the first of these next two examples has two different "y" names in play.

expr := sin(y*x):

f := y -> expr:



g := y -> unapply(expr,x):


proc (x) options operator, arrow; sin(y*x) end proc

The command unapply exists to make it easier to build procedures from given expressions.

In the variants under discussion, I was building a procedure that returns an Int call containing a procedure (as integrand). And the original form of the integrand is a given existing expression.

Building procedures that return procedures (ie. a "procedure factory"), substituting for different variables at each level, is pretty awkward without unapply.

The first pair of these look understandable. But that last one, lacking all unapply, is more klunky. Without any unapply, things can be even klunkier if you want the procedure factory to contain literal sin(x*y) instead of the reference name expr.

expr := sin(x*y):

G1 := Y -> unapply(eval(expr,y=Y),x):


proc (x) options operator, arrow; sin(2*x) end proc


G2 := Y -> subs(y=Y, unapply(expr,x)):


proc (x) options operator, arrow; sin(2*x) end proc


G3 := unapply('unapply(eval(expr,y=Y),x)',Y):


proc (x) options operator, arrow; sin(2*x) end proc


G4 := YY -> subs(Y=YY, X->eval(expr,[x=X,y=Y])):


proc (X) options operator, arrow; eval(expr, [x = X, y = 2]) end proc


A variant on G2 above:

expr := sin(x*y):

template := unapply(expr,x):

G2b := Y -> subs(y=Y, eval(template)):


proc (x) options operator, arrow; sin(2*x) end proc



@sand15 That procedure F uses unapply to get an operator form for the integrand.

The result of
  unapply(expression_in_x, x)
is an operator (procedure).  As such, it no longer has a direct dependency on the name x in particular, or on any other name.

And so those commands like Int, fsolve, plot, etc, would take a mere range as second argument, as opposed to how they'd take name=range to accompany an expression.

In the case of Int, the numeric integration is done with respect to the arguments that will be passed to the operator-form integrand. In the case of fsolve, the root-finding is done with respect to that. Etc.

Forgive me if the following is too long-winded. (It's the kind of thing I'd put early in a book on Maple, if I were to write one.) You might well already know all this.



For expressions, the following commands take a second
argument in the form      name = range

That's consistent behavior, between the following commands.

expression := x^3 - 1/2;


evalf( Int( expression, x = 0 .. 1 ) );


plot( expression, x = 0 .. 1 );

fsolve( expression, x = 0 .. 1 );


Optimization:-Minimize( expression, x = 0 .. 1 );

[HFloat(-0.49999999999999994), [x = HFloat(3.4847423234192726e-6)]]


For operators/procedures, the following commands take a second
argument in the form      range

There is no particular "variable" connected to the operator, at a
level outside it.

This is the case whether the body of the operator is written out
manually, or formed using unapply.

That's consistent behavior, between the following commands.


p1 := x -> x^3 - 1/2 ;

proc (x) options operator, arrow; x^3-1/2 end proc

evalf( Int( p1, 0 .. 1 ) );


plot( p1, 0 .. 1 );

fsolve( p1, 0 .. 1 );


Optimization:-Minimize( p1, 0 .. 1 );

[-.49999999999999994, Vector(1, {(1) = 0.34847423234192726e-5})]

p2 := unapply(expression, x);

proc (x) options operator, arrow; x^3-1/2 end proc

plot( p2, 0 .. 1 );

evalf( Int( p2, 0 .. 1 ) );


fsolve( p2, 0 .. 1 );


Optimization:-Minimize( p2, 0 .. 1 );

[-.49999999999999994, Vector(1, {(1) = 0.34847423234192726e-5})]

You could call an operator using any(!) name you want.

The following uses an unevaluated function-call, which is
treated like an expression. Hence the following commands
take the second argument in the form   name = range

The name beside the range matches the name used in the
unevaluated function-call. Below, I use s.

evalf( Int( 'p2(s)', s = 0 .. 1 ) );


plot( 'p2(s)', s = 0 .. 1 );

fsolve( 'p2(s)', s = 0 .. 1 );


Optimization:-Minimize( 'p2(s)', s = 0 .. 1 );

[HFloat(-0.49999999999999994), [s = HFloat(3.4847423234192726e-6)]]


By using the option numeric with the unapply command
the resulting function call like  p3(s) can be more easily used,

without unevaluation quotes.

That makes it safer/easier to treat p3(s) like an expression,
because it stays unevaluated unless s is replaced by a something numeric.










p3 := unapply(expression, x, numeric):





eval(p3(s), s=0.5);




@Hullzie16 The optionsimplicit=[gridrefine=1] gets passed by plots:-inequal to plots:-implicitplot (which the former uses, internally). You could experiment with other implicitplot options there, to get a better resolution in the inequal plot. (That can make it take longer, say.)

The various digits, epsilon, and method options are used in the Int calls. Those get passed to the numeric integrator when those Int calls get evalf'd. Here it's tricky because you have nested Int calls.

In such situations the inner numeric integration often needs a more accurate result (smaller epsilon) to that the outer numeric integration can get its convergence for each evaluation of its own, outer integration.

The plotting command (or implicitplot) may be able to handle a coarser epsilon for the outer integration, which may make that faster. That may also be necessary to get the outer integration to converge (for the various values of the plotting variables).

Balancing all that, and the methods, can be tricky. Unfortunate choices may make it take a very long time, or not work at all.

@NIMA112 This is not super fast, and some computational effort is duplicated.

But it allows you to find the ranges for h[1] and h[2], and then merge them into a common range from which shared contour values may be constructed.

4 5 6 7 8 9 10 Last Page 6 of 542