nm - Questions - MaplePrimes

What can cause Physics to be activated w...

Asked: nm 11643 Product: Maple 2025

November 24 2025

0 0

In 2025.2, I found that calling Physics:-Setup causes code of `convert/diff` to change (on the fly) causing error.

I removed from my code the places I was calling Physics:-Setup explicitly, but the error still shows up. Which means there is still places in the code to cause Physics to come into play.

I just installed 2025.2 and have not done anything yet. Just running a test.

Does one need to install Physics package?

First, let me give an example showing that calling Physics:-Setup changes `convert/diff` which ends up causing an internal Maple error

>	interface(version);

>	SupportTools:-Version();

>	Physics:-Version();

>

restart;

Original result. No problem

>	print(`convert/diff`);

$proc (a, { useeval::truefalse := false }) local ee, zD; ee := `PDEtools/usediff`(a); zD := indets(ee, 'And(function, satisfies(proc (f) options operator, arrow; (op(0, f))::`PDEtools/D/structure` end proc))'); if zD = {} then ee else _Env_t_in_use := `tools/get_symbols`(a); if useeval then zD := map(`convert/diff/D_to_eval@diff`, zD, ':-useEval'); zD := map(proc (u) options operator, arrow; lhs(u) = subsop(0 = eval, rhs(u)) end proc, zD); subs(zD, ee) else subs(map(`convert/diff/D_to_eval@diff`, zD), a) end if end if end proc$

>	T:=D(x)(infinity):

>	PDEtools:-difforder(convert(T,diff))

After call Physics:-Setup

>

restart;

>	Physics:-Setup('assumingusesAssume' = false):

>	print(`convert/diff`);

proc () local ans; ans := usepdiff(args); if has([ans], 'D') then ans := Physics:-OriginalValue["convert/diff"](ans, args[2 .. -1]) end if; ans end proc

>	T:=D(x)(infinity):

>	PDEtools:-difforder(convert(T,diff))

Error, (in unknown) invalid input: diff received infinity, which is not valid for its 2nd argument

Download why_code_changes_calling_Physics_maple_2025_2_nov_24_2025.mw

Notice that now calling PDEtools:-difforder(convert(T,diff)) fail because Physics:- was called.

But my code now has no calls to Physics:-, I made sure to comment all those out.

But I still get same error when I run my test program. Not able to find where Physics is "activated" again to cause the code change in `convert/diff` that happens dynamically when Physics is loaded.

It must be happining on different call internally. But have no idea why and where.

This is all on new PC. I have no Maple ini files or anything like this that can cause this.

Will installing Physics package explicity fixes this?

Update

I think I know why this happens. Not all fixes made by Edgardo S. Cheb-Terrab in last Physics update are included in Maple 2025.2 !

See https://mapleprimes.com/questions/240843-Why-PDEtoolsSolve-Fail-On-This-Equation where fix is made in Physics v.1880 which I confirmed in Maple 2025.1.

But now I checked and this problem is back in Maple 2025.2. which means that fix was not merged into Maple 2025.2. How could this happen?

Download fixed_in_2025_1_but_missing_in_2025_2.mw

So I am hoping that figuring how to install Physics update in Maple 2025.2 will fix the current problem with convert and also bring that old fix for PDEtools:-Solve back into Maple 2025.2.

This is something that Maplesoft should have taken care of.

Update

Figured how install Physics update package V 1881 and doing so fixed this problem in Maple 2025.2 !

This tells me that all fixes that were in Physics update package were not merged into Maple 2025.2

This worksheet shows that now code works OK, but need to make sure to install Physics update package in Maple 2025.2

>	interface(version);

>	SupportTools:-Version();

>	Physics:-Version();

>

restart;

Original result. No problem

>	print(`convert/diff`);

$proc (a, { useeval::truefalse := false }) local ee, zD; ee := `PDEtools/usediff`(a); zD := indets(ee, 'And(function, satisfies(proc (f) options operator, arrow; (op(0, f))::`PDEtools/D/structure` end proc))'); if zD = {} then ee else _Env_t_in_use := `tools/get_symbols`(a); if useeval then zD := map(`convert/diff/D_to_eval@diff`, zD, ':-useEval'); zD := map(proc (u) options operator, arrow; lhs(u) = subsop(0 = eval, rhs(u)) end proc, zD); subs(zD, ee) else subs(map(`convert/diff/D_to_eval@diff`, zD), a) end if end if end proc$

>	T:=D(x)(infinity):

>	PDEtools:-difforder(convert(T,diff))

>

After call Physics:-Setup. now works OK since Physics update is installed

>

restart;

>	Physics:-Setup('assumingusesAssume' = false):

>	print(`convert/diff`);

proc () local ans; ans := usepdiff(args); if has([ans], 'D') then ans := Physics:-OriginalValue["convert/diff"](ans, args[2 .. -1]) end if; ans end proc

>	T:=D(x)(infinity):

>	PDEtools:-difforder(convert(T,diff))

>

Download why_code_changes_calling_Physics_maple_2025_2_nov_24_2025_V2.mw

