nm - Questions - MaplePrimes

How to obtain the extent of the x and y ...

Asked: nm 9949 Product: Maple 2024

July 31 2024

1 0

When making this plot, using smart plot (i.e. not giving the plot command the x=from..to and also not giving it y=from...to

p:=plot(0,color=red);

I need to programatically find the x=-10..10 and y=-1..1 from the variable p. But if I do

rhs~(indets(p, identical("originalview")=anything));

it gives

{[-10. .. 10., 0. .. 0.]}

But clearly looking at the plot the y axis is from -1..1

The reason I need to determine the view from the above plot, is that I need to use same view windows size in another plot not using smart plot (phase plot) which requires one to provide explicit x and y ranges. i.e I'd like the phase plot to have same view size in terms of x range and y range.

I printed the PLOT structure but do not see another field to look at.

Any idea or trick to find y=-1..1 values in this example ? I am using Maple 2024.1

lprint(p)
PLOT(CURVES(Matrix(200,2,{(1, 1) = -10., (2, 1) = -9.89484789949749, (3, 1) = 
-9.80335561909548, (4, 1) = -9.70046298090452, (5, 1) = -9.59688830351759, (6,
1) = -9.49380589849246, (7, 1) = -9.39823531356784, (8, 1) = -9.29927750854271,
(9, 1) = -9.19693520502513, (10, 1) = -9.09492111457286, (11, 1) = 
-8.98998708341709, (12, 1) = -8.89756113165829, (13, 1) = -8.79351140100503, (
14, 1) = -8.6890344321608, (15, 1) = -8.58835151356784, (16, 1) = 
-8.49692177788945, (17, 1) = -8.38820297889447, (18, 1) = -8.29610389547739, (
19, 1) = -8.18897076683417, (20, 1) = -8.09413979497487, (21, 1) = 
-7.99009518894472, (22, 1) = -7.89102011959799, (23, 1) = -7.78764567839196, (
24, 1) = -7.69271567135678, (25, 1) = -7.59032083417085, (26, 1) = 
-7.4839613758794, (27, 1) = -7.39137515477387, (28, 1) = -7.29137949949749, (29
, 1) = -7.18807420301508, (30, 1) = -7.08701012462312, (31, 1) = 
-6.9892254321608, (32, 1) = -6.88065220301508, (33, 1) = -6.78309432763819, (34
, 1) = -6.67893047236181, (35, 1) = -6.58454253768844, (36, 1) = 
-6.48135159396985, (37, 1) = -6.38425695778894, (38, 1) = -6.28276508643216, (
39, 1) = -6.18353823115578, (40, 1) = -6.07965690954774, (41, 1) = 
-5.97960685025126, (42, 1) = -5.87729121407035, (43, 1) = -5.77582280301507, (
44, 1) = -5.68258387135678, (45, 1) = -5.57572153366834, (46, 1) = 
-5.48014258492462, (47, 1) = -5.37823549045226, (48, 1) = -5.28069739798995, (
49, 1) = -5.17239388140703, (50, 1) = -5.07861099396985, (51, 1) = 
-4.97216657788945, (52, 1) = -4.87515404824121, (53, 1) = -4.76903758693467, (
54, 1) = -4.67747702713568, (55, 1) = -4.57320023718593, (56, 1) = 
-4.47247400603015, (57, 1) = -4.37181357688442, (58, 1) = -4.27152345929648, (
59, 1) = -4.17517605326633, (60, 1) = -4.07102195577889, (61, 1) = 
-3.97175554874372, (62, 1) = -3.86728232964824, (63, 1) = -3.77270890854271, (
64, 1) = -3.66818757386935, (65, 1) = -3.56807434874372, (66, 1) = 
-3.46820480201005, (67, 1) = -3.36389067336683, (68, 1) = -3.26781355276382, (
69, 1) = -3.16941743919598, (70, 1) = -3.06077643819095, (71, 1) = 
-2.96241091055276, (72, 1) = -2.86181373366834, (73, 1) = -2.7595089959799, (74
, 1) = -2.66547103417085, (75, 1) = -2.5652296120603, (76, 1) = 
-2.46575123417085, (77, 1) = -2.35934029145729, (78, 1) = -2.26543724422111, (
79, 1) = -2.15709262110553, (80, 1) = -2.05931995175879, (81, 1) = 
-1.96257900603015, (82, 1) = -1.85855141105528, (83, 1) = -1.75410300301508, (
84, 1) = -1.65907041708543, (85, 1) = -1.5581500321608, (86, 1) = -1.4596616, (
87, 1) = -1.35289910050251, (88, 1) = -1.26051985527638, (89, 1) = 
-1.15441893366834, (90, 1) = -1.05467848944724, (91, 1) = -.955901429145728, (
92, 1) = -.857045790954773, (93, 1) = -.756219297487437, (94, 1) = 
-.649344903517589, (95, 1) = -.551351549748743, (96, 1) = -.454619526633167, (
97, 1) = -.351214585929648, (98, 1) = -.248034748743718, (99, 1) = 
-.155424717587939, (100, 1) = -.0457214572864313, (101, 1) = .0460731437185924,
(102, 1) = .153437240201004, (103, 1) = .255905869346734, (104, 1) = 
.347398149748743, (105, 1) = .4502907879397, (106, 1) = .553865465326634, (107,
1) = .656947870351759, (108, 1) = .752518455276382, (109, 1) = .851476260301508
, (110, 1) = .953818563819095, (111, 1) = 1.05583265427136, (112, 1) = 
1.16076668542714, (113, 1) = 1.25319263718593, (114, 1) = 1.3572423678392, (115
, 1) = 1.46171933668342, (116, 1) = 1.56240225527638, (117, 1) = 
1.65383199095477, (118, 1) = 1.76255078994975, (119, 1) = 1.85464987336683, (
120, 1) = 1.96178300201005, (121, 1) = 2.05661397386935, (122, 1) = 
2.1606585798995, (123, 1) = 2.25973364924623, (124, 1) = 2.36310809045226, (125
, 1) = 2.45803809748744, (126, 1) = 2.56043293467337, (127, 1) = 
2.66679239296482, (128, 1) = 2.75937861407035, (129, 1) = 2.85937426934673, (
130, 1) = 2.96267956582914, (131, 1) = 3.06374364422111, (132, 1) = 
3.16152833668342, (133, 1) = 3.27010156582915, (134, 1) = 3.36765944120603, (
135, 1) = 3.47182329648241, (136, 1) = 3.56621123115578, (137, 1) = 
3.66940217487437, (138, 1) = 3.76649681105528, (139, 1) = 3.86798868241206, (
140, 1) = 3.96721553768844, (141, 1) = 4.07109685929648, (142, 1) = 
4.17114691859297, (143, 1) = 4.27346255477387, (144, 1) = 4.37493096582915, (
145, 1) = 4.46816989748744, (146, 1) = 4.57503223517588, (147, 1) = 
4.6706111839196, (148, 1) = 4.77251827839196, (149, 1) = 4.87005637085427, (150
, 1) = 4.97835988743719, (151, 1) = 5.07214277487437, (152, 1) = 
5.17858719095477, (153, 1) = 5.27559972060302, (154, 1) = 5.38171618190955, (
155, 1) = 5.47327674170854, (156, 1) = 5.57755353165829, (157, 1) = 
5.67827976281407, (158, 1) = 5.7789401919598, (159, 1) = 5.87923030954774, (160
, 1) = 5.97557771557789, (161, 1) = 6.07973181306533, (162, 1) = 
6.1789982201005, (163, 1) = 6.28347143919598, (164, 1) = 6.37804486030151, (165
, 1) = 6.48256619497488, (166, 1) = 6.5826794201005, (167, 1) = 
6.68254896683417, (168, 1) = 6.78686309547739, (169, 1) = 6.8829402160804, (170
, 1) = 6.98133632964824, (171, 1) = 7.08997733065327, (172, 1) = 
7.18834285829146, (173, 1) = 7.28894003517588, (174, 1) = 7.39124477286432, (
175, 1) = 7.48528273467337, (176, 1) = 7.58552415678392, (177, 1) = 
7.68500253467337, (178, 1) = 7.79141347738694, (179, 1) = 7.88531652462311, (
180, 1) = 7.9936611477387, (181, 1) = 8.09143381708543, (182, 1) = 
8.18817476281407, (183, 1) = 8.29220235778895, (184, 1) = 8.39665076582915, (
185, 1) = 8.49168335175879, (186, 1) = 8.59260373668342, (187, 1) = 
8.69109216884422, (188, 1) = 8.79785466834171, (189, 1) = 8.89023391356784, (
190, 1) = 8.99633483517588, (191, 1) = 9.09607527939699, (192, 1) = 
9.1948523396985, (193, 1) = 9.29370797788945, (194, 1) = 9.39453447135678, (195
, 1) = 9.50140886532663, (196, 1) = 9.59940221909548, (197, 1) = 
9.69613424221106, (198, 1) = 9.79953918291458, (199, 1) = 9.9027190201005, (200
, 1) = 10.},datatype = float[8],storage = rectangular,order = Fortran_order,
shape = []),COLOUR(RGB,.47058824,0.,.54901961e-1,_ATTRIBUTE("source" = 
"mathdefault"))),AXESLABELS("",""),VIEW(-10. .. 10.,DEFAULT,_ATTRIBUTE("source"
= "mathdefault")),_ATTRIBUTE("input" = [table([(1)=plot,(2)=[0]]), 
"originalview" = [-10. .. 10., 0. .. 0.], "originalaxesticks" = AXESTICKS(
DEFAULT,DEFAULT,_ATTRIBUTE("source" = "mathdefault"))]))

Update

This below is a proc that takes PLOT data struct and returns correct x,y ranges. It seems to work ok on few tests I did. Bug reports are welcome.

>

restart;

>

#gets a PLOT struct and returns correct x,y ranges

get_x_y_range:=proc(p)::list;
local T,from_x,to_x,from_y,to_y;

   try
      T:=plottools:-getdata(p,'rangesonly');
   catch:
      error StringTools:-FormatMessage( lastexception[2..-1] );
   end try;

  from_x := op(1,T[1]);
  to_x   := op(2,T[1]);
  from_y := op(1,T[2]);
  to_y   := op(2,T[2]);

  if from_y=to_y then
     if from_y<0 then
        to_y   := 0;
        from_y := from_y-abs(from_y)/2;
     elif from_y>0 then
        from_y := 0;
        to_y   := to_y+to_y/2;
    else
        from_y := -1;
        to_y   := 1;
    fi;
  fi;

  RETURN([from_x..to_x,from_y..to_y]);

end proc:

>	p := plot(6); get_x_y_range(p)

>	p := plot(-3); get_x_y_range(p)

>	p := plot(0); get_x_y_range(p)

>	p := plot(x); get_x_y_range(p)

>	p := plot(sin(x)); get_x_y_range(p)

>	p := plot(exp(x)); get_x_y_range(p)

>

Download get_x_y_range.mw

Update

Warning. plottools:-getdata(p,'rangesonly') is buggy. I replaced this with

rhs~(indets(p, identical("originalview")=anything))[];

which gives more accurate Y ranges used. Here is example showing that getdata(p,'rangesonly') returns wrong y ranges for a plot compared to how it shows on the screen, So in the function above, better use the second method instead. This whole getdata(p,'rangesonly'); should be looked at by Maplesoft and fix to make it return correct values that agrees with screen view.

Download fixed_plot_Y_range.mw

Wrong Latex generated when using _C1 fo...

Asked: nm 9949 Product: Maple 2024

July 18 2024

1 2

This is some serious problem in Latex in Maple 2024.1

I went back to using _C1, _C2 for my own constants of integration.

But I want to get the nice latex for c__1,c__2.

So to do that, my understanding is that I just need to call Maple's dsolve after restart on some random ode in order to set c__1,c__2 for display only and also for latex.

This below seems to confirm this. But now the latex generated is all wrong and messed up on some places.

My question is: I want to use use _C1,_C2 (i.e. the traditional constants) in my own code I write which generates solution to an ode, but for Latex, I'd like these to come out as c__1,c__2 since they look nicer.

What is the correct way to do this? What Am I doing wrong here? I do not see it.

>	interface(version);

>	#EXAMPLE showing using _C1 for input and latex. All works OK restart;

>	sol:=y(x) = x+_C1/x^2;

>	#correct latex. No problem compiling, but not nice looking _C1 latex(sol)

y \! \left(x \right) = x +\frac{\textit{\_C1}}{x^{2}}

>	#Example showing what happens when making call to dsolve initially restart;

>	dsolve(diff(y(x),x$2)=0); #this call is used to just activate display of nicer constants

>	sol:=y(x) = x+_C1/x^2;

y(x) = x+c__1/x^2

>	#bad latex, gives error when compiling with texlive latex(sol)

y \! \left(x \right) = x +\frac{c}{_}

Download latex_problem_maple_2024_july_18_2024.mw

And to confirm this is new problem in Maple 2024, I run the same exact worksheet now in Maple 2023.2, and there it works correctly. i.e. Latex generated is correct in both cases. Here is the Maple 2023.2 worksheet, you can see below the difference in Latex.

>	interface(version);

>	#EXAMPLE showing using _C1 for input and latex. All works OK restart;

>	sol:=y(x) = x+_C1/x^2;

>	#correct latex. No problem compiling, but not nice looking _C1 latex(sol)

y \! \left(x \right) = x +\frac{\textit{\_C1}}{x^{2}}

>	#Example showing what happens when making call to dsolve initially restart;

>	dsolve(diff(y(x),x$2)=0); #this call is used to just activate display of nicer constants

>	sol:=y(x) = x+_C1/x^2;

y(x) = x+c__1/x^2

>	#good Latex now in Maple 2023.2. latex(sol)

y \! \left(x \right) = x +\frac{c_{1}}{x^{2}}

Download latex_problem_maple_2023.2.mw

If it makes any difference to Maple, I am using the typesetting EXTENDED now for everything. But I do not think Latex should care about this, but thought to mention it just in case.

dsolve does not return solution unless g...

Asked: nm 9949 Product: Maple 2024

July 18 2024

1 0

I have thought before that Maple's dsolve will try to return implicit solution automatically if unable to find explicit one or for some other reasons it prefers implicit.

But In this ode, we see Maple returns no solution at all for this first order quadrature ode, even though it can find solution when given implicit option.

Is this a correct behaviour? Should it not have returned this solution automatically?

Download why_no_solution_by_dsolve_july_18_2024.mw

Update

I found another example of this problem. Maple gives no solution to this ODE unless option implicit is given. This is not right behaviour. If Maple can't give explicit solution, it should return the implicit one automatically. How is the user supposed to know there is a solution to this ode otherwise?

>

restart;

>	Physics:-Version();

>

restart;

>

libname;

$"C:\Users\Owner\maple\toolbox\2024\Physics Updates\lib", "C:\Program Files\Maple 2024\lib"$

>	ode:=(x^2+y(x)^2-2y(x))diff(y(x),x) = 2*x: IC:=y(0)=1: sol:=dsolve([ode,IC],y(x));

>	sol:=dsolve([ode,IC],y(x),'implicit');

>	sol:=dsolve([ode,IC],y(x),'useInt');

y(x) = -RootOf(exp(_Z)*x^2-(Int(_b*(_b-2)/exp(_a), _b = 0 .. -_Z))+Int(_b*(_b-2)/exp(_a), _b = 0 .. 1))

>	sol:=dsolve([ode,IC],y(x),'explicit');

>

Download why_does_not_solve_unless_implicit_august_12_2024.mw

Maple 2024.1 locks up completely when us...

Asked: nm 9949 Product: Maple 2024

July 17 2024

0 6

I called dsolve with timelimit on this ode. All of Maple instantly locks up.

I do not mean the worksheet, but everything. I have each worksheet using its own engine,. Not able to open new worksheet, nothing clicks. The whole front end locks up. Can't click on anything.

Killing every mserver.exe does not even resolve this. I had to terminate all of Maple from the task manager. The strange thing, is that looking at task manager I see mserver.exe doing nothing. zero CPU. Only the front end process is at high CPU (the one with the Java icon). It looks like the Java frontend is locked up for some reason.

Do others see the same thing? does this happen on the mac also? Please make sure to save all your work before trying to run this on your PC.

Maple 2024.1 on windows 10. This is first order Riccati ode.

Download maple_lock_up_july_17_2024.mw

These are GUI options on my end.

UPDATE 1

in Maple 2023.2 also on windows 10, there is no lock up at all. same code. The solution to the ode is very large. I tried using both typesetting level to EXTENDED and typesetting level MAPLE STANDARD and no hang.

I wonder if this has something to do with why Maple 2024.1 locks up? But I have not changed anything in my end. I made no change in options or anything else. same PC, same graphics card.

UPDATE 2

Found the BUG!!

In Maple 2024.1, if I change the display option typesetting level to EXTENDED, the front end do not hang.

If I change the display typesetting level MAPLE STANDARD, the ftont end hangs.

But why??

>	interface(version);

>	Physics:-Version();

>	ode:=(a2x^2+b2x+c2)diff(y(x),x)=y(x)^2+(a1x+b1)y(x)+a0x^2+b0*x+c0;

>	DEtools:-odeadvisor(ode);

>	interface(typesetting=extended):

>	timelimit(30,dsolve(ode));

>	interface(typesetting=standard):

>	#WARNING, this will hang MAPLE now. WHY?? timelimit(30,dsolve(ode));

Download maple_lock_up_july_17_2024_2.mw

ps. Reported to Maplesoft support. July 17, 2024. Hopefully this will be fixed in Maple 2024.2

c__1 and _C1 do not seem to work the sam...

Asked: nm 9949 Product: Maple 2024

July 09 2024

2 2

The change from _C1 to c__1 is causing me so many problems as I still do not fully understand it.

I have nothing in my Maple ini file.

I was solving from a solution to an ode for the constant of integration, which I know is c__1 inside a proc.

But this was failing to solve for it. When I copy same code to global (worksheet), it works. So it is clearly issue of name space related to c__1 vs. _C1.

So even though the solution now has the subscripted version and not the traditional one (since that is the default now), it does not solve for it when inside a proc.

If instead I solve for _C1, then it works. Even though the solution has c__1. This is bizzar to me.

I also tried adding global c__1; inside the proc, but this did not help. (did not show this version in the worksheet).

Why is solving for c__1 fail inside a proc but works outside? Clearly the c__1 in the solution of the ode is not the same c__1 I typed in to solve for, even though on the screen they look the same.

So c__1 is not really the same as _C1 in all aspects. Right?

Here is worksheet. Example 1 below shows how it fails inside proc

Maple 2024.1. Does this happen for others on Linux or the Mac?

>

restart;

>	interface(version);

>	Physics:-Version();

Example (1) solving for constant of integration fails inside proc but works outside

>

restart;

>	foo:=proc(ode::`=`) local sol,the_constant; sol:=dsolve(ode); print("sol is ",sol); the_constant:=solve(sol,c__1); print("the constant is ",the_constant); end proc;

proc (ode::`=`) local sol, the_constant; sol := dsolve(ode); print("sol is ", sol); the_constant := solve(sol, c__1); print("the constant is ", the_constant) end proc

>	#this does not work ode:=diff(y(x),x) = 3/4*y(x)/x; foo(ode)

>

restart;

>	#this works ode:=diff(y(x),x) = 3/4*y(x)/x; sol:=dsolve(ode); print("sol is ",sol); the_constant:=solve(sol,c__1);

>

Example (2). Solving for _C1 works, even though the ode has c__1 , why??

>

restart;

>	foo:=proc(ode::`=`) local sol,the_constant; sol:=dsolve(ode); print("sol is ",sol); the_constant:=solve(sol,_C1); #notice solving for _C1 now print("the constant is ",the_constant); end proc;

proc (ode::`=`) local sol, the_constant; sol := dsolve(ode); print("sol is ", sol); the_constant := solve(sol, _C1); print("the constant is ", the_constant) end proc

>	ode:=diff(y(x),x) = 3/4*y(x)/x; foo(ode)

>

restart;

>	ode:=diff(y(x),x) = 3/4*y(x)/x; sol:=dsolve(ode); print("sol is ",sol); the_constant:=solve(sol,c__1); #these both work OK in global the_constant:=solve(sol,_C1); #these both work OK in global

>

Example (3). Forcing arbitraryconstants = subscripted it still does not work inside proc. Why??

>

restart;

>	foo:=proc(ode::`=`) local sol,the_constant; sol:=dsolve(ode,arbitraryconstants = subscripted); print("sol is ",sol); the_constant:=solve(sol,c__1); print("the constant is ",the_constant); end proc;

proc (ode::`=`) local sol, the_constant; sol := dsolve(ode, arbitraryconstants = subscripted); print("sol is ", sol); the_constant := solve(sol, c__1); print("the constant is ", the_constant) end proc