@mmcdara Vote up (largely for your Reply immediately above).

I believe that the decline in efficiency is precisely due to the reason that you said: It's "stupid" (efficiency-wise) to use range= -1..1 when the standard deviation is small; that range is too wide. Also, it's stupid (accuracy-wise) to use range= -1..1 when the standard deviation is large; that range is too narrow. In particular, if range= a..b and either CDF(X, evalf(a)) = 0.0 or CDF(X, evalf(b)) = 1.0, then the range is too wide. Ideally, a should be slightly >= Quantile(X, eps) and b slightly <= Quantile(X, 1-eps) where eps is akin to a "machine epsilon": a small positive number such that evalf(1 - eps) < 1 (strict inequality!) and such that neither Quantile is +/- Float(infinity).

Regarding "adaptive": It's adaptive to an extent; GIGO applies. If you want it to be adaptive in this respect, then don't specify the range; it will then choose a suitable one. Not specifying the range is equivalent to specifying range= deduced. That having been said, for this example there will likely be cases where it fails to calculate an appropriate range and requests that the user does it.

@FrancescoLR It seems to me that to achieve any real benefit from parallelism, you'd also need multiple disk drives operating in parallel. Otherwise, I'd think that the disk drive rather than the CPU would be the bottleneck. I'm not sure about this, because perhaps buffering the file output to RAM ameliorates the bottleneck effect.

@Magma Okay, granted, my comment was impolite. Since my primary purpose is that readers learn from my posts, how can I help you to learn efficient Maple, and reasonable coding practices (regardless of language)?

If you want to use GF, much better code would be

select(
   p-> andmap((g,F)-> F:-order(F:-input(g)) = p-1, [2,3], GF(p,1)),
   select(isprime, [seq(2001..2999, 2)])
);

And even if you want to go old-school with a while loop, either of these is far better than what you had:

p:= 2000: 
L:= table():
while (p:= nextprime(p)) < 3000 do
   G:= GF(p,1);
   if G:-order(G:-input(2)) = p-1 and G:-order(G:-input(3)) = p-1 then
      L[p]:= p
   end if
end do:
[entries(L, indexorder, nolist)];
#
# Or
#
p:= 2000: u:= 0:
L:= Vector():
while (p:= nextprime(p)) < 3000 do
   G:= GF(p,1);
   if (G:-order@G:-input)~({2,3}) = {p-1} then
      L((u:= u+1)):= p
   end if
end do:
[seq(L)];

I thought that your followup entitled "not working..." was appropriate as a separate Question, so I made it so, with the title "[Finite-field arithmetic] not working..." Please continue the discussion of that issue there. And in this thread, please continue discussing how to use Maple to work with the quotient ring GF(p,k) / f where k > 1 and f is a reducible univariate polynomial over GF(p,k).

@Magma That's ridiculous. It seems that you've learned nothing from my Answer.

@bellaqueame I've rewritten your ElemRing:

ElemRing:= proc(
   f::depends(polynom(polynom(integer, tauh), x)), 
   x::name,
   tauh::specfunc(polynom(integer, _Z), RootOf),
   p::prime
)
local i, n:= p^(degree(op(tauh))*degree(f,x))-1, ring:= rtable(0..n);
   for i to n do 
      ring[i]:= Nextpoly(ring[i-1], x, tauh) mod p
   od;
   [seq(ring)]
end proc: 

Please execute this in Math Input (aka 1D Input) or in a Code Edit Region because I suspect that the depends parameter modifier doesn't work in 2D Input. Your versions have numerous levels of unnecessary, nested list-forming brackets. I think that this is the reason that they don't work. I don't feel like disentangling all your nested lists, because they're simply not necessary.

Note that I changed the parameters (and their order) from your ElemRing. Like before, the x (a global unassigned name) should be passed! It's not necessary to pass k because it can be deduced from tauh. The order is just my style preference and follows the argument order of Nextpoly. It is traditional in Maple that the field characteristic p be the last parameter.

@bellaqueame From your "invalid power" error, I assume that you're using 2D Input. The error can be corrected by changing

<seq(a^(` q `^k), k= 0..n)>^+

to

<seq(a^(` q `^k), k= 0..n)>^%T

and also make the same change on the following line.

I strongly discourage the use of 2D Input. I use Maple Input (aka 1D Input).

I haven't looked at your code yet.

@bellaqueame As far as I'm concerned, there's no practical difference between an infinite equivalent class and its canonical representative. For example, consider 3/5: Is it just a rational number, or is it the equivalence class of all pairs of integers (n,m) such that 5*n = 3*m? And does making that distinction make any practical difference? Only set theorists make that distinction, and then only when they're being pedantic.

My command Rem(..., f, x) mod p does include the ring extension element! It's the x, and I told you to pass the x to your FastEval.

Doesn't the following code do (over a randomly generated ring) what you describe above?: 

restart:

p:= 3: d:= 2: q:= p^d: n:= 2: #size parameters
interface(rtablesize= 2+p^(n*d)):

alias(T = RootOf(Randprime(d, z) mod p, z)): #random degree-d field extension

#explicit list of ring elements:
R:= [seq(rtable(
   (0..p-1)$(n*d), 
   ()-> add(add(args[d*i+j+1]*xi^i, i= 0..n-1)*T^j, j= 0..d-1)
))];

#random polynomial that splits into n distinct linear factors over F_q:
f:= sort(
   collect(Expand(mul(xi-a, a= combinat:-randcomb(R,n))) mod p, xi, expand), 
   xi
);
 
#table of powers of every ring element:
<
   <seq(a^(` q `^k), k= 0..n)>^+,
   <seq(`=======`, k= 0..n)>^+,
   Matrix((nops(R), n+1), (i,j)-> Powmod(R[i], q^(j-1), f, xi) mod p)
>;

Powmod(a, n, f, x) mod p is equivalent to Rem(a^n, f, x) mod p but is a little more efficient.

Regarding ceil(log[2](n)), it's equivalent to

ceillog2:= (n::posint)-> `if`(n=1, 0, 1+ilog2(n-1)):

@acer Vote up. Since these commands are undocumented, do you have any idea what mtr and mtd stand for? That would help me remember them.

@izhammulya It's not at all strange that the minimal solution sets those variables to their maximal values. All coefficients are positive and those variables appear in equality constraints but not the objective. I think that you simply made a mistake by including them in the constraints. Removing those variables from the problem entirely is equivalent to setting them to 0.

@izhammulya If you think that those variables should be 0, then simply remove them from the problem!

@izhammulya Please post your problem as an attached worksheet. For one thing, it'll be much easier to read. You can attach a file by using the green uparrow on the toolbar of the MaplePrimes editor.

I could write a procedure that does that, but before I do, I'm curious what the purpose is for you. Any of the following commands is likely to provide more-relevant information about a DAG and its substructures:

indets, #by far the number-one choice
ToInert,
dismantle, #gives a visualization, but difficult to process results programmatically
disassemble@addressof

@jbuddenh Yours is the second problem in a week reported in MaplePrimes caused by the poor rendition of code examples in Maplesoft's online help pages. As I told that other Questioner, I recommend that you always compare with the in-program help (in this case ?Statistics,Distributions,Uniform). And for additional clarity, press F5 to display the code in a monospaced font if it's not already thus displayed.

@minhhieuh2003 Thanks, I totally understand your Question now.

The answer depends on whether Typesetting:-mrow has an option akin to tabulation, such as placement at a certain distance from the left edge of the virtual box that it works in. Trying to fit in a certain number of space characters is unreliable if you're not using a monospaced font.