@vv

My mistakes:

•  You also have a syntax error in f()  [a ":" after proc()  not accepted in 1d].
  Appologies, I rewrote the content of a pdf file; in the code the ":" are not present after proc()
  (furthermore it generates an error if there is a delcration statement after the "proc" line, for instance local ....)
   
• I effectively made a mistake by tipping args(k) instead of instead of arg[k] (furthermore I knew the sorrect syntax
  Strangely it seems to be correctly interpreted by Maple 2015: printing the quantity named "objet" returns the correct name
   
• Last but not least: One more time I have forgotten that names constructed with "||" are global !!

Then the answer is: either I use the awfull sequence
    if n=1 then print(Object1)
  elif n=2 then print(Object1)
  …
  end if

or either I construt a list ObjectList:=[Object1, ...ObjectN] and a list ListA := [A] and I do this

 Choice := proc(a::list)
  local n, object:
  n := ListTools:-Search(true, a):
  object := ObjectList[n]
  print(object):
end proc:

Thank's for your answer, even if it is not always pleasant to be remembered we are an airhead !

@tomleslie 

"  The advantage(?) of doing it this  ...": right, it seems a better (the only one?) way to manage "pseudo axis"
 

By the way: I did a mistake in my original post.
I wrote

• the empirical marginal distribution of X (Histogram), put below the line "y = min({y[n], n=1..N} )" and rotated by 180 degrees

In fact I should have written:

• the empirical marginal distribution of X (Histogram), put below the line "y = min({y[n], n=1..N} )" and SYMMETRIZED around the x axis

A simple task to do with plottools:-transform
reflection := plottools:-transform((x,y) -> [x, -y])

From now on the two histograms are placed correctly by using only plottools:-transform ... you deinitely gave me a good advice.
 

@ThU

It's good enough for me.

By the way, where did you find this stylesheet = [vertexcolor = "White",vertexborder=false]) info ?

Thanks again

@ThU 

Correction: CTRL+J doesn't work.


Thank you anyway
 

@ThU 
"Do you mean the vertical bar at the location of the cursor? " : Yes,

The problem is now solved (see my previous "auto-answer"), but I'm keeping by my side your "control-J" trick ... for the last time.
Thanks for the answer

1. I opened the worksheet "W"  with an older Maple version (Maple 2015): it contained the vertical location bar
2. I saved it with another name
3. And finally opened this new fir with Maple 2018 ... and this bar was miraculously restored !!!

I let the people in charge of this site to decide for themselves  if this question/auto-answer must be retained or removed

@Carl Love 

I give up : I DON'T KNOW HOW TO DO AN OBJECTIVE COMPARISON

I used your last version of NimMatrix with parameters 5, 5  (NimMatrix(5,5))

Procedure 1 :
 T := NULL;
for r from 1 to 100 do
   T := T, CodeTools[Usage](Code(...), output=cputime)  # from your answer to the "other" thread
end do:
add(T)/100

