10 years, 9 days

## Not unexpected...

You appear to believe that the "prettyprinted" version of Maple's 2D-input bears a simple relationship to underlying ASCII characters - not true.

If you select the input argument to the Explode() command and then, from the Maple toolbar, you use

Format->Convert To->1-D Math Input,

then you will observe that your "input" string is actually

"1&le; n&le;m"

which the Explode() command explodes "correctly"

## Yes...

Ths problem has existed for the past couple of days :-(

## No...

NLPSolve() (usually) requires that the objective function be differentiable, o that it can figure out which direction represents "downhill". The "Error Message" just says that around the iniitial point the objective function is "flat". This *might* be a maximum, a minimum, or indeed just a region where your objective function is "flat", ie doesn't change value when the independent variables are changed

If you are supplying an initial point, change it

If you are not supplying an initial point, then try supplying a few different ones

Alternatively use the big green up-arrow in the MaplePrimes toolbar to upload your worksheet

## Use 'list' not 'set'...

You have defined 'Sol' as a set - ie using curly braces {}.

Sets have no concept of order - you cannot guarantee which element  will occur where. Whatever you may think, the set {3,2,1} is absolutely identical to {1, 2, 3}.

The simplest way to fix your immediate problem is to change the definition of 'Sol' from a set to a list. Although it defeats me why you should want to loop through the elements of either the list or the set, why not just apply the 'assign()' command elementwise??

Both options are shown in the attached

 >
 >
 (1)
 >
 (2)
 >
 >
 (3)
 > restart;
 > N := 3: L := 0: R := 1: T := 1: NN := 4: Mx := NN: My := NN: Mz := NN: Delta__x := (R - L)/Mx; Delta__y := (R - L)/My; Delta__z := (R - L)/Mz; Delta__t := T/N; n := 0: Sol := [u[1, 1, 1, 1] = 0.014578485742667928362, u[1, 1, 2, 1] = 0.029548584487036957497, u[1, 1, 3, 1] = 0.044323688168892291723,         u[1, 2, 1, 1] = 0.029548584487036957496, u[1, 2, 2, 1] = 0.059949352480274039874, u[1, 2, 3, 1] = 0.090261881648876334312,         u[1, 3, 1, 1] = 0.044323688168892291724, u[1, 3, 2, 1] = 0.090261881648876334322, u[1, 3, 3, 1] = 0.13752578451379877709,         u[2, 1, 1, 1] = 0.026717348328676609020, u[2, 1, 2, 1] = 0.054613563612919064759, u[2, 1, 3, 1] = 0.083815829643036530661,         u[2, 2, 1, 1] = 0.054613563612919064757, u[2, 2, 2, 1] = 0.11170063733186747631,  u[2, 2, 3, 1] = 0.17183586485000930908,         u[2, 3, 1, 1] = 0.083815829643036530657, u[2, 3, 2, 1] = 0.17183586485000930908,  u[2, 3, 3, 1] = 0.26633149533104995811,         u[3, 1, 1, 1] = 0.039827755588924378576, u[3, 1, 2, 1] = 0.081803408890300879260, u[3, 1, 3, 1] = 0.12733149048832359596,         u[3, 2, 1, 1] = 0.081803408890300879254, u[3, 2, 2, 1] = 0.16807855529017971428,  u[3, 2, 3, 1] = 0.26194706234064804568,         u[3, 3, 1, 1] = 0.12733149048832359595,  u[3, 3, 2, 1] = 0.26194706234064804570,  u[3, 3, 3, 1] = 0.40978986410708023066];
 (4)
 > assign~(Sol): # # A test #   u[3, 2, 3, 1];
 (5)
 >
 >
 >

## Workaround...

Force the timestep option to be 1/2 of the spacestep option, and it always seems to "work", irrespective of the magnitude of the latter.

The attached works for all values of "myStep" which I have tried.

I could speculate on why - so (at the risk of being completely wrong). SInce the spatial domain is symmetrical wrt 0, a spacestep setting of 0.1, would give 20 intervals. To guarantee 20 intervals in time, the timestep has to be set to 0.05. Maybe when computing a "default" timestep, Maple just uses the spacestep setting (ie 0.1), ignoring the spatial range, and thus ends up with 10 time intervals?

In general things seem to work better if the number of time intervals = number of spatial intervals

PS I also "corrected" the definition of the piecewise function used for the initial conditions, because I didin't understand wht yo menat by the condition 'true', and it was undefined for x=0

Anyhow for what it is worth the attached seems to work OK.

 > restart; pde := diff(u(x,t),t\$2)=diff(u(x,t),x\$2): bc  := u(-1,t)=u(1,t),D[1](u)(-1,t)=D[1](u)(1,t): f:=x->piecewise( -1/2
 >

## So many basic syntax errors...

that the code you present is basically unfixable. Now just becuase I like making guesses, I'm going to make the following observations/recommendations

1. learn the difference between a function with an argument nad an indexed variable: for example x(0) is the function x() with the argument 0, x[0] is the zeroth element of indexable variable 'x'. These are two entirely different concepts.  If you don't understand the difference, then don't write any code until you do!
2. learn the difference between an indexable quantity (eg x[0]) and one with an inert subscript (eq x__0). If you choose to use Maple's 2D input option then this will "appear" the same in both input and output lines - although, of course, they have entirely different meanings. If you don't understand the difference, then don't write any code until you do!
3. don't use the same name as the index variable in a "for" loop and then as the index variable in any statement (eg add() ) within that "for" loop. You *might* get away with this ( Maple's scoping rules are pretty good), but it is a high-risk activity.
4. don't try to define a variable in terms of itself - for example in your code you have various places where you write something like x[n+1]=add(x[n], n=0..m). Note that this violates recommendation (3) above, but let's just assssume for the moment that Maple's scoping rules will handle this, and that the two quantities labelled 'n' on either side of this assignment are entirely distinct - so that (for example) Maple will (may?) interpret this as x[2]=add(x[n], n=0..m). Consider what happens if n=2 on the lhs and m=2. Then the statement becomes x[2]:=x[0]+x[1]+x[2]. So you are trying to assign x[2] in terms of itself. This is known as "recursive assignment" and will never work.
5. If I guess what you actually mean when you commit any/all the errors above and try to fix it then I will get something like the attached. (I have also assumed that when you defined the parmeter 'u' and then never used it, you actually meant the parameter 'mu' which is used but never defined - of course this could be one of the many guesses where I'm wrong

Anyhow for what it is worth, the attached *might* be of some use - but you will have to check every single guess I have made

 > restart; m := 10; S[lambda] := sum(S[b]*lambda^b, b=0..m): L[lambda]:= sum(L[b]*lambda^b, b=0..m): G[lambda]:= S[lambda]*L[lambda]: ft := unapply(G[lambda], lambda): for i from 0 to m do     A1[i] := (D@@i)(ft)(0)/i!; end do;
 (1)
 > beta:= 0.04: lambda:= 0.4: delta:= 0.3: d:= 0.01: e:= 0.1: a:= 0.2: k:= 0.6: mu:= 0.03: q:= 0.8: x[0]:= 9: w[0]:= 3: y[0]:= 1: v[0]:= 4: m := 3:
 (2)
 >

## Many ways to do this...

of which the attached is only one

 > restart;   with(plots):   with(plottools):   d1:= display        ( [ display            ( circle              ( [-6,0],                6,                color=red,                thickness=2              )            ),            plot( 6*sin(x),                  x=0..4*Pi,                  color=red,                  thickness=2                )          ]        ):   F:= proc(t)            display            ( [ display                ( line                  ( [-6,0],                    [6*cos(t)-6, 6*sin(t)],                    color=blue,                    thickness=4                  )                ),                pointplot                ( [t, 6*sin(t)],                  symbol=solidcircle,                  symbolsize=24,                  color=blue                )              ],              scaling=constrained            );       end proc:    animate( F, [theta], theta=0..4*Pi, background=d1, frames=100);
 >

## Not an explanation...

but if I were trying to achieve the same(?) thing, I'd probably wirte the attached - which *seems* to work

 > p:= proc()            local x:=1,                  v:= ;            return v;       end proc;   ans:=p();
 (1)
 >

## A solution...

It is not too difficult to "reproduce" the calculation in the paper you reference, which is done in the attached

 > restart;   interface(version);
 (1)
 > # # Set up system for the paper supplied by the OP. # The two "important equations in that paper are # numbered eq1 and eq37 - so use the same labelling here #   eq1:=v__beta(r,beta)=2*R__i^2*(R(beta)^2-r^2)/R(beta)^4;   eq37:=diff(v__r(r, theta, beta),r)*r*(R__f-r*cos(theta))+v__r(r,theta,beta)*(R__f-2*r*cos(theta))+r*diff(v__beta(r,beta),beta)=0; # # According to the text eq1 is subject to the additional # condition that # # R(beta)=R__i+2*beta*(R__f-R__i)/Pi # # so make this substitution in eq1 #   eq0:=R(beta)=R__i+2*beta*(R__f-R__i)/Pi;   eq1a:= subs(eq0, eq1); # # Then susbtitute this result in eq37 to produce the # "ordinary linear first-order differetnial equation" #   eq37a:=simplify(expand(subs(eq1a, eq37)));
 (2)
 > # # Solve the above differential equation #   sol1:=simplify(dsolve(eq37a, v__r(r, theta,beta))); # # The solution contains an arbirary function # _F1(theta, beta) in the "undifferentiated" variables # so I am arbitrarily(?) going to set this function to 0 #   sol2:=eval(sol1, _F1(theta, beta)=0);
 (3)
 > # # The above solution *looks* very similar to the desired # solution (labelled eq2 in the OP's reference paper), but # trying to massage sol2 above to exactly match the form # the form given in the paper could take for ever! # # Easier just to reproduce eq2 (from the paper) here #   eq2:=v__r(r, theta, beta)=4*Pi^2*r*(R__f-R__i)*R__i^2*((Pi*R__i+2*(R__f-R__i)*beta)^2-Pi^2*r^2)/((Pi*R__i+2*(R__f-R__i)*beta)^5*(R__f-r*cos(theta)));
 (4)
 > # # Check that the right hand side of the ODE solution above # and eq2 (from the paper) are the same, by subtracting them. # # Answer should be zero! #   simplify(rhs(sol2)-rhs(eq2));
 (5)
 > # # Knowing that the solution obtaine by dsolve() above is # "correct", OP's original worksheet wants to compute # this for some given values of parameters #   d:=10: c:=10: LI:=4: R__i:=d/2+LI: R__f:=c+d/2+LI: # # so that the solution sol2 becomes #   sol2;
 (6)
 >

## Observation...

Maple18, Maple 2015, and Maple 2016 all return "infinity"

Maple 2017, Maple 2018 and Maple 2019 all returrn Pi*R

Looking at the "updates" in Maple 2017 (see ?Advanced Math), there is a whole section on improvements associated with symbolic integration. So I guess whatever the original problem, one of these updates fixed it.

## You can't...

do a contour plot of a vector field, since the former is magnitude-only and the latter contains both magnitude and direction. You can produce a contour plot of the magnitude of the vector field, which is what I have done in the attached

 > restart;   with(VectorCalculus):   with(plots):   epsilon:=.01: # # Define the potential and plot it #   pot := 1/sqrt(x^2+y^2+epsilon)-1/sqrt((x-.25)^2+y^2+epsilon):   contourplot(pot, x=-0.5..1, y=-0.5..0.5, grid=[100,100]); # # Take the gradient of the potential - which should be the # electric field #   v := VectorField( Gradient( pot, [x,y] ), 'cartesian'[x,y] ): # # Produce a field plot #   fieldplot(v, x=-0.5..0.5, y=-0.5..0.5, arrows=THICK, color=red, anchor=tail); # # OP wants a contour plot of the electric field. However # a contour plot is magnitude-only. Presumably OP wants the # contour plot to represent the purely the magnitude of the # vector field #   contourplot(Norm(v)(), x=-0.5..1, y=-0.5..0.5, grid=[100,100]);
 >

## A lot of syntax problems...

which I *think* I have fixed in the attached. This involved removing lots of redundant stuff and a fair amount of editing so the chances that I got everything correct is not that great. I suggest you read/check this very carefully

For some reasom this site is not displaying worksheets correctly today, so you will have to download/execute

someODEs.mw

## Confusing objective...

the attached will calculate/plot both speed() and L() for any numeric argument.

Unfortunately the MApleprimes uploader sppears to be broken - again- and will not display the contents of this file on this site so you will have to download/execute

speedandL.mw

## Things to investigate...

My ability to help is limited by the fact I only have a 'bare' copy of Matlab with no addOns/toolboxes, other than the Maple toolbox. However the following observations may be helpful

From the Matlab 'HOME' tab, Add-Ons -> Manage AddOns does not identify the Maple toolbox as a conventional add-on. In fact it does not appear in this list at all. Suggests that one cannot use Matlab'x Add-On manager

On the other hand, from the Matlab 'HOME' tab Set Path shows two Maple-related entries, in my case at the bottom of the list. These entries are

C:\Program Files\MATLAB\R2019b\toolbox\maple
C:\Program Files\MATLAB\R2019b\toolbox\maple\util

So I *assume* that when one installs the Maple toolbox, the Matlab default pathdef.m file (located in C:\Program Files\MATLAB\R2019b\toolbox\local for a "default" installation) is edited to include these "Maple-related" entries. Presumably also, during the Maple toolbox installation, references to the "default" Matlab symbolic toolbox are removed from the pathdef.m file.

So the first thing experiment I would try

1. Uninstall the Maple toolbox
2. Verify that the default symbolic toolbox is working
3. Copy the pathdef.m file to somewhere convenient
4. Reinstall the Maple toolbox
5. In a decent editor check the differences between the "current" pathdef.m file and that saved at step (3) above. They *ought* to be different - references to the default symbolic toolbox removed and references to Maple included
6. At this stage (ie with the Maple toolbox installed and "active"), use the Matlab toolbar HOME->Set Path dialogue to remove the two Maple entries
7. Path changes take place "immediately" (ie no restart is necessary), this ought to disable the Maple toolbox (without "unistalling" it
8. Assuming that everything has worked until now find the references to the defalt symbolic toolbox obtained at step 5) above, and again using the HOME->Set Path dialogue, use the Add folder option to reinstate these.
9. Verify that the default symbolic toolbox is now working
10. Again assuming that everything is OK, you can now "toggle" beween default and Maple symbolic toolboxes just by using the Add Folder and Remove Folder options in the Set Path dialogue

As has already been noted it is not clear whether you mean 12^(6^5), or (12^6)^5.  The attached does both

 > restart:
 > doWork:=proc( N::posint)                 local p,                       num:=N,                       digsum:=add                               ( irem                                 (num, 10, 'num'),                                 p=1..length(num)                               );                 if   irem(digsum, 3)=0                 then printf( "      %a is divisible by 3\n", digsum):                 elif isprime(digsum)                 then printf( "      %a is prime\n", digsum):                 else printf( "      %a is nether prime nor divisible by 3\n")                 fi:           end proc:   doWork(12^(6^5));   doWork((12^6)^5);
 37845 is divisible by 3       153 is divisible by 3
 >
 >