7345 Reputation

10 years, 343 days

Hmmmmm...

Well, the fundamental reason you only see one plot is that issue multiple 'restart' commands in your worksheet. Every time you use the 'restart' command you are instructing Maple to clear everything prior to that point!

So the simplest solution would be to delete all the restart commands. However, this means that initialisations/evaluations from the preceding code may influence subsequent code: which happens in your case - and it could take a long time to figure ot precisely why. For this reason (and the fact that your code, as written, is spectacularly inefficient), I have rewritten it so that it generates an Array of plots for each value of the parameter N[c] in your worksheet - this seems to be the only thing which is varied. The only reason I generate an array of plots for each value of N[c] is that your solution process produces multiple real solutions (as well as a lot of complex ones) and I have no on what basis you are selecting a specifi real solution. So for the supplied values of N[c], I generate all real values of 'a', then plot the corresponding polynomial.

Check out the attached - I could probably tidy it up a little more but it is past my bedtime

plotProb.mw

Something like...

eq1:= x^2+y^2=0.314;
eq2:= y=0.05180967688*x;
ans:=convert(fsolve([eq1,eq2]),list);
map(rhs, ans);

A slightly different cheat...

For the two curves cc1, cc2, you need to set the lower limit of the associated plotting range according to fsolve(cc1=P[B]), fsolve(cc2=P[B]). As in

restart;
F1:= (w+u-s)*(-P[A]*P[B]+P[B])+P[A]*(p-s)-c+s:
F2:= P[A]*P[B]*(p-s)-c+s:
c1:= solve(F1, P[A]):
c2:= solve(F2, P[A]):
params := [w=4, u=2, c=2, s=1, p=7]:
cc1:= eval(c1, params):
cc2:= eval(c2, params):
p1:= plot(cc1, P[B]=fsolve(cc1=P[B])..0.5, color=blue):
p2:= plot(cc2, P[B]=fsolve(cc2=P[B])..0.5, color=green):
p3:= plot(P[B], P[B]=0..0.5, color=red):
plots:-display([p1,p2,p3], thickness=2, view=[0..0.5, 0..0.5]);
plots:-display([p1,p2], thickness=2, view=[0..0.5, 0..0.5]);

Check...

Tools->Options->Interface

and ensure that the checkbox for "Large toolbox Icons" is ticked

This is probably about as good as you are going to get. Result is acceptable on my 2560X1440 display - but on a 4K, maybe not?

Maple 2015/2016 come with "new" toolbar icons which are supposedly designed to be more readable on "high-resolution" monitors - and these are "more readable" that those for Maple18 on the same 2560X1440 display. But on a 4k display......

This is a regrettable side-effect of the fact that many artefacts (eg icons) in a (eg) a user interface are prgrammed as fixed pixel counts - and as the pisel size reduces, the artefact (aka icon) size reduces. You can make the argument that any applicaion should start with some seriously high resolution icons, then interrogate the display resolution and sample icons appropriately so that they are an accceptable size. I have no argument with this, but I accpet that it would mean a significant rewrite of the UI for many applications.

