@Rouben Rostamian  The command InertForm:-Parse will take an infix expression entered as a string and return an equivalent prefix expression (not as a string). That's most of the work. From there, you can change all `%+` and `%*` to exactly two operands per operator, move the operators to the ends, and remove the parentheses.

I just have some quick and immediate thoughts about this. It's been less than 5 minutes since I started reading this post, so my ideas are not fully formed.

It seems that this RPN requires that each operator have a fixed number of operands. That means that a distinction must be made between unary negation and binary subtraction. These are different keys on most pocket calculators but not in the standard alphabets used for most computer languages, including Maple.

What makes you say that it'll speed up evaluation? I certainly see that RPN can speed up the manual entry of expressions. But all expression evaluations AFAIK are already done with stacks.

The term hailstone sequence is usually associated with the name Collatz. The classic example is

A[n+1]:= `if`(A[n]::even, A[n]/2, 3*A[n]+1), A[1] = any positive integer.

The Collatz conjecture is that for any given A[1], there exists an n such that A[n] = 1.

I don't know what you mean by double hailstone sequence.

@emendes a) The quantile function is simply the inverse function of the CDF. In this case, the CDF can't be symbolically inverted while it contains the parameter m. But for any given numeric value of m, a numeric inverse can be easily obtained with fsolve, like this:

fsolve(eval(Statistics:-CDF(X2, v), [m= 3]) = .95, v= 0..1);

     0.776393202250021

b) $ n simply means "make n copies." For example, x $ 5 is x, x, x, x, x. The unevaluation quotes that I showed earlier forces the expression to be re-evaluated for each copy, which in this case makes the distributions i.i.d.

Please upload your worksheet using the big green up arrow on the toolbar of the MaplePrimes editor.

If you copy and paste your code to a plaintext Maple Input region and then hit return, you may get a more informative error message.

@quo On the other hand, it's fine to independently assign values to m[a], m[b], m[a,b], m[], etc. Each of these has an effect on m, which is the parent table, but they don't affect each other.

(You can even dependently assign values to m[a] and m[b], as in
m[a]:= 1 + m[b];
m[b]:= 3;
though I don't recall ever having a need to do this.)

@quo The main problem with using an indexed variable such as m[a] is that you cannot independently assign values to both m and m[a]. Worse yet, if you try to do it, you won't get an error message; you'll just get incorrect results.

@rstellian I said that if you just wanted to draw samples, then a much-more efficient procedure could be used. Here it is:

Sampler:= (i::posint, x::posint)->
   subs(L= irem~([$i-x..i-1, $i+1..i+x] -~ 1, 100) +~ 1, R= rand(1..2*x), ()-> L[R()])
:
S:= Sampler(98,5):
['S()' $ 25]; #Sample size is 25.

@Markiyan Hirnyk As described in the example in the last sentence of the first paragraph of the original Question, the data points are 93, 94, 95, 96, 97, 99, 100, 1, 2, 3. The mean of these is 68. There is nothing to adjust.

Please change the title of your Question from "I really need your help, please" to something mathematical or scientific! That you need help is already obvious because you're posting a Question. Thus, the current title has very low information content. Thus, the post will likely be ignored by future readers.

Are you sure that you aren't missing something that's given in the original source of this problem? I can't imagine how this integral could turn up in any practical problem. You might as well integrate cos from -infinity to infinity: Clearly there is an uninteresting oscillatory divergence.                                           

I don't understand why there is an index-out-of-bounds error. On a quick read through of your code, I spotted the obvious mod bug, so I corrected that, which fixed the whole problem, so I just left it at that.

The index error doesn't occur if the code is run in native Maple.

You can access the C code by doing (in Maple), before compiling:

infolevel[Compiler]:= 3:

This will show you the name of the text file containing the C code. You can add some debugging print statements to this code and rerun it if you want. Personally, I'm happy with the proviso "Use irem instead of mod in compiled Maple code."

@pchin Is it possible for a user to simply turn off the Typesetting Rule that produces this error?

This situation that error messages may come from the Typesetting Rules opens up a whole new level of complexity in debugging Maple code. Since the errors can be avoided by simply suppressing the output (and then using lprint), this will often be satisfactory to the user. But it is difficult for the user to know at first that the error is coming from the Rule rather than their code! Here are two ideas to address this:

1. These error messages could be distinguished from regular error message by being prefixed with the word TYPESETTING.

2. The invocation of a Typesetting Rule could be wrapped like this:

try 
   whatever 
catch:
   if interface('typesetting') = 'extended' then
      interface('typesetting'= 'standard');
      userinfo(
         1, Typesetting, 
         "Typesetting (extended) error detected; resorting to Standard Typesetting."
      );
      whatever;
      interface('typesetting'= 'extended')
   else
      error
   end if
end try;

It is not necessary to have procedures in individual text files in order to do version control. I personally find that unwieldy (too many files). I like one file per module. The way that my brain works in comprehending computer code, I find that about 500 lines per text file is ideal. My ideal maximum size for a procedure is what will fit on a single screen using whatever editor/monitor combination that I'm using. I often have a lengthy comment (10 - 20 lines) at the beginning of a procedure. I don't require that this comment fit on the same screen as the procedure.

Edit: I removed my remark that Git supports syntactic colouring for Maple. I was conflating it with vi and its derivatives, which do have the colouring.

@Kitonum Thanks for the correction.