solns:=solve(eqns,vars,explicit);

Your four solutions included RootOf() that had multiple solutions. You could use allvalues() on the RootOf() or you can use the explicit option to solve()

If you use a whole bunch of trace() and use kernelopts(opaquemodules=true), then you can track that `int/indef2` recognizes that the integral includes both trig and exponential and invokes `int/trigexp` to analyze it. In there, a particular pattern possibility is detected, confirmed by the analysis of `int/ppexptr`, and then `int/pexptr`is invoked to carry out the actual integration. Inside that, pretty much the most simple case is detected, and set formula are filled out and the result returned. As an analogy only, the situation is sort of like the rote transformation of the quadradic form a*x^2+b*x+c to its roots by filling out the formula (-b +/ sqrt(b^2-4*a*c)/(2*a)) : the code doesn't try to explain why it works, it just does it.

Automated integration involves a lot of pattern matching, examining the combinations of functions involved in a particular integral and consulting specialized tables or code to determine if a known case can be found and the answer filled out. It is not clear that it is meaningful to talk about "step-by-step" solutions of integration, though it is meaningful to hope there is a common name for the patterns that were detected.

To see how more about how the particular detected pattern is worked out, see for example this write-up over here

With older Maple, you can use

map(rhs,result);

with newer Maple there is an extension that allows you to express it as

rhs~(result)

However, notice that you are solving for a set of variables, and you are asking for the result to be expressed as a set rather than a list. That has occasional use, but you are more likely to want the results to be ordered. You can get the ordering by using the technique others have mentioned,

eval([x,y],result);

though that can have some subtle side-effects due to the additional eval(). But you can also get the ordering using the map(rhs) or the rhs~ if you change to [x,y] as your variables instead of {x,y}

result:=solve({x+y=1,x+2*y=4},[x,y])

e.g.,