I feell obliged to point out that this problem is not specific to Maple. I have an issue with several Windows applications, even on a 2560X1440 display .....with a 4k display, ouch :-(

Two possibilities...

1. Recommended: read the help at ?procedure, and code the required function accordingly
2. Not recommended: use the Matlab-to-Maple translator

I took the code

function R=ff(i,m)
K=1;
Q= zeros( i );
for j=1:2:i
Q(j)=2*i-K;
K=4+K;
end
R=Q(m);

and saved it in the file 'test.m'. I then used

restart;
with(Matlab):
FromMFile("D:/Users/TomLeslie/myMaple/test.m", "D:/Users/TomLeslie/myMaple/test.mpl");

to read the matlab file, output it as a Maple file, then read the Maple file - obviously you will have to change the pathnames in the above to something appropriate for your installation(s). Subsequent invocations of the Maple code, such as

ff(3,1);
ff(19,7);

then returned 5 and 25 respectively. Are these correct? Well maybe!.

I generally find that doing a "machine translation" from one programming language to another is a high-risk activity, so I never recommend it.

However, if you are too lazy to learn how to write simple Maple procedures, then maybe you will be prepared to use the above technique

Not bug...

s is used as a variable in your equations

it is then used as a loop index to provide facilitate your loop statement.

Changing the loop varoable solves your problem, as in

restart:
e1 := 12*g^2+12*h^2+4*i^2+3*j^2=684:
e2 :=  12*l^2+12*m^2+4*n^2+3*o^2=684:
e3 := 12*q^2+12*r^2+4*s^2+3*t^2=172:
e4 := 12*v^2+12*w^2+4*x^2+3*y^2=108:
e5 := 12*g*l+12*h*m+4*n*i+3*j*o=-84:
e6 := 12*g*q+12*h*r+4*s*i+3*j*t=-84:
e7 := 12*g*v+12*h*w+4*x*i+3*j*y=-84:
e8 := 12*l*q+12*m*r+4*n*s+3*o*t=-84:
e9 := 12*l*v+12*m*w+4*n*x+3*o*y=-84:
e10 := 12*q*v+12*r*w+4*s*x+3*y*t=-84:
e11 := g+h+i+j=-1:
e12 := l+m+n+o=-1:
e13 := q+r+s+t=-1:
e14 := v+w+x+y=-1:
e15 := h*i+m*n+3*s*r+4*x*w=-21:
e16 := g*i+l*n+3*s*q+4*x*v=-21:
e17 := i+n+3*s+4*x=-3:
e18 := g*h+m*l+3*q*r+4*w*v=-7:
e19 := h+m+3*r+4*w=-1:
e20 := g+l+3*q+4*v=-1:
e21 := i*j+o*n+3*s*t+4*x*y=-84:
e22 := j*h+o*m+3*r*t+4*y*w=-28:
e23 := j*g+o*l+3*q*t+4*y*v=-28:
e24 := j+o+3*t+4*y=-4:
e25 := j^2+o^2+3*t^2+4*y^2=144:
e26 := i^2+n^2+3*s^2+4*x^2=129:
e27 := h^2+m^2+3*r^2+4*w^2=57:
e28 := g^2+l^2+3*q^2+4*r^2=57:
eqset := {e1, e2, e3, e4, e5, e6, e7, e8, e9, e10, e11, e12, e13, e14, e15,
e16, e17, e18, e19, e20, e21, e22, e23, e24, e25, e26, e27, e28};
for zzzz in eqset do print(zzzz) end do;

Perfectly possible - but...

1. It is not to difficult to write the code to perform what you want. However it looks as if the pdsolve() process is starting to have significant numerical problems.
2. f(x,y) with y=0.02, plotted for x=0..20 starts small, and continues small whilst becoming oscillatory. This characteristic is often associated with numerical noise in the pdsolve() process.
3. the pdsolve() process fails completely for the third PDE (ie when P=10)
4. If pdsolve() can obtain a solution then it is always possible to uses fdiff() to get the functions which you want. But if pdsolve() is generating something close to "numerical noise" under the desired conditions, then performing numerical differentiation on this "numerical noise", whilst possiblel, is not going to be very meaningful
5. Only suggestion I can make at this point is to try to improve the accuracy of the pdsolve process: increase the mesh size, decrease the error tolerances, etc, etc. This is a rather time-consuming process, because solution times will increase a lot, and determinng the optimal options for the pdsolve() command is a bit of an "experimental science".

Anyhow check out the attached, where I have added your current requirements to the end of the worksheet I produced previously. For the reasons stated above, although the code runs, I have little faith in the accuracy of the results being generated

pdeProb2.mw

Maybe...

something like the attached

ruku.mw

"Toy" example...

what else do you want/need

restart;
f:=x->cos(x); # function whose minimum is required
a:=0; # lower limit
b:=evalf(2*Pi); # upper limit
n:=50; # number of steps
min(seq( f(j), j=a..b, (b-a)/n)); # minimum value obtained

Can't reproduce...

restart;
f := proc (x) options operator, arrow; sqrt(x)+ln(.1*x) end proc;
xk := 5.0;
for k to 6 do
xk1 := xk-f(xk)/(D(f))(xk);
xk := xk1
end do;

works for me - at least for initial values between 1 and 10. I can see potential issues for initial values which are negative (or even large and positive).

Since I can't reproduce, I can only suggest

1. make sure you have a 'restart' command at the start of the code snippet
2. ensure that the initial value is a floating-point number - ie enter 5.0 rather than 5, which will essentially force all calculations to use floating-point rather than 'exact' arithmetic
3. outside chance that it is a Maple version issue, although reading your code, I can't see any reason why this would be the case. But if (1) and (2) above do nt fix your problem, then specify Maple version

Recommendation...

1. When adding a small number of terms, it is generally a 'better' idea to use add() rather than sum()
2. If you do decide to stick with sum() then you will need to adjust the range expression so that the first entry is less than the second. So sum(whatever, -2..0) will give the answer you (probably) want but sum(whatever, 0..-2) will not. Now sum(whatever, 0..-2)  will deliver a consistent answer, but probably not the one you want: see the ?sum/details page as suggested by vv
3. Using the add() command, it does not matter whether the range is -2..0, or 0,,-2, provided that in the latter case one provides a third argument indicating the 'step'. By default this is '1'. But add(whatever, -2..0) will provide the same answer as add(whatever, 0..-2,-1)

Something along the lines of...

DETools:-DEplot
( diff(x(t),t)-x(t), # ODE
x(t),                # dependent variable
t=-1..1,           # range of indepenent variable
{x(0)=1}         # initial condition(s)
);

use the view option...

as in

display(f1, g1, view = [.8 .. 1.2, 0 .. .4])

Basically yes...

See the attached, where I have plotted

1. f(x,y), at x=xVal, where I set xVal=1
2. diff( f(x,y),y), at x=xVal, where I set xVal=1
3. diff( f(x,y),y, y), at x=xVal, where I set xVal=1

You can set xVal to anything sensible with the pde solution space

pdeProb.mw

Clarify...

In order to see where you are now, then you need to include representative array 'P'. Also a value for 'N', (unless 'N' is just the range of the first index in 'P').

It is fairly easy to kill the gridlines in the example 'checkerboard' by using the 'style'  option in the polygonplot() command, as in

p := seq
( seq
( plots[polygonplot]
( [[i,j], [i+1,j], [i+1,j+1], [i,j+1] ],
color=ColorTools:-Color([rand()/10^12,
rand()/10^12,
rand()/10^12]),
style=polygon
),
i=1..10
),
j=1..10
):
plots[display]([p]);

 First 112 113 114 115 116 117 118 Last Page 114 of 148
﻿