@raj2018 You have several for statements of the form 

for x in a..b do

I guess that you expect it to choose some numbers between a and b? But it doesn't: It only uses x=a and x=b. How many numbers do you want it to use? Do you want them evenly spaced?

@sursumCorda In native Maple, initializing arrays with the functional form of initializer is faster than using a loop. I used the loop because you're not allowed to create arrays in compiled code.

The reason that your code is slower is the repeated formation and garbage collection of expression sequences for multiple-assignment statements such as

x,y:= a,b;

(This is disappointing to me because I often prefer the neater presentation of the code with the multiple assignments.)

Here I've done the case of "positive" years, which was sufficient to do your 5.7-million-year example. The compiled code finished in under 1.5 seconds without using multi-threading. I'll leave the "negative"-year case to you.

restart
:
EasterC_Mpl:= proc(
    BEGIN::integer[4], END::integer[4], R::Array(datatype= integer[4])
)
local 
    Year::integer[4], a::integer[4], b::integer[4], c::integer[4], g::integer[4],
    j::integer[4], gjk::integer[4], Month::integer[4], k::integer[4]
;
    for k to END-BEGIN+1 do
        Year:= BEGIN+k-1;
        a:= irem(Year, 19);
        b:= iquo(Year, 100); c:= irem(Year, 100);   
        g:= irem(19*a + b - iquo(b,4) - iquo(8*b+13, 25) + 15, 30); 
        j:= iquo(a + 11*g, 319); 
        gjk:= g - j + irem(2*irem(b,4) + 2*iquo(c,4) - irem(c,4) - g + j + 32, 7);
        Month:= iquo(gjk + 90, 25);
        R[k, 1]:= Month; 
        R[k, 2]:= irem(gjk + Month + 19, 32)
    od;
    return 
end proc
:
EasterC:= Compiler:-Compile(EasterC_Mpl)
:
Easter:= proc(BEGIN::integer, END::integer)
local N:= END-BEGIN+1, E:= Array(1..N, 1..2, datatype= integer[4]);
    EasterC(BEGIN, END, E);
    ArrayTools:-Alias(E, [BEGIN..END, 1..2])
end proc
:
E:= CodeTools:-Usage(Easter(1, 57*10^5)):
memory used=43.49MiB, alloc change=42.48MiB, 
cpu time=1.44s, real time=1.43s, gc time=15.62ms

MD:= md-> local r; [iquo(trunc(lhs(md)),100,r), r] = rhs(md):
T:= (MD~@sort)(Statistics:-Tally(E[..,1]*100+~E[..,2]), key= lhs);
   T := [
     [3, 22] = 27550, [3, 23] = 54150, [3, 24] = 81225, 
     [3, 25] = 110200, [3, 26] = 133000, [3, 27] = 165300, 
     [3, 28] = 186200, [3, 29] = 192850, [3, 30] = 189525, 
     [3, 31] = 189525, [4, 1] = 192850, [4, 2] = 186200, 
     [4, 3] = 192850, [4, 4] = 186200, [4, 5] = 192850, 
     [4, 6] = 189525, [4, 7] = 189525, [4, 8] = 192850, 
     [4, 9] = 186200, [4, 10] = 192850, [4, 11] = 186200, 
     [4, 12] = 192850, [4, 13] = 189525, [4, 14] = 189525, 
     [4, 15] = 192850, [4, 16] = 186200, [4, 17] = 192850, 
     [4, 18] = 197400, [4, 19] = 220400, [4, 20] = 189525, 
     [4, 21] = 162450, [4, 22] = 137750, [4, 23] = 106400, 
     [4, 24] = 82650, [4, 25] = 42000
  ]

@RezaZanjirani I don't see your attached code.

@2cUniverse I guess that I need to rephrase my last Reply above because it seems like you either didn't read it or didn't understand it: All fundamental periods are divisors of the totient. The totient is very easy to compute from the prime factorization. Prime factorizations are easy to compute for numbers on the order that you're considering.

The totient itself will only be a fundamental period for x = 2, 4, p^k, 2*p^k for odd prime p. In these cases, the bases for which the totient is a fundamental period are called primitive roots. You might benefit from this Wikipedia article: https://en.wikipedia.org/wiki/Primitive_root_modulo_n

@Carl Love The possibilities for the period are the divisors (NumberTheory:-Divisors) of the totient (NumberTheory:-Totient) of 78; but not every divisor is necessarily a fundamental period. In this case, the totient is 24, but 8 and 24 are not fundamental periods.

According to the help page ?Export, the following 63 file formats are supported for programmatic exporting, (i.e., not requiring any menu-based command or user interaction):

AMF  Base64  BMP  BSON  BYU  CNF  CSV  DGML  DIF  Digraph6  DIMACS  DOT  DXF  FASTA
FASTQ  GDF  GenBank  GeoJSON  GEXF  GIF  Graph6  Graphlet  GraphML  GXL  GZIP  INI
JGF  JPEG  JSON   Jupyter  JVX  LaTeX  LEDA  MathML  MAT  MatrixMarket  MetaPost  MLA
MPL  MW  Newick  OBJ  ODS  OFF  Pajek  PLY  PNG  SMTLIB  Sparse6  STL  SXC  Text  TGF
TSV  UBJSON  VTK  WMF  XLS  XLSX  XML  YAML  ZIP  ZLIB

It's an impressive list, but it doesn't include PDF.

@Carl Love My idea for reducing the number of powers of the base that need to be checked was easier to implement than I initially thought it would be, and it's now included in the code above.

The system that you call OdeSys contains derivatives taken with respect to both xi and eta. That makes them partial differential equations (PDEs), not ordinary differential equations (ODEs). Solving PDEs is vastly more complicated than ODEs. Since I've seen variations of this system countless times here on MaplePrimes, I suspect that you're working from a text that shows a technique for completely eliminating the variable xi. 

@mmcdara You wrote:

• we both implicitely assume then the number to be partionned was a positive integer. What does the OP want if this number is negative and the set of number contains negative numbers...?

No, the OP said explicitly in the first sentence of the Question that they were positive integers.

I combined your two Posts into the above. If you wish to include additional material, please put it as a Comment to this Post rather than as a separate Post.

@sand15 Hyperlinks can be directly embedded in MaplePrimes posts by using Ctrl-K or the toolbar item that looks like two links of chain. I edited your posts in this thread to convert your links to true hyperlinks.

@Samir Khan I don't know if MapleFlow supports the remove statement yet, but if it does, then a more direct way to Answer the Question (as originally posed) is

remove(type, L, string)

What is the axis of revolution? If you use one of the coordinate axes, you'll get something closer to a sphere than to a torus.

@rlopez These Typesetting-based adjustments only affect the display of expressions. The determination of equality is up to the kernel, not the GUI display.

@ecterrab: The width of the n-dash is fine by me. However, I think that the vertical thickness of the line is too thin. Could it be made bold? It also seems too low vertically when applied to a numeral (this might depend on the font).

What about the other issue that I showed in that worksheet, the extra very thin space between the n and the minus sign in the prettyprinted display of n-x, where n is a numeral? In other words, the minus sign is not exactly centered between its operands.