Procedure 2 : (from acer's suggestion)
 CodeTools[Usage](Code(...), output=cputime, iterations=10


Results
  indicator                Proc 1                   Proc2            

 cpu time/run             16.9 s                     32.75 s             

memory size            0.95 GiB                  0.95 GiB

I repeated this twice and obtained the same ratio of 2 between the cpu times.
For proc1 the 10 times range between 15.49 s and 18.08 s

For "My best code" chich uses no sophisticated material nor the option remember, the cpu times are the same (up to unavoidable fluctuations) with proc1 and proc2.

Then : what is the cpu time (16 s or 32 s) I have to take to do an OBJECTIVE comparison ???

 

@acer 

Thank you acer.
I've read the help pages but I missed apparently this "iterations" option
 

@Carl Love 

Procedure used to evaluate the cpu time (see my brevious reply)

T := NULL;
for r from 1 to 100 do
   T := T, CodeTools[Usage](Code(...), output=cputime)  # from your answer to the "other" thread
end do:
add(T)/100

CONDITIONS : BASE = 5, K = 3 (==> NimMatrix(5, 3))

The results (Maple 2018 / Windows 7) are
"NimMatrix lastversion"    14.35 ms / run
"NimMatrix first version"   23.56 ms / run
"My best code"                         46.90 ms / run

@Carl Love 

It works well in Maple 2018.
I did probably some mistake when I used this with the older Maple's versions
(I guess you're going to think I'm familiar with that...)

@Carl Love 

I tried this but it didn't work (I used Maple 2015 ... or maybe 2016 ?)
I'm going to try again with Maple 2018 newly installed on my PC.

BTW : I just sent you two replies on the "unconventional addition" thread

Thanks

@Carl Love 

I did not want to sound offensive.
Put all this on blunders due to the fact that English is not my native language. Words do not have the same harshness from one language to another.

About the way I stated the problem there are, I agree, a lot of things to say and I recognize willingly that I should have done better

And don't go thinking that I'm one of those people who never admits to having made an error.
I can ensure you I never thought this about you

So, I'm sorry if I have hurt you.
Leave it there and recieve my apologies
 

@Carl Love

CodeTools[Usage] being rether inefficient to estimate the computational time (see my new question), I did this

t0 := time():
for r from 1 to 100 do   Code(...) end do:
time()-t0;

where "Code" is one among "NimMatrix first version", "NimMatrix last version", "My best code"

CONDITIONS : BASE = 5, K = 3 (==> NimMatrix(5, 3))

The results (Maple 2018 / Windows 7) are
"NimMatrix lastversion"     1.529 s  ---> 15.23 ms / run
"NimMatrix first version"    2.371 s  ---> 23.71 ms / run
"My best code"                         5.273 s  ---> 52.73 ms / run

As you've seen earlier my first comparisons where made by using CodeTools[Usage].
I tried the same here, running 10 times each of these codes and doing a restart before each new run. 
The cpu times I obtained for
"NimMatrix lastversion"     32, 63, 31, 62, 63, 32, 78, 54, 63, 63
"NimMatrix first version"    63, 47, 62, 47, 46, 47, 78, 47, 62, 46
"My best code"                         62, 78, 78, 78, 63, 62, 62, 31, 78, 78

I didn't compute the means of the CPU times but a lot of things may be observed :

1. The times vary in a relatively large ratio (~2.5 for "NimMatrix lastversion"  or "My best code")
2. CodeTools[Usage] seems to deliver rounded values (strabge it is that 78 or 63 appear many times)
3. The times are roughly speaking the same and no evident ranking can be deduced from them (even if tendencies can be infered)
4. The times are significantly larger to those obtained by the first method (which returns the real time, necessarily larger than the CPU time)

I guess that the strong differences in the results produced by the two methods comme from the fact that the first one (r=1..100) does no restart between each run.
My code doesn' use any remembre option and is probably less sensitive to the lack of restart (besides you may notive that
52.73 ms/run is not, off the top of my head, far from the mean of [ 62, 78, 78, 78, 63, 62, 62, 31, 78, 78]).

 

@nm 

I agree.
In fact there are many ways do realize this addition.
At the beginning I thought that some bitwise operations existed in Maple, but I failed to find them.
Then I decided to do may own coding and faced the problem of lists (a and b) of different length (typically I need to compute "A plus B" for each pair in {0..3^n}^2, [of course the relation "A plus B" = "B plus A" halves the number of operations)

I first wrote something more or less the same than your solution  (maybe a little bit longer) and I found it too complicated for it used ListTools[Reverse] too.
This why I have come to use a polynomial representation (my " pa := add(a[k]*x^(k-1), k=1..numelems(a))" ) .
But this looked rather "artificial".
Using gfun seemed promising because the coding was even shorter ... but I faced some difficulties at the last steps.

The key of your solution lies in the line c := parse(cat(op(a)))+parse(cat(op(b)));
A more astute way to handle lists of different length than using polynoms.

Thank you for your answer
 

@acer 

Absolutely right!
I'm ashamed not to have think to that myself :-(

Of course the few questions I posted here are just a part of a more general program but your proposal could answer them.

Than you acer