result := rhs~(solve({x+y=1,x+2*y=4},[x,y]);  #newer Maple

or

result := map(rhs,solve({x+y=1,x+2*y=4},[x,y])); #older Maple

Your worksheet has

theta[3] := 0;

and then you construct some equations, and then in your list of initial conditions to fsolve you include theta[3] = 0 . The assigned value of theta[3] is going to be substitutied into that "theta[3] = 0" giving an expression of "0 = 0" in your initial conditions. That is not valid.

If you assigned a fixed value to a variable, then do not include that variable in your list of initial conditions -- just like you did not include theta[0] in your initial conditions after having assigned a fixed value to theta[0]

Asking about the curvature of discrete data is like asking about the colour or age or weight of the number 7. Discrete data just is, a set of scalar values without meaning.

In order to get any meaning from a set of discrete data, you need to impose an interpretive model on the data. Perhaps the data is to be interpreted as not merely discrete but also ordered, and perhaps the order imposes a implied second dimension such as that adjacent measurements are a particular distance apart on the x axis. Perhaps subsequences of 6 adjacent values are to be interpreted as 6 space-time coordinates. Or 10 adjacent values. Or 11 adjacent values. Depending on which quantum model you are using.

Even if you can group the discrete data into explicit or implied coordinate systems, you still need a model of what the data represents. There is nothing inherent in discrete data that requires that one interpret it as representing measurements over a "smooth" surface. Perhaps there are multiple adjacent "smooth" surfaces. Perhaps the surfaces involved are rough surfaces. Perhaps the surfaces are smooth but have changes of large magnitudes in-between measurements.
For example, suppose you happen to sample a simple sine wave at intervals of Pi. All of the measurements would come out the same to within the uncertanty of measurement. The "obvious" interpretation would be that the curve involved is a straight line. But that is just because of the way you happened to sample it.

Whenever you have discrete data, you must assume that even if it represent measurements of a function with a continuous first-order derivative (or even continually continuous, continuous at every derivative), that there might "rieally" have been any number of huge changes in the function surface in-between adjacent measurements.

Given any discrete set of data, there is an Aleph-1 (infinity of the real numbers) of different possible continually-continuous functions that fit the measurements perfectly. And that's even assuming that the discrete measurements were infinitely precise: if there is any uncertainty in the measurements, then the only reason there would not be "even more" possible functions is that there appears to be no infinity larger than Alelph-1.

Unless, that is, you have have strong reason to impose a model on the data that constrains the behaviour of the "actual" function between the measurements. If you do have such a model, then you need to know about the parameters of that model in order to be able to fit a line (or surface) to the discrete measurements and thereby complete the model that would allow you to calculate curvature near the discrete measurements.

You might ask to fit a polynomial to a set of data. If the polynomial you are using is more than 4th degree you should be questioning what you are doing, and if the polynomial you are using is more than 7th degree you should be treating the answers as "For Amusement Only" and probably of less value than if you had asked the Magic 8-Ball .

You mght also ask to do a "cubic spline fit" of the data. Cubic splines are a class of curves that humans find "nice". I argue that unless you happen to know ahead of time that your function is suitable for use with cubic splines (e.g., the data represents ergonomic measurements where the question is what humans would prefer) then it is a category mistake to use cubic splines to try to calculate curvature. Some mathematicians disagree with me on that, but I have not found their arguments convincing.

If the task involves computing the boundaries of surfaces which have been sampled by point clouds, such as laser scanners or Microsoft Kinect, then a useful technique is Alpha Shapes.

The "curvature" of discrete data has no actual meaning. Fitting data to a model and then measuring the curvature at the locations under that model does have meaning. Fitting data to a model curve is the field known as Curve Fitting. There is a Maple CurveFitting package that may be of use.

Example:

L := [9, 2, -3, 4, -3, 4, 4];

with(ListTools):
T0 := [Categorize((p, q)-> L[p] = L[q], [$1..nops(L)])]:
T1 := map(v->L[min(v)] = sort(v), T0):
OUT := sort(T1,(p,q)->lhs(p)<=lhs(q));

The result is

OUT := [-3 = [3, 5], 2 = [2], 4 = [4, 6, 7], 9 = [1]]

In the tests I did, the first sort() step was not necessary, but I saw nothing in the definition of ListTools[Categorize] I did not see any reason that the values would be ordered. If you want to dare to count on them being ordered then you can use

T1 := map(v->L[v[1]] = v, T0):

MATLAB's ic output would correspond to

ic1 := map(v->v[1],T0):
ic := sort(ic1, (p,q)->L[p]<=L[q]);

or if you want 'legacy' functionality, map it v[-1] instead of v[1].

In your update loop, you do things like

  In[i] := In[i-1] + 1;

which is fine in itself, but you are forgetting to propagate In[i-1] to In[i] in the other cases, so the values being used are the ones that were initialized using the Fill(). Try

S[i] := S[i-1]:

Rec[i] := Rec[i-1]:

In[i] := In[i-1]:

before the "if i > 0"

You could then also consider changing the code inside the "if i>0" to (e.g.)

In[i] := In[i] - 1;

as the In[i] will have been copied from In[i-1] before the "if"

Which MS WIndows version are you using?

See a Windows 7 solution over here .

For a longer write up that shows up to use the Windows SxS tracing utilities to repair individual programs (e.g., maple), see this page over there

@Preben Alsholm showed some syntax corrections.

Beyond that, I would also point out that you are mixing exact quantities such as Pi and 3/4, with fixed point quanties such as 0.1 and 0.19, with floating point calculations such as y^1.5 . The fact you are using solve() means you want an exact solution, but the 0.1 and y^1.5 and so on "contaminate" the solution finding making an exact solution difficult. When you have this kind of contamination, solve() is often unable to find answers, and the answers it does find not infrequently fail back-substitution and are sometimes spurious (e.g., finding a real root of an equation that provably has no real roots.)

In the matter of y^0.5 and x^2.5 and so on: in Maple, when there is a fixed point or floating point power in an exponentiation, rather than a rational power such as 1/2 or 5/2, then the operation is defined in terms of the "principle root", y^n evaluating to exp(n * ln(y)) , and the operation is defined as taking place in floating point (and so subject to the Digits limitations.)

Try this experiment:

cu := r->r^3.0: curr := r->r^evalf(1/3): c := r->cu(curr(r))-r: plot(c,0..1);plot(c,0..100000);c(100000);

In the first plot you will see random noise both negative and positive; in the second you will see that the trend is more and more negative and that the range of the noise gets greater and greater. By 100000 the discrepancy has grown to -0.00010 .

If you try the same plot with rational exponents, the output will look similiar, because plot() is going to be sending floating point numbers into the calculations. But any one rational point you evaluate at such as 100000 will have 0 discrepency. For finding exact solutions, you can't have any discrepency.

Thus, if you want to use solve() because you want exact solutions, you should change all of the literal numeric constants to rational numbers, leaving the named constants such as Pi unchanged. Or you should switch to using fsolve() instead of solve() -- and even if you do that, you should be giving some consideration to what you want expressions such as Pi + 0.1 to mean in your calculation.

When working with fixed-point constants or floating-point numbers, remember that Maple treats fixed-point constants as indicating that floating-point calculations may be used.

And always remember that floating-point calculations are non-associative and non-distributive, so if you are operating on them algebraically instead of procedurally, you are making a mistake of domain.

In the case above, switching to rational values and using solve() may take rather some time to complete. But whatever it does produce will be correct. If you can wait that long. Might be very long though...

In OS-X, the installer pop-up that tells you to install the legacy Java includes a link. Follow that link to get the legacy Java, download and install it. Maple will use that version and nothing else will be affected. You do not need to uninstall your other Java versions.

You missed the assignment operator in creating PDEs . You have

  PDEs = [.....]

but need

  PDEs := [.....]

When you try with that, you will find that pdsolve(PDEs) quickly returns empty. You will need to work numerically. And in order to do that, you will need to supply initial conditions as well as the 'numeric' option

pdsolve(PDEs, ICS, numeric)

for some set of initial conditions.

If you use the "numeric" option but leave out the initial conditions, you might get a confusing message about invalid subscript inside of pdsolve/numeric . The solution is to add the initial conditions.

mylist := [-1 $ k];

after that you can store to the elements. Efficiency is not going to be a major consideration for exercises that impose constraints on your approach.

If efficiency is a concern and you are required to use looping, then you can use a different data structure, such as

mylist := Vector(k);

then store to it as needed. If at the end it must specifically be a list, then

mylist := convert(mylist,list);

You can use a variable as a subscript.

  L := [2, 4, 6, 8, 10];

  K := 3;

  L[K] := -2;

  L;

The index expression can be calculated. For example,

  L[mod(J,10)+1] := 5; 

In this particular usage case, and accepting some limitations on the pattern matching, I can make do with

sscanf(TheString, StringTools:-Repeat("%*[^%]%c%d", 9));

or change the %c to %% if I just want the numbers returned without the %.

This code version fails if there are any % not followed by a number, such as "The price went up 5%"

There are a few things to check.

First, use the View menu to ensure that Context Bar is enabled.

In the status line just underneath the worksheet tab list, ensure that you have Math selected and not Text or Drawing or Plot or Animation. Then in the line underneath that, the one that gives you choice of font and font size and so on, in the left-most choice bubble, be sure that you have chosen one of "C 2D Input", "C 2D Math", "C Code", or "C Maple Input", and then type your command and press return. And just to be sure (thinking back to a reported problem), press return again if the first one does not work.

You could also go under the File->New menu item and specifically select Worksheet, and try with that, and Document and try with that. In Document mode you will not normally have a command prompt.

If that does not work, please go under the Maple menu and ask for Preferences, select the Display tab, and tell us what you have selected for "Input display" and also for "Typesetting Level"

For a more advanced check, to see if something is being done but just not showing up, you can do this:

View->Palettes->Expand All Docks

View->Palettes->Show All Palettes

View->Palettes->Collapse All Palettes

now look for the red-marked Variables palette and click on the title to expand it. You will see in there an area labled with "Variable Value" but that area will be empty to start with. Now in the command area, enter the command

Q := 5

and wait very briefly. If the variable Q shows up in Variables Palette then your engine is okay but your display is getting lost.

(Note for others who might happen to read this: if you have some long long numbers or expressions stored in variables, then each time you make an assignment, it might take the Variables Palette close to a minute to update! But this does not occur if all you have is short variables; the delay has to do with the time taken to internally format huge numbers or expressions.]