@radaar 

you are happy using hardware floats

@Kitonum 

Looks like the result of a call to

kerneopts(memusage)

I'm not sure how useful this is for checking the usage of a specific calculation - I think it just returns the total usage of all currently known Maple objects, broken down by object.

This may (will?) be substantially different from the amount of memory used during a specific calculation, for which the CodeTools:-Usage() approach is probably a better representation

@bmartin 

Is available from (what appears to be) the authors' academic web-site. See entry (39) at

http://depts.washington.edu/maple/publications_new.html

is - why do you want to do this???

Alternatively - what part of the attached causes you a problem?

Download spStep.mw

@Preben Alsholm 

see the attached

Download docMode.mw

My general advice for problems of this nature is always

1. Put the restart statement in its own execution group
2. Don't use 2D input
3. Don't use document mode

@Jalale 

Misuse of terms in comments - I'm expressing probabilities as percentages, so a probability of 0.1 will appear as 10%. So if you add these with

add(j[2], j in pV);

the result will be 100, rather than 1.

If you want actual proabilities then change the calculation

probs:= [ seq
                ( [ j[1],100.0*j[2]/nT ],
                  j in vals
                )
              ];

to

probs:= [ seq
                ( [ j[1],1.0*j[2]/nT ],
                  j in vals
                )
              ];

@ciaran1996doyle
In the code block

for i from N-1 by -1 to 0 do
      for j to M-1 do
          f[i+1, j] := a[j]*f[i, j-1]+b[j]*f[i, j]+c[j]*f[i, j+1]
      end do;
      f[i+1, 0] := b[0]*f[i, 0]+c[0]*f[i, 1];
      f[i+1, M] := a[M]*f[i, M-1]+b[M]*f[i, M]
  end do

The left-hand sides of all the expressions define f{i+1,..]], with i varying from 0 to N-1; hence everything from i = 1 to N is defined.

Unfortunatley the right hand sides of these expressions contain f[i,...] with i varying from 0 to N-1. Now exactly where is f[0,..] defined????

This explains why your ouptu contains a lot of unevaluated terms, and every single one of the undefined terms is of the form f[0,..], because nothing of the form f[0,...] is ever defined

f[i, M] := a[M]*f[i, M-1]+b[M]*f[i, M]

Since f[i, M] is undefined when this line is executed, this constitutes a recursive assignment, which cannot be resolved

that might help!

Because the question (as posted) makes no sense to me at all

Several different people have responded to this question. I have added emphasis to their quoted responses

Acer said

I deliberately avoided mention the command DocumentTools[RunWorksheet] before, because I think that it is the wrong way to solve this kind of problem. It's not nearly as computationally efficient, nor nearly as robust, as the other things mentioned. It fosters the existence of suboptimally organized worksheets.

Dr Vengkat Subramaniam said

I believe a procedure is the best way to approach this.

I said

Enclose the original code in a proc()..end proc wrapper and call this procedure with loop index values.

One of us is definitely "prejudiced"

@vv 

I did consider the 2D issue, and I'm pretty sure that you are more-or-less correct, although

1. it doesn't address the whole issue of f(x) versus f(x+1) as separate definitions?
2. range specifications are still  wrong in multiple places. I actually tried a few ways in 2d input, to come up with '.. .' (thats 2 dots followed by a space, followed by another dot). Couldn't make anything sensible of it, in either 2D or 1D input

@Glowing 

"Surely I can run it over and over manually to get all the results, but I just wish to have a script or something to make this process automatically."

You can do it this way, inefficient, inconvenient and a right royal pain - but if you can live with it, then I don't have a problem. If yoiu want script to do it automatically then you will have to post the original worksheet

Therefore, DocumentTools[RunWorksheet]( )  seems to be the optimum option under such circumstance.

Of all the possible solutions, this is the about the worst.

It will work - it is just painfully bad. However since you refuse to post the original code and let someone fix it properly, I have to assume that you really like using bad code, and don't want anyone to fix it. This saves me about 15 minutes of work - which I suppose is good?

Since you have decided that DocumentTools[RunWorksheet]( ) is the desired(?!!) solution, then presumably(?) your problem is now solved.

Alternatively, upload (big green arrow in the toolbar) the original worksheet here, and someone will fix it for you (properly)

May have to include an explicit "return" statement in the proc - depends on which quantities you want to be "returned"

@Glowing 

Stating the obvious

1. Don't write code which is "inconvenient to execute multiple times
2. Having ignored (1) above, you now have to "encapsulate" the code somehow. The only thing which needs to be determined is the "best" method of converting what you have, to what you woud like. Without seeing your code, it is tricky to be definitive, but if you actually posted your worksheet, I would probably do something like
   1. export the worksheet as an  .mpl file
   2. in an external text editor, top-and-tail the code with proc()..end proc statements so that one can pass the necessary argument(s)
   3. read() this (modified) mpl-file into a new worksheet. This will produce a lot of warnings about variables being implicitly declared as local. (If necessary/desireable this can be fixed with a bit of cut-and-paste in the external text editor)
   4. Write a simple for-loop (or seq) which executes this procedure over the required index values - this is a on-line command
3. Without seeing your worksheet, it is difficult to be certain, but I would estimate that the above process (minus the execution time) above would take between 5 and 10 minutes to set-up