why overload always calls the first proc...

Asked: nm 11643 Product: Maple 2025

November 01 2025

1 1

I am finding many problems using overload in OOP.

But for starter, here is a basic one that does not use Object. Will make separate question for other issues once I figure this basic one out.

I have overload with two procs.

First proc takes 2 arguments of type string, and the second proc one argument also of type string.

When calling the overloaded proc with one argument or two arguments, it always calls the first one which takes 2 arguments.

It never calls the second, even though the call is using one argument only. It always matchs the first proc.

It seems Maple just checks if the first argument match and stops.

I also made sure to use $ for end of arguments flag.

Now when changing the order and putting as the first proc the one that take one argument and the second proc which takes two arguments, now it works. Maple calls the correct proc based on the number of arguments.

How could this be possible? Is order of procs in overload important?? How does one then figure the correct order. It should be based on match of signature of proc, not the order. i.e. match made based on number and type of arguments.

Is there a way to make the first one work as is without having to worry about order? Or Am I making mistake somewhere?

>

restart;

>	interface(version);

>

restart;

>

set_name :=overload(
        [
            proc(first_name::string,last_name::string,$) option overload;
                print("in proc which takes two arguments");
            end,

            proc(the_name::string,$) option overload;
                 print("in proc which takes one argument");
            end
        ]
    ):

>	set_name("me"); #why this call the first proc and not the second?

>	set_name("me","joe");

>

restart;

>

#change order of procs in list
set_name :=overload(
        [
            proc(the_name::string,$) option overload;
                 print("in proc which takes one argument");
            end,

            proc(first_name::string,last_name::string,$) option overload;
                print("in proc which takes two arguments");
            end
        ]
    ):

>	set_name("me");

>	set_name("me","joe");

Download why_order_makes_differenence_in_overload_nov_1_2025.mw

why dsolve losses one solution when aske...

Asked: nm 11643 Product: Maple 2025

October 22 2025

1 0

Solving an ode, dsolve says it used exact method and gives two solutions as result (correct result).

But when asking dsolve to solve same ode but now specifying that it uses exact method (i.e. same one it used itself before), now it gives one solution only, not two as before.

Why is that? Should not both commands give same result? i.e. two solutions?

>	interface(version);

>	SupportTools:-Version()

>	Physics:-Version()

>

restart;

>	ode:=3y(x)^3x^2+y(x)^4+(3x^3y(x)^2+y(x)^4+4xy(x)^3)*diff(y(x),x) = 0; DEtools:-odeadvisor(ode); infolevel[dsolve]:=5:

>	sol:=dsolve(ode); #gives two solutions

Classification methods on request

Methods to be used are: [exact]

----------------------------

* Tackling ODE using method: exact

--- Trying classification methods ---

trying exact

<- exact successful

>	maple_sol:=dsolve(ode,[exact]); #why y=0 solution do not show here??

Classification methods on request

Methods to be used are: [exact]

----------------------------

* Tackling ODE using method: exact

--- Trying classification methods ---

trying exact

<- exact successful

>	sol:=dsolve(ode); #gives two solutions again

Classification methods on request

Methods to be used are: [exact]

----------------------------

* Tackling ODE using method: exact

--- Trying classification methods ---

trying exact

<- exact successful

Download why_different_solutions_maple_2025_1_oct_22_2025.mw

internal error from odetest, with _EnvAl...

Asked: nm 11643 Product: Maple 2025

October 21 2025

1 0

When solution was obtained using earlier call to solve with _EnvAllSolutions := true: set, then odetest givens internal error.

When _EnvAllSolutions := false: then no error.

Why? And is there a workaround so I can use _EnvAllSolutions := true: but have odetest still work?

>	interface(version);

>	Physics:-Version();

>	SupportTools:-Version();

>

Example fail when using _EnvAllSolutions := true:

>

restart;

>	kernelopts('assertlevel'=2):

>

ode:=diff(y(x),x) = ln(1+y(x)^2);
IC:=y(0)=0;
x0:=0;
sol:=y(x) = -sqrt(-1 + exp(RootOf(-Intat(-1/(2*tau*sqrt(-1 + exp(tau))*exp(-tau)), tau = _Z) + x + _C2)));

eq:=0=eval(rhs(sol),x=x0);
_EnvAllSolutions := true:
_EnvExplicit := true:
sol_C:=_C2=solve(eq,_C2);
sol:=eval(sol,sol_C);
odetest(%,[ode,IC])

y(x) = -(-1+exp(RootOf(-Intat(-(1/2)/(tau*(-1+exp(tau))^(1/2)*exp(-tau)), tau = _Z)+x+_C2)))^(1/2)

0 = -(-1+exp(RootOf(-Intat(-(1/2)/(tau*(-1+exp(tau))^(1/2)*exp(-tau)), tau = _Z)+_C2)))^(1/2)

_C2 = Intat(-(1/2)*exp(tau)/(tau*(-1+exp(tau))^(1/2)), tau = (2*I)*Pi*_Z1)

