This is an extension of the problem first posted at

http://www.mapleprimes.com/questions/221422-Stuck-In-Finite-Difference-Method

The remaining problem with the original postwas that everything dependent on a variable p[i], which was undefined (and p[i+1] was defined in terms of quantities which could not be determined, and assignments became recursive)

Since OP has now come up with a definition for p[0], and then p[i+1] in terms of p[i], I have revised my original response in order to calculate all of the relevant information, as attached

finDef2.mw

Somehow I doubt that this is the end of the OP's issue. The code (s)he presents, plots p[i] (as dependent variable) against u[i] (as independent variable. This is perfectly plausible but just looks unlikely from  the structure of the code presented.

Furthermore the OP headlines this question as

hello, i just try to plot the relation between my outputs (u, and phat) with i from 0 to 10 , but i have a problem any suggestions? 

and then plots p against u, which is OK I guess - except it "sort of" implies that p is an output and u is an input - with no mention of phat. So what is an "input" and what is a output? Note that this is not difficult, p, phat, u, are all now determined, so any of these could be plotted against any other (or indeed against their common index variable.

But anyone who can figure out what the OP really, really, wants has more insight than me!

The worksheet you uploaded does not produce the answers you claim - in fact it fails with the error message

Error, too many levels of recursion

on the second iteration of the for loop - which, looking at your code, doesn't really surprise me. Please only supply code which exhibits the problem you claim is happening.

Despite the advice I provided last time, you are still not explicitly calculating p[i+1], and everything goes downhill from that point

Well there are several problems caused by the variable names which you have adopted. As a general rule, don't use spaces in variable names. (It is possible to do this in Maple - but often leads to problems, so it is just better to avoid the issue). This naming problem is (probably) exacerbated by your adoption of 2-D input mode, which adds an extra level of expression parsing.

In order for you calculation to sensibley progress, it would seem that you need to define/update the quantity the 'p', so that p[i+1] will evaluate to something. In the attached I have just "made up" a definition for this, just to get everything working

finDef.mw

Let's just say that none of these software packages exactly shout about the fact that the underlying "engine" is lapack/blas - for obvious reasons

The attached will "find" the first numeric entry in a line. All prior entries will be concatenated as a string- ie one column in the output,. All numeric entries will also be columns in the output.

But at least this time you do not even have to specify how many "columns" of output data you want

readParse2.mw

Once again you will have to modify the path/file names to something appropriate for your machine. It will run with the same two test files I uloaded previously

Excerpt from the help on ImportMatrix(), with my embolding

delimiter=s Specify character that separates entries in the file, where s is a string containing  a single character

Which part of 'a single character' is difficult to understand?

Given a "single character" such as tab/space/comma whatever - then you can use ImportMatrix(). However in your original data file, there is no "single character" which will provide the parsing you want

Your statement

" As you know the matrix calculations of the Matlab is more powerful than Maple"

is incorrect (unless you can prove otherwise).

For LinearAlgebra computations, both Matlab and Maple (Mathematica as well) use the same, *free*, linear algebra software libraries known as LAPACK and BLAS - check out the Wikipedia entries for these.

Now none of Maple/Matlab/Mathematica want to admit that they are all using identical underlying software (ie LAPACK+BLAS) for linear algebra computations. After all, why wpuld you pay for Maple/Matlab/Mathematica, when you can download LAPACK+BLAS and use it for free!

So are there discrepancies - well yes. Both Mathematic and Maple allow arbitrary precision floating point numbers (which Matlab does not). Both Mathematica and Maple will certainly invoke various argument-checking routines in order to determine how calculations should be performed. Matlab will not do this becuase  (by default) it just uses "standard" double precision. However one can construct problems in both Maple and Mathematica (typically by requiring the use of hfloats) which will then be "equivalent" to the Matlab calculation - with the result that calculations in all three packages take about the same time, because they are all using the same underlying engine - ie LAPACK+BLAS

My original code didn't care how many spaces were involved - I may have tried your original data file on the basis of 5 spaces and found that it failed, then coded round it. To be honest I can't remember.

However an obvious shortcoming of my original code is that it is "hard-wired" for three columns of data. A minor revision will make it work for an arbitrary number of "columns". Although you now have to enter the number of columns manually. I siimply can't think of a bulletproof way to figure out whether you want

peppers red large 20 15 12

to be parsed as

"peppers red large",  20,  15, 12

ie four "columns", or

"peppers", "red", "large",  20,  15, 12

ie six "columns" or even

"peppers red", "large",  20,  15, 12

ie five "columns.

So what the attached actually does when you specify (say) four colums is to assume that the last three (space separated) entries are definitely columns. Whatever is left will always be concatenated into a single column, So, for example, if you set nCols=4

peppers red large 20 15 12

will be parsed as

"peppers red large", 20 ,15, 12

On the other hand if you set nCols=5, then

peppers red large 20 15 12

will be parsed as

"peppers red", "large", 20 ,15, 12

Try the attached code and the two example files - obviously you will need to revise the path/file name to something appropriate for your machine

readParse.mw

testdata.txt

testdata2.txt

This ODE system is trivial to solve, either on the back of my cigarette packet, or with Maple, as in

restart;
odes:=[diff(v(x),x)=0, v(x)*diff(u(x),x)-diff(u(x),x,x)+1=0];
ics:=[u(0)=0, D(u)(1)=0, v(0)=0];
solv:=dsolve([odes[1],ics[3]]);
dsolve([subs(solv, odes[2]), ics[1..2][]]);

This is essentially the same logical process as posted by Markiyan Hirnyk.

So the obvious question arises - why does Maple provide an "incomplete" solution, when supplied with

restart;
odes:=[diff(v(x),x)=0, v(x)*diff(u(x),x)-diff(u(x),x,x)+1=0];
ics:=[u(0)=0, D(u)(1)=0, v(0)=0];
dsolve([odes[], ics[]]);

Unlike the post by Ian Thompson, I cannot imagine why v(x)=0 would be regarded as "a special case", by me (or Maple)

The only(?)  slightly special feature of this ODE system would seem to be that one of the ODEs can be solved independently of the other. However, if one simply changes the boundary condition to v(0)=1, then either

restart;
odes:=[diff(v(x),x)=0, v(x)*diff(u(x),x)-diff(u(x),x,x)+1=0];
ics:=[u(0)=0, D(u)(1)=0, v(0)=1];
solv:=dsolve([odes[1],ics[3]]);
dsolve([subs(solv, odes[2]), ics[1..2][]]);

or

restart;
odes:=[diff(v(x),x)=0, v(x)*diff(u(x),x)-diff(u(x),x,x)+1=0];
ics:=[u(0)=0, D(u)(1)=0, v(0)=1];dsolve([odes[], ics[]]);

will work (and give the same answers). So the "independent ODE" argument would seem to be irrelevant.

So what specifically about the original ODE system, causes Maple to provide an incomplete solution, when a complete solution is trivial.

Since you are displaying everything on the same plot the rather obviously you can only have one scale for the vertical axis.

For your case this will largely be determined by the scale of the Histogram() plots.

To generate a "simple" histogram you need to use the option frequencyscale=absolute.

The default is frequencyscale=relative, which means that the heights of each 'bin' are scaled so that the sum of the areas of all bins is 1. When frequencyscale=absolute, you are essentially forcing both the bin widths and bin heights, so that the sum of the areas of all bins will not be 1

Since the KernelDensityPlot is an "attempt" to produce a probability density function, then (rather obviously) the integral under this curve will be scaled to 1.

Thus if one uses Histogram with relative scaling, then since the area of the bins is scaled to 1, one might expect this to match the KernelDensityPlot which has the same scaling. However, for your case, note that the KernelDensityPlot produces 'peaks' which are substantially lower and wider than the corresponding entries in the Histogram.

This is a reflection of how well ther KernelDensity command can actually 'match' any given set of data samples.

It is quite informative to leave everything else the same and play with the bincount option in your command sequence

H:=Histogram([PhiA,PhiB],
              bincount=20):
K:=KernelDensityPlot([PhiA,PhiB],
                  color=burgundy):

well I've tried a few of the usual tricks, and can't come up with anything which will provide an analytic (ie exact) solution. Not saying that such a solution is impossible - just that I can't finid it.

On the other hand, plotting the integraand over the required range, using

restart:
expr:=1/ln(1+1/x);
plot(expr, x=0..2);

shows that the integrand is reasonably well behaved, so I would expect a numerical evaluation to be pretty accurate, and

int(expr, x=0..2, numeric);

returns 2.848438450.

Maple's identify() command is quite useful for working out whether some arbitrary float can be derived as some combination of "plausible" values such as 'e', 'Pi', sqrt(2), sqrt(3), whatever - but in this case returns nothing useful

I'm tempted to believe that this integral has no analytic solution :-(

From the list you present, it seems as if you must have some method of generating the position of (say) body1 for all time 't'. In other words you can set up functions for the position of this body as [x1(t), y1(t), z1(t)].

If you can, then the simplest way to plot the trajectory of this body woulld be to use a 'spacecurve', as in

p1=plots:-spacecurve([x1(t), y1(t), z1(t)],t=0..100, color=red):

do the same for bodies, 2..4, to produce plots p2,..p4. Then 'display' these on the same graph using

display([p1, p2, p3, p4]);

It would be so much easier to figure out exactly how to do this if you had provided your worksheet (upload using the bi green up arrow in the MaplePrimes toolbar)

Load the function definitions/parameter set for which you say you get "part of the green function over y=x line "

when I attempt to access the supplied link

Pe.maple

all I get is a new browser page which states

The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.

In your expression

on which side of the equation does the Einstein summation convention apply?

To ask it a more simple way, you want A[i,j]*B[m,j] on the left hand side of this equation to mean something enitrely different from the term A[i,j]*B[m,j] on the right hand side

When you decide to adopt a notation convention, then it willl be applied everywhere - which is why I find the above "equation" mathematically meaningless. Think about it!