@Carl Love 

Compare:

(x^2+12)/(x+1) mod 13;

Normal((x^2+12)/(x+1)) mod 13;

@Carl Love 

Probably OP wants

Normal( (x-1)/(x-3) ) mod 13; 
    (x+12)/(x+10)

(the field of fractions).

Or, maybe (in this case)

r := Rem(x-1,x-3,x,'q') mod 13:
q + r/(x-3 mod 13);
    1 + 2/(x+10)

@Stretto 

The control is less intuitive because all 3 angles theta, phi, psi  are changed using the mouse. In other CASs, psi=0; this is also true in the Classic Worksheet (exists only for 32 bit but it seems that it will be discontinued).
Probably psi=0 is enough and more intuitive: horizontal mouse move (anywhere) ==> theta, vertical ==> phi.

P.S. Instead of using psi, we could rotate the screen, at least for a laptop  :-)

@Christian Wolinski 

Nice, vote up.
It would have been better if the undefined entries were not treated as 0 by matrixplot.

@Christian Wolinski 

Both are linear, first order PDEs, with standard solutions. The option generalsolution is not needed in this case (if inserted, the result is the same).

@BeatrizSilva 

It works for me.

trabalho_final_2019-ok.mw

@Mariusz Iwaniuk 
It should be added that this is valid in general only for x>0 [not a bilateral expansion]

@Zeineb 

Try:

simplify(gg(x0) - alpha);

The mathematical definition of a PRNG is clear. But deciding whether a computer-based PRNG is acceptable or not is practically impossible. All we can do is to choose arbitrarily (more or less) some criteria. The main criterion seems to be "usefulness".

The Pyton code must be converted to Maple by hand. This cannot be done automatically. Actually it is probably easier to start directly from the algorithm.

The main concern is that Maple has a very solid Groebner package. Are you sure the Python code has something better or not implemented in Maple? It would be useful to present a few examples obtained with your code.

@Melvin Brown 

For the animation you have spacestep = 1/50, timestep = .1
but in the plots there are the default values.
If you use the same values, the results will agree. I don't know how the error estimates are implemented; I think that the differences should not be so big, unless the method is not stable.

@acer 

But is it possible to reproduce the worksheet from scratch (without setting manually the labels or by copy+paste)?
 

@acer 

It seems that the worksheet has some strange output data.
After removing the output and re-executing, everything is OK.

Parameters in a procedure cannot be assigned like this
( P := convert(P, list);   etc)

@Carl Love 

I think you meant "expression" instead of "statement" for arrow operators.

For example,
f := () -> local i; i:=7;
is not correct (but enclosing (i:=7) is ok).

Note that 
f:=proc() local i; i:=7 end;
is correct too.