@Kitonum The default time command is showing the sum of the times on all processors. Parallel processing always takes more time, when time is measured that way, because there is significant overhead involved in dividing up the tasks among processors. The benefit of parallel processing, if any, is only evident when you look at the real time via time[real].

time[real](PP({$1..20}));
                             6.113
time[real](PowerSet({$1..20}));
                             4.302

You can also simply replace the seq in PP with Threads:-Seq. It turns out that there is not much benefit to the parallel processing here. But the benefit should increase as computers get more and more processors (I have 8). To make a better comparison, compare procedures where the only change is from seq to Threads:-Seq.

You say "d will be x(t) + a(t)". What is a(t)? Did you mean "d will be x(t) + a[1](t)"?

This brute force technique is far from optimal, especially considering that the sum is converted to a continuous increasing function of N.

This brute force technique is far from optimal, especially considering that the sum is converted to a continuous increasing function of N.

It is important for you to note that Markiyan changed your Sum to sum (with lowercase s). It is easy for a reader to miss that detail. The fsolve will not work without that. With the evaluated sum, it converts the summation to a continuous increasing function of N.

Also, he changed your pi to Pi. The latter is the well-known constant, while the former is just another variable.

It is important for you to note that Markiyan changed your Sum to sum (with lowercase s). It is easy for a reader to miss that detail. The fsolve will not work without that. With the evaluated sum, it converts the summation to a continuous increasing function of N.

Also, he changed your pi to Pi. The latter is the well-known constant, while the former is just another variable.

@Przemek I can't give any more advice until you post the equations.

You did not enter the procedure exactly as I typed it. It's Statistics :- CDF, not Statistics - CDF. Cut-and-paste the boldface code below. The non-boldface part is Maple's responses.

normalcdf:= proc(x1,x2,mu,sigma)
local t,dist:= Statistics:-CDF(Normal(mu, sigma), t);
     eval(dist, t= x2) - eval(dist, t= x1)
end proc:
normalcdf(2100,2200,2150,50);
                            /1  (1/2)\
                         erf|- 2     |
                            \2       /
evalf(%);
                       0.682689492137088

You did not enter the procedure exactly as I typed it. It's Statistics :- CDF, not Statistics - CDF. Cut-and-paste the boldface code below. The non-boldface part is Maple's responses.

normalcdf:= proc(x1,x2,mu,sigma)
local t,dist:= Statistics:-CDF(Normal(mu, sigma), t);
     eval(dist, t= x2) - eval(dist, t= x1)
end proc:
normalcdf(2100,2200,2150,50);
                            /1  (1/2)\
                         erf|- 2     |
                            \2       /
evalf(%);
                       0.682689492137088

I edited the tags on your Question.

@rkm You can use labels if you want. The percentage sign means, literally, "the result of the previous command". There's also %% and %%% for "the result of the second-most-recent command" and "the result of the third-most-recent command." But that's as far back as you can go without using labels.

@rkm You can use labels if you want. The percentage sign means, literally, "the result of the previous command". There's also %% and %%% for "the result of the second-most-recent command" and "the result of the third-most-recent command." But that's as far back as you can go without using labels.

I picked a subset of the four shortest polynomials, {f0, f1, f5, f6}, and tried to solve just those. After running for about an hour (with apparently insignificant memory usage--38 M), I had a loss of kernel.

Are you looking for an exact solution, or would a decimal approximation be okay? If the latter, try fsolve.

It is hard to say whether Maple is right or wrong when its answer is FAIL. In this case (the n::posint case), we know that there is enough information to give the definitive answer false. We may say that Maple should know that the answer is false. But it hasn't been programmed to analyze the situation deep enough. My guess is that it boils down to this: Maple knows that the inequality is false for real n between real 2 and real 4, but it doesn't know that there is an integer between those bounds.