y(x) = -(-1+exp(RootOf(-Intat(-(1/2)/(tau*(-1+exp(tau))^(1/2)*exp(-tau)), tau = _Z)+x+Intat(-(1/2)*exp(tau)/(tau*(-1+exp(tau))^(1/2)), tau = (2*I)*Pi*_Z1))))^(1/2)

Error, (in series/csgn) assertion failed

>

Example Works when using _EnvAllSolutions := false:

>

restart;

>	kernelopts('assertlevel'=2):

>

ode:=diff(y(x),x) = ln(1+y(x)^2);
IC:=y(0)=0;
x0:=0;
sol:=y(x) = -sqrt(-1 + exp(RootOf(-Intat(-1/(2*tau*sqrt(-1 + exp(tau))*exp(-tau)), tau = _Z) + x + _C2)));

eq:=0=eval(rhs(sol),x=x0);
_EnvAllSolutions := false:
_EnvExplicit := true:
sol_C:=_C2=solve(eq,_C2);
sol:=eval(sol,sol_C);
odetest(%,[ode,IC])

y(x) = -(-1+exp(RootOf(-Intat(-(1/2)/(tau*(-1+exp(tau))^(1/2)*exp(-tau)), tau = _Z)+x+_C2)))^(1/2)

0 = -(-1+exp(RootOf(-Intat(-(1/2)/(tau*(-1+exp(tau))^(1/2)*exp(-tau)), tau = _Z)+_C2)))^(1/2)

_C2 = Intat(-(1/2)*exp(tau)/(tau*(-1+exp(tau))^(1/2)), tau = 0)

y(x) = -(-1+exp(RootOf(-Intat(-(1/2)/(tau*(-1+exp(tau))^(1/2)*exp(-tau)), tau = _Z)+x+Intat(-(1/2)*exp(tau)/(tau*(-1+exp(tau))^(1/2)), tau = 0))))^(1/2)

[RootOf(Intat(exp(tau)/(tau*(-1+exp(tau))^(1/2)), tau = _Z)+2*x-Intat(exp(tau)/(tau*(-1+exp(tau))^(1/2)), tau = 0))-ln(exp(RootOf(Intat(exp(tau)/(tau*(-1+exp(tau))^(1/2)), tau = _Z)+2*x-Intat(exp(tau)/(tau*(-1+exp(tau))^(1/2)), tau = 0)))), 0]

Download odetest_fail_when_using_envAllsol_maple_2025_1_oct_21_2025.mw

are c__1 and _C1 no longer same object i...

Asked: nm 11643 Product: Maple 2025

October 19 2025

2 0

The nice addition added to Maple 2022 in this post made it clear that c__1 and _C1 are the same under the cover.

But then why in Maple 2025.1 it does not give this?

I found this when I was trying to find constants of integrations in solution of an ode, and used

indets(sol,And(symbol, suffixed(_C, nonnegint)));

Which did not find the constants of integration, since I happened to have typed the solution using c__1 and not _C1, but I thought they are the same.

Did something change or I still dont understand well the difference between c__1 and _C1 ?

Worksheet below.

>	interface(version);

>	SupportTools:-Version();

>	Physics:-Version();

>

restart;

>	sol:= y(x)=-cos(x)/2+sin(x)/2+c__1*exp(-x); indets(sol,And(symbol, suffixed(_C, nonnegint)));

>	sol:= y(x)=-cos(x)/2+sin(x)/2+c__1*exp(-x); indets(sol,And(symbol, suffixed(c__, nonnegint)));

${c__1}$

>	sol:= y(x)=-cos(x)/2+sin(x)/2+_C1*exp(-x); indets(sol,And(symbol, suffixed(c__, nonnegint)));

>	sol:= y(x)=-cos(x)/2+sin(x)/2+_C1*exp(-x); indets(sol,And(symbol, suffixed(_C, nonnegint)));

${_C1}$

>	c__1 - _C1

>	addressof(c__1);

>	addressof(_C1);

Download why_c1_and_C1_not_same_oct_19_2025.mw

Update

Found out why. This only works if one calls dsolve() first. Here is an example

Download why_c1_and_C1_not_same_oct_19_2025_V1.mw

But this is really confusing. c__1 before calling dsolve is not the same as c__1 after calling dsolve.

It will be better if Maple is changed such that these work the same all the time without having to call dsolve() first.

E-Mail Address:
Password:
Remember Me:	Automatically sign in on future visits

E-Mail Address:
Password:
Remember Me:	Automatically sign in on future visits

Ask a Question

Create a Post

nm

11643 Reputation

20 Badges

MaplePrimes Activity

These are questions asked by nm

What can cause Physics to be activated w...

why overload always calls the first proc...

why dsolve losses one solution when aske...

internal error from odetest, with _EnvAl...

are c__1 and _C1 no longer same object i...

Save this setting as your default sorting preference?

Ask a Question

Create a Post

Generating PDF…

Save this setting as your default sorting preference?
Note: You can change your preference any time in your account settings
Don't show this again