acer

33156 Reputation

29 Badges

20 years, 192 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are replies submitted by acer

This is a correction for the earlier typo. I tried to give the two black-box procedure more pertinent names.

bbox_ex2b.mw

Note that you still haven't actually attached a worksheet file for you latest followup query. So we cannot tell what you mean about units, or what you ment by your references like  `V__!3` etc.

When you upload a .mw file here, using the green uparrow in its editor, you also have to attach it or (better, here) insert a link to it. Those are choices in the pop-up that appears when you upload via the arrow.

@elemental cinder Sorry, if I typo'd.

The ranges passed to help fsolve might need adjustment, on account of that. Or, try looking at the implicitplot to get hints on ranges.

And you should try fsolve rather than solve, since the expressions are not explicit. (ie. a purely numeric solving)

[making dinner for the family right now. I'll revisit in a few hours I hope.]

@Ronan I'm glad that you're able to make some progress.

Soneone changed one of my Replies into an Answer. I have changed it back, to keep the original sequence of posting in their original order (because they logically and textually follow each other.

@Ronan Did you try my suggestion, after adjusting for your typo?

How is the following not doing what your last Comment mentioned? (This is essentially the same as in my previous Reply, but now there is RT:- instead of TN:- )

2026-03-27_Q_Module_Generic_Variables_R1_acc2.mw

 

ps. You just wrote, in a followup Comment, "One other question the arises from this....", with an additional query. But the additional query doesn't seem (to me) so much something revealed in part of the reposnses; it seems more a related (but quite distinct) thing on writing code&modules. Could you not ask all your relevant queries when you first post your Question?

@Ronan My followup point is that you might well want to programatically query current settings (so as to use the results in some test or manipulation). Here's a shot at that.

Note the latter examples, illustrating that you can both set and query values. It's done now to query values after doing the setting, but you could change the order.

I'm not sure if you mean that you want the modules source code to contain TM (literally), and then to be able to utilize it as RationalTrigonometry. Here's something on that too. (If you actually were to keep your source code in plaintext files -- which some people always do for serious projects, and then read them in -- then you could use $define macros.

restart;

kernelopts(version);

`Maple 2026.0, X86 64 LINUX, Mar 05 2026, Build ID 2001916`

use TM=RationalTrigonometry in
TM := module()
  export Cartline,Parmline,Settings;
  local Cartvars:=[:-x,:-y,:-z],Parmvars:=[:-alpha,:-beta,:-rho],
        GeomClr:="Blue",Prntmsg:=true;

  Settings := proc({Cartvars::list:=TM:-Cartvars},{Parmvars::list:=TM:-Parmvars},
                   {GeomClr::string:=TM:-GeomClr},{info::boolean:=TM:-Prntmsg},
                   other::list(identical(:-Cartvars,:-Parmvars,:-info,:-GeomClr)):=[], $)
    (TM:-Cartvars,TM:-Parmvars,TM:-GeomClr,TM:-Prntmsg):=Cartvars,Parmvars,GeomClr,info;
    if _npassed = 0 then
      print("Cartvars ",TM:-Cartvars); print("Parmvars ",TM:-Parmvars);
      print("GeomClr ",TM:-GeomClr); print("Prntmsg ",TM:-Prntmsg);
    end if;
    if other = [] then return NULL;
    else return map[2](`?[]`,TM,`[]`~(subs(:-info=':-Prntmsg',other)));
    end if;
  end proc;

  Cartline := proc(p1::list,p2::list,{vars::list:=TM:-Cartvars},Prntmsg:=TM:-Prntmsg)
    local l:= (p2[2]-p1[2])*vars[1]+(p1[1]-p2[1])*vars[2]
              -p2[2]*p1[1]+p1[2]*p2[1];
    if Prntmsg then print("Cartesian line format"); end if;
    return l;
  end proc;

  Parmline := proc(p1::list,p2::list,{varp:=TM:-Parmvars},Prntmsg:=TM:-Prntmsg)
    local l:= p1+~varp[1]*<p2-p1>;
    if Prntmsg then print("Parametric line format"); end if;
    return l;
  end proc;
end module:
end use;

_m132392360999968

 

RationalTrigonometry:-Cartline([4,3],[-8,4]);

"Cartesian line format"

x+12*y-40

RationalTrigonometry:-Cartline([4,3],[-8,4],vars=[s,t],false);

s+12*t-40

RationalTrigonometry:-Parmline([4,3],[-8,4]);

"Parametric line format"

Vector[column](%id = 36893620539784520636)

RationalTrigonometry:-Parmline([4,3],[-8,4],varp=[Lambda]);

"Parametric line format"

Vector[column](%id = 36893620539784523036)

RationalTrigonometry:-Settings();

"Cartvars ", [x, y, z]

"Parmvars ", [alpha, beta, rho]

"GeomClr ", "Blue"

"Prntmsg ", true

RationalTrigonometry:-Settings(Cartvars=[X,Y,Z],info=false);

RationalTrigonometry:-Settings()

"Cartvars ", [X, Y, Z]

"Parmvars ", [alpha, beta, rho]

"GeomClr ", "Blue"

"Prntmsg ", false

RationalTrigonometry:-Cartline([4,3],[-8,4]);

X+12*Y-40

RationalTrigonometry:-Cartline([4,3],[-8,4],true);

"Cartesian line format"

X+12*Y-40

RationalTrigonometry:-Settings(Parmvars=[varkappa,vartheta,sigma],info=true,Cartvars=[A,B,C])

RationalTrigonometry:-Settings();

"Cartvars ", [A, B, C]

"Parmvars ", [varkappa, vartheta, sigma]

"GeomClr ", "Blue"

"Prntmsg ", true

RationalTrigonometry:-Settings([Cartvars, info, Parmvars]);

[[A, B, C], true, [varkappa, vartheta, sigma]]

RationalTrigonometry:-Settings([Cartvars, GeomClr],
             info=false, Parmvars=[f,g,h]);

[[A, B, C], "Blue"]

RationalTrigonometry:-Settings();

"Cartvars ", [A, B, C]

"Parmvars ", [f, g, h]

"GeomClr ", "Blue"

"Prntmsg ", false

Download 2026-03-27_Q_Module_Generic_Variables_R1_acc.mw

@Ronan For your interest: without dummy parameters, multiple overloads, etc. I'd suggest that this is simpler in structure, and in use.

(nb. sometimes this site displays some Maple 2026.0 outputs as [?], though they can be fine in actual Maple.)

restart;

kernelopts(version);

`Maple 2026.0, X86 64 LINUX, Mar 05 2026, Build ID 2001916`

TM := module()
  export Cartline,Parmline,Settings;
  local Cartvars,Parmvars,GeomClr,Prntmsg;
  Cartvars := [:-x,:-y,:-z];  
  Parmvars := [:-alpha,:-beta,:-rho];
  GeomClr := "Blue";
  Prntmsg := true;

  Settings := proc({Cartvars::list:=TM:-Cartvars},{Parmvars::list:=TM:-Parmvars},
                   {GeomClr::string:=TM:-GeomClr},{info::boolean:=TM:-Prntmsg}, $)
    TM:-Cartvars:=Cartvars;
    TM:-Parmvars:=Parmvars;
    TM:-GeomClr:=GeomClr;
    TM:-Prntmsg:=info;
    if _npassed = 0 then
      print("Cartvars ",TM:-Cartvars);
      print("Parmvars ",TM:-Parmvars);
      print("GeomClr ",TM:-GeomClr);
      print("Prntmsg ",TM:-Prntmsg);
    end if;
    return NULL
  end proc;

  Cartline := proc(p1::list,p2::list,{vars::list:=TM:-Cartvars},Prntmsg:=TM:-Prntmsg)
    local l;
    l := (p2[2]-p1[2])*vars[1]+(p1[1]-p2[1])*vars[2]
         -p2[2]*p1[1]+p1[2]*p2[1];
    if Prntmsg then print("Cartesian line format"); end if;
    return l;
  end proc;

  Parmline := proc(p1::list,p2::list,{varp:=TM:-Parmvars},Prntmsg:=TM:-Prntmsg)
    local l;
    l := p1+~varp[1]*<p2-p1>;
    if Prntmsg then print("Parametric line format"); end if;
    return l;
  end proc;
end module:

 

TM:-Cartline([4,3],[-8,4]);

"Cartesian line format"

x+12*y-40

TM:-Cartline([4,3],[-8,4],vars=[s,t],false);

s+12*t-40

TM:-Parmline([4,3],[-8,4]);

"Parametric line format"

Vector[column](%id = 36893622109376958940)

TM:-Parmline([4,3],[-8,4],varp=[Lambda]);

"Parametric line format"

Vector[column](%id = 36893622109376961340)

TM:-Settings();

"Cartvars ", [x, y, z]

"Parmvars ", [alpha, beta, rho]

"GeomClr ", "Blue"

"Prntmsg ", true

TM:-Settings(Cartvars=[X,Y,Z],info=false);

TM:-Settings()

"Cartvars ", [X, Y, Z]

"Parmvars ", [alpha, beta, rho]

"GeomClr ", "Blue"

"Prntmsg ", false

TM:-Cartline([4,3],[-8,4]);

X+12*Y-40

TM:-Cartline([4,3],[-8,4],true);

"Cartesian line format"

X+12*Y-40

TM:-Settings(Parmvars=[varkappa,vartheta,sigma],info=true,Cartvars=[A,B,C])

TM:-Settings();

"Cartvars ", [A, B, C]

"Parmvars ", [varkappa, vartheta, sigma]

"GeomClr ", "Blue"

"Prntmsg ", true

 

Download 2026-03-27_Q_Module_Generic_Variables_R1_ac.mw

ps. Another finesse that might be programatically useful is the functionality where Settings could also accept one or more of the relevant locals (just as a list of names, say, or as strings) and return their current values. Let me know if you'd be interested; it's just another adjument, I think.

pps. I'm not sure if it's your style, but some of the adjacent lines in the code could be rolled into so-called multiple-assignment. Eg,
   (a,b,c):=A,B,C;
rather than,
    a:=A;
    b:=B;
    c:=C;

@dharr That is interesting. It might be "fun" to discover or prove which patterns of values of the assumed parameters lead to actual solutions.

I see that the following form can be obtained in Maple 2026.0 if using environment variable _EnvAllSolutions rather than the allsolutions option of solve. (That's a bit weird, and I ought to check whether it happens for other kinds of equations...)

[edited: I used a different equation, now corrected]

restart;

kernelopts(version);

`Maple 2026.0, X86 64 LINUX, Mar 05 2026, Build ID 2001916`

ee := x^Pi=Pi^x;

x^Pi = Pi^x

solve(ee,x,allsolutions);

-Pi*LambertW(-ln(Pi)/Pi)/ln(Pi), Pi

_EnvAllSolutions := true:

S := solve(ee,x);

exp(-LambertW(_Z3, -(ln(Pi)+(2*I)*Pi*_Z4)*exp(-(2*I)*_Z1)/Pi)-(2*I)*_Z1)

V := indets(S,suffixed(_Z)):

map(getassumptions,V);

{{_Z1::integer}, {_Z3::integer}, {_Z4::integer}}

Download s_ex2.mw

@Ronan It's a pity you didn't show or explain what you actually wanted to accomplish when you first posted your Question.

I think that declaring variables `global` like that is not great programming.

You could achieve the same behavior by merely adding to my example's module a new export procedure which reassigns values to the module locals Cartvars and Parmvars. That's a rather usual approach.

ps. Some benefit of modules is encapsulation, and protection of the global name-space.

@dharr In Maple 2026.0 one could just,

   convert(simplify(expr), cosh)

as there the result of simplify(expr) is  1/4*sech(1/2*u)^2  . That's also the case for the OP's other original expression, exp(u)/(1+exp(u))^2 .

 

note: In Maple 2024.2, as opposed to taking reciprocals, one could get to  1/(2*cosh(u)+2) by simplify(combine(expr)) .

@Alfred_F The first step below (with the reciprocal) speaks to another weakness in simplify. One might reasonable hope that simplify(expr) would do that directly.

restart

kernelopts(version)

`Maple 2024.2, X86 64 LINUX, Oct 29 2024, Build ID 1872373`

expr := (cosh(u)+sinh(u))/(1+cosh(u)+sinh(u))^2

(cosh(u)+sinh(u))/(1+cosh(u)+sinh(u))^2

alt := 1/simplify(1/expr)

1/(2*cosh(u)+2)

R1 := sinh((1/2)*u)^2 = trigsubs(sinh((1/2)*u)^2, trigidentity = "Pythagoras")[1]

sinh((1/2)*u)^2 = cosh((1/2)*u)^2-1

R2 := cosh(u) = trigsubs(cosh(u), trigidentity = "Double Angle")[1]

cosh(u) = cosh((1/2)*u)^2+sinh((1/2)*u)^2

simplify(alt, {R1, R2})

(1/4)/cosh((1/2)*u)^2

 

 

Download test2_ac.mw

@Rouben Rostamian  I could add that the redraw=false option could also be added to (just) the plots:-display call. Although the plots:-display might occur in some code not written by you, in which case adding it to the plot call could serve.

Btw, the fact that additional curves (when merged) may redrawn with different colors is mentioned in the plots:-display Help-page, and also noted on the Maple 2022 compatibility page. But it seems (to me) to indicate that one might supply redraw=false to plots:-display only, rather than (alternatively) to plot itself.

nb. coords=elliptic (or other) doesn't have a corresponding setting for the axiscoordinates option. But your issue occurs for that too.

A milder effect can occur when some reduced domain determination occurs in the individual plots. Eg,

p1:=plot(5^x,x=0..20):
p2:=plot(6^x,x=0..20):
plots:-display(p1,p2)
plots:-display(p1,p2,redraw=false)

I added all this as notes in the report.

It works ok in Maple 2021, but not in Maple 2022-2026.0, it seems.

Of course, the behavior you've shown is wrong. It's supposed to automatically combine the x-ranges into the larger union.

The bug shows up with that use of the coords=polar. Without that the x-ranges are combined as expected, without needing to supply a view.

I can submit a bug report against what appears to be a regression.

By the way, if you don't want to specify explicitly the y-range in the passed view then you could pass the option as,

     view=[-2..2,default]

in which case it will inherit. I write that just to correct the 3rd bullet point, apparently from AI, in nm's Reply.

And if the AI also claims that the view option is needed in such examples then it'd be confused about that too.

note also:

eval( tan(x)-sec(x), x=Pi/2 );
Error, (in tan) numeric exception: division by zero

limit( tan(x)-sec(x), x=Pi/2 );

           0

@C_R 

Btw, while I used value for most of the example checks, I threw in one with a call to simplify instead, to illustrate its effect.

I'm a bit on the fence about whether it's mostly a good thing that this next example returns zero.

    simplify( sqrt(2) - %sqrt(2) )

Also, the following will return 2*3^(1/2)

   simplify( %sqrt(12) )

So I'm not sure what gemini means by its claim that "Simplification" is "Blocked". It doesn't seem to be a claim about "Evaluation", which has a separate line in what you showed. Perhaps it's just some sort of claim about immediate arithmetic cancellation (though, logically, that seems just a consequence about lack of immediate evaluation).

ps. evala and radnormal seem to leave %sqrt alone. And they can do a kind of simplification.

@C_R That's really interesting.

Except for perhaps one minor spot ( about explanation of [op(u)] vs [u] ) it seems like an accurate explanation, broken into steps properly. Up until the point that it misinterprets %sqrt, of course.

I wonder how it might ever learn that %sqrt is an inert form.

The explanation made a weakness apparent to me: the denominator of the content might not be numeric.

M := 1/(11*Q(sqrt(5)));

    1/11/Q(5^(1/2))

C := content(M);

    1/11/Q(5^(1/2))

irem(C, 11);

   irem(1/11/Q(5^(1/2)),11)

rem(C, 11, ':-__x');

         0

And so I tentatively offer a revision that also handles this additional example:

G:=proc(ee,k::posint:=2)
    subsindets(ee,`*`,
               u->`if`(rem(denom(content(u)),k,':-__x')=0 and
                       member(sqrt(k),[(uu->`if`(uu::`*`,op(uu),uu))(numer(content(u)))]),
                       u*sqrt(k)/%sqrt(k),u));
end proc:

 

-13/7/(sqrt(11)*sqrt(5))*(x+a);
G( %, 5 );
G( %, 11 );
simplify(% - %%%);

-(13/385)*11^(1/2)*5^(1/2)*(x+a)

-(13/77)*11^(1/2)*(x+a)/%sqrt(5)

-(13/7)*(x+a)/(%sqrt(5)*%sqrt(11))

0

Download unrat02b.mw

This is a benefit of trying to concoct "unit test" examples, and trying to find examples that "break" your code.

ps. There is some dodginess to using rem here. But I haven't thought of the fatal counterexample yet. ;)  And I know that I can't just handle the numerator the same way (tempting as may be).

1 2 3 4 5 6 7 Last Page 2 of 607