@acer I think I need to digest all this material and begin working by myself.
Thank for your useful help

PS : examples/ProgrammaticContentGeneration does not seem to exist in Maple 2015 (I only have Maple 2015 at home) ... maybe you refer to Maple 2016 (2017) ?
If so it is not a problem : it will wait until next monday that I return to the office,
Have a good weekend
 

@acer ... they complete the previous ansver (rlopez) I recieved

The fact that  "DocumentTools package can be used to programatically generate GUI Tables that are formatted like a report" is very important for me.
So it only remains for me to plunge into this package.

Concerning the sticking point you raised  : LaTeX is not necessary if Maple provides something of a comparable visual rendering.

To say the truth I had begun to write "LaTeX within Maple" commands , for example (do not smile) :

MyText := "\\noindent
{\\bf Some Title}
":
fprintf(fd, "%s\n", Mytext).

It is technically possible but it is cetainly not a soft job !!!

I am sure your answer will prove to be of very great help

Thank you.

@rlopez ... it's already a good place to start.

Concerning yout answer : I use to use the worksheet mode (I had a few setbacks with the document mode).
By the way : I omitted to say that I would like to draw up the document "programatically"

I was not sure DocumentTools is the good package to use : your answer is precious.

Thank you again

@John May 
(PS : I asked the question from my office but I reply from home, so the difference in the connection names)

First answer : so simple, how could I not think of trying it ???

Second answer: Very astute : I had thought to use Optimization:-Maximise but I was stuck by the expression of the objective function to use. I will try it as soon as I am at my office.

Thanks for the advices, have a good day

@gkokovidis 
(PS : I asked the question from my office but I reply from home, so the difference in the connection names)

Thanks for the advice, I'm going to download the toolbox, have a good day

@vv  I don't agree about this causal relationship between sigma and Digits.

Here is my argument (maybe I'm mistaken ?)
The convolution product C(x) = int(f(u)*g(x-u), u=x - a..x + a) (a = k*sigma for some k > 0) can be re-written as 
C(x) = - int(f(x-u)*g(u), u = a .. -a).
What matters here is g(u) = Cste * exp(-0.5*(u/sigma)^2)  (f(.) is of order 1)
Furthermore the integration range is [-k*sigma, k*sigma] and thus g(u) always keeps values in [Cste*exp(-0.5*k^2) , Cste],  regardless the value of sigma.
So I do not think a small sigma implies a large value of Digits.
I suspect the value of k should be critical (probably some simulations could proove on infirm this inference). 

Nevertheless gkokovidis, ace and you are right : the value of Digits can help giving the "right" plot, just as your "convert-to-Heaviside" proposal does to.
But I think that the very reason of the poor results I obtained still remains to be found ... but is is another question for another time.


I express my sincere thanks to all of you for the time that you have taken

@vv ... doing some comparison and check performances.
Not that I don't trust you !
But because using this convert-to-Heaviside trick could have some interest in the app I'm currently developping

Thanks for the suggestion

@vv  ... which puzzles me because gkokovidis and especially acer had already given me a satisfactory, although (a priori) completely different explanation .

By the way, why do you say that `f*g` is expressed with the Direc "function" ?
I simply defined `f*g` := x -> int(f(x-u)*g(u), u=...) 

Thank you acer
 

@acer   this completes the workaround gkokovidis has just sent me.

Thank you for your explanation

@gkokovidis 

Great thanks to you.

@acer 

There is just a minor difference between you and me as shows the screen capture below : the eval(F) command
returns the content of procedure F.
But all the rest suits me perfectly well.

Thanks for your precious help

@vv , I am sand15 (now from home)

I understand your argument but disagree with it.
n! is the factorial function, defined for all strictly positive integers,  while Gamma(x) is another function buid as an extension, to the complex plane, of the factorial function.

The quantities Prob(X=n | X ~Geometric(p)) make sense only for n >= 0  : unlike the Gamma function there is no extension to the real field. So the command

ProbabilityFunction(Geometric(1/3), 5.1);

should return 0 from a pure mathematical point view.

Although correct, is it sufficient ?
I would prefer Maple returns 0 plus a warning to highlight that "n = 5.1" is an impossible event


Now, what about the answer 0.4215152817e-1 ?
Lets take the example of tossing a fair die : what do you think of a student who would answer a non null value when asked to the probability of getting Pi ? 
Probably that he/she does not really understand the concept of random variable ?
I think the same thing with regard to  " ProbabilityFunction(Geometric(1/3), 5.1) = 0.4215152817e-1 " ... no offense intended

(let us remark that Maple 2015.2 returns 1/6 when asked for ProbabilityFunction(DiscreteUniform(1, 6), Pi) , which is even more stupid)) 


When I say that discrete distributions are not correctly implemented in Maple, I do not say that all is wrong but that it is not satisfactory.
I think that many of the problems Markyian refers to, come from a mathematically incorrect specification of the Probability (Mass) Function for discrete random variable. 
Truth is :  if you are aware of this problem and have some basics in probability theory you can say "Oh, it is just a default I can live with"  ; but the position "it is absolutely unforgivable" is equally admissible


A few years ago I was developping an algorithm for constructing optimized design of experiments. At some point the algorithm requires to ramdomly select one column of a matrix. If all colums are equally likely, a simple way to do this is randperm(...)[1] ; another way is Sample(DiscreteUniform(..), 1)[1] (which is conceptually more satisfactory)
The former method works well, not the later because  Sample(DiscreteUniform(..), 1)[1] returns a real, not an integer (as expected) and the column selection thus fails.
More generally, getting reals when you expect integers may be very annoying.

Best regards

When I'm at the office I use Maple 2015 on a Windows 7 PC ; always in worksheet mode with classical Maple input (too more problems with the document mode).
The error you mentionned reminds me an arror I often encounter when I copy 2D code from Maplet help pages to a worksheet session : when I copy more than a single block of instructions, the result appears in 2D mode on my worksheet and the execution generates an error of the kind you obtain.
"My" solution : try to copy block by block (in yout example 3 blocks (1) : with(..) ; (2) maplet := ... ; (3) result := ...) and be sure that the result is in Maple input mode, not 2D mode.

For me it works ... no guarantee it will do the same for you
 

@Thomas Richard 

I apologize for the images, it appears simpler to copy manually the error message

But you're right, the first error si the one you mention

The second one is 
invalid input: indices received fResultTable["/Users/..../Desktop/OriginalFile.mw"], wich is not valid for its 1st argument t

@Christian Wolinski 


 Wolinski never die :-)