@Preben Alsholm 

Thanks Preben

@vv 

@tomleslie 

@Carl Love

Thank you all for all for all your contributions.

I also undertood that the format of the files is not neutral, nor even their order of creation


The first reply from vv made me questioned myself about the results returned by addressof.
I didn't know of this command and I did a few things around my initial issue.
They are summarized in the attached file

Basically:

1. To refer to the last vv's reply...
   Yes the addresses of A, B, and C are different (please look to the code below).
   But as B:=eval(A) makes a strong link between A and B, I could have thought the their adresses would have be the same (contrary to those of A and C:=copy(A)).
   The fact that changing one ientry of A (B) modifies accordingly B (A) seemed to advocate this intuition.
   I was definitively wrong
   
   PS: for those of you who know FORTRAN; there was a statement named EQUIVALENCE, which enabled to access the same memory location through different names
    
2. Strangely for me, the adresses of A[n], B[n] and C[n] are the same for each index n (please look the code below)
   Why this?
   Could it be that addressof(A[1]) does not return the address of A[1] as I was expected for?
    
3. Plus a few auxiliary quesions  you will discover by your own
    

If you get a little bit of time, could you be kind enough for enlighten me about the few points I raise here
Nothing critical for me, just the desire to understand a little bit more deeply how MAPLE works.

Download AboutTables.mw

@tomleslie 

Thanks Tom for your help.
Filtering the original matrix was not my primary intention but it could be useful in the future.
 

@Kitonum 
Thanks

@Carl Love 

indets(a, specfunc(VIEW))[]; is indeed a more general way to get the information
Thank you

@Carl Love 

This is a workaround. Do you know what that means? It is not a denial of the existence of a bug! It acknowledges the bug's existence and provides the user with an easy and practical way to "work around" the bug until it is fixed.

Yes, I know what a workaround is. It can be used in any of these two situations:

1. You face a Maple impossibility to do a specific operation and you replace it by something else.
   Nothing can answer to all issues, every product, here a Maple, has its own limitations and using it beyond its frontiers may require workarounds.
    
2. You face a bad behaviour of Maple, let's say a "bug", even if it is a taboo word here, and you proceed otherwise to avoid the bug.
    

The main problem with the most part of workarounds published here (a significant part of all the replies), is that the op doesn't know if they are proposed to help using Maple out of its application domain, or to circumvent a bug (as a rule workarounds are not explained ... even if you are among those that constitute an exception).
Given the taboo character of this word, there seems to be a collective denial to their existence, which, for me,  is definitely unbearable.
For many years I develop computational codes and I face, as anybody does too, user feedbacks about bugs. I'm not ashamed at that.

This is why I'm happy to read from you  It is not a denial of the existence of a bug!
Not so often acknowledge here.

After my reply to the first vv's answer you wrote  I suspect that you didn't type his commands into your Maple 2018
What vv proposed was this
         restart:
         with(Statistics):
         N :=3; 
         X := RandomVariable(Binomial(N, 1/2)):
         F:=CDF(X, s):

It solved nothing at all as it is confirmed by the the attached file (or I did some mistake in this file I'm blind to find), so I'm not sure you were right in saying I suspect that you didn't type his commands into your Maple 2018

Major_Hassle.mw


Far from any controversy now.
But I think that Vv is right about you: You're more interested in arguing than getting practical information on how to use Maple
About my propensity of arguing ...  you can be right. But, on the other side, if the substance of the discussions could let me think that there was no denial to recognize the existence of bugs, I would be  probably less vindictive.
 

PS: Your memory is better than mine for I do not remember what my first post was.

@acer 

First of all: thank you for these "dispassionnate" answers.

I have a few questions ad remarks:

About your first reply:

1. F := value(CDF(X, s, inert)) returns a more credible expression than CDF(X, s): do you intend to modify the CDF procedure in order that it will do this automatically?
   All the more that, if I'm not mistaken, there is no advice in the help pages to proceed the way you did.
2. F := value(CDF(X, s, inert))  is close to the Maple 2015 output of  CDF(X, s) .
   Nevertheless  some discrepancies remain :
   1. value(CDF(X, s, inert)) explicitely tells nothing about what happens beyond s>3 (contrary to Maple 2015).
   2. The upper summation bound is no longer floor(s) but s, even if it seems to be exactly the same thing, why this change?

About your second reply:

1. F := CDF(X, s) assuming s <= 3 doesn't suit me for it implicitely tells that the CDF is not defined for values of s strictly greater than 3.
    
2. Given the fact that PDF(X, t) is a linear combination of "Dirac functions", the computation of the cdf through the command   cdf := int(P(X, t), t=-infinity..s) provides a linear combination of Heaviside functions (exactly what Maple 2015 does too).
   So, why does this Psi function come from ?

Finally

1. Do you think of recovering the old Maple 2015 CDF procedure ?
    
2. For my sake, would you qualify as bug the fact  CDF(X, s) is not returning a proper expression?

CDF of Binomial(6, 1/2) is OK  but not CDF of Binomial(6, 1/4) 
The step at location [0, 1[  (or ]0, 1] because french and english customs do not agree on this point) is not present!

X := RandomVariable(Binomial(6, 1/4)):   # or Binomial(6, 0.25) if you prefer
F := CDF(X, s):
plot(F, s=-1..7, discont=true, gridlines=true, axis[1]=[gridlines=7]);


The CDF has an uncomprehensible form invoking the Psi function. 
Could anyone from the development team restore what was done in Maple 2015?

@acer 
I'm so sorry acer for not having replied sooner.
After this inexcusable delay I greatly thank you for all these precious informations.

@vv

Thanks vv. 

By the way: limit returns infinity ... It would have been better to recieve a FAIL or undefined answer

@acer 

Very good!

Do I "want additional aspects like color, or fonts/color/weight on 2D Math"? Surely!

By the way, I had thought using Typesetting because I had already saw a few commands using "mn", mrow", somewhere here.
But I wasn't able to retrieve them from the Typesetting help page: are these functions documented in some place?

This text corrected 20 miutes later ...
I've found useful informations from the example given in the InertForm[Typeset] help page!!!

Thanks for the help

@tomleslie 

Thanks Tom, this is indeed a good idea.

 

@Carl Love 

I just read your reply, thanks for the clarification.

@Carl Love 

Thanks a lot



PS: No hard feelings, glad to read you again

Hi again
(sand15 is my professional login and mmcdara my private one)

I've done this very simple test:

restart:
with(Groebner):
F := [ seq(randpoly([x,y], homogeneous), k=1..3) ];
G := Basis(F, plex(x,y)):
LeadingCoefficient~(G, plex(x,y));

The GBs are not reduced (except in exceptional cases)

I've tried to use other algorithms, for instance
G := Basis(F, plex(x,y), method=maplef4): 
(it seems that one can write maplef4 or "maplef4" ,  see the head of  showstat(Basis) where `method` is defined as type string ot symbol).
For all the methods I tested we obtain the same unreduced GB.

But, very surprisingly, you can write  
G := Basis(F, plex(x,y), method="WhatTheF.ck"):
and get no error message ??? 

@Carl Love 

Sorry for the last reply: the screen capture doesn't appear even if it was correctly correctly displayed in the preview window.
Il will try again when I am home

@radaar 

And I repeat too that your solution is {x(t)=sin(t), y(t)=cos(t)}
See also Preben's answer