@Preben Alsholm 

The typsetting mechanism is supposed to be used for display purposes. Now it seems to be very intrusive and alters also the results!

@vv 

I must add that  evalf[10](frac(Pi^20)) = 23  is not technically a bug. It's, let's say, a "psychological bug" because nobody expects frac(...) be >= 1. This happens because `evalf/frac` is not implemented and the number of Digits is only 10; note that frac(Pi^20) returns (correctly) Pi^20-8769956796.
Maple's evalf is reliable if used correctly!

@Christopher2222 

Just set the rankings  to -infinity (or better, some very large <0)  rather than 0.
This should probably solve the problem; however, when two such countries with negative ratings play each other, one of them must win.
 

@Markiyan Hirnyk 

It's easy to elucidate your doubts: open the implicitplot help page in a worksheet window, insert trace(fsolve)  and execute all.

Near the curve the sqrt's are almost 0 and may take imaginary values. So, the sign changes are absent and the implicitplot algorithm does not work well in this case. That's why Acer's direct solution is probably the best!

(Of course, the algorithm could implement a sign check for Re and Im).

@acer 

Strangely,

plots:-implicitplot(Re(ee)=0, b=0..5, p=0..5,gridrefine=1, crossingrefine=7);
also works, but
plots:-implicitplot(abs(ee)=0, b=0..5, p=0..5,gridrefine=1, crossingrefine=7);
fails.

(Actually for abs it's not that strange because the needed sign changes are absent).

@Markiyan Hirnyk 

The parametrization covers the whole curve. This follows from the solve result wrt {b,p} .

@Markiyan Hirnyk 

It's simply a substitution; other substitutions are also possible.
What for? We want a parametrization, isn't it?

@mlog 

The procedures are not really necessary, but make the manipulations easier. On the other hand evalf(Int(...)) tends to work better for procedures. The symbolics are difficult for floats, so convert(...,rational)  is usually a good idea; here also because the parameters have large magnitudes.

@Markiyan Hirnyk 

The curve was parametrized. E.g. using:

f:=simplify(sqrt(b)*sqrt(1-4*p/b)-2*arctan(sqrt((9*p/b-22201/10000)/(9/4-9*p/b)))) assuming b>0:
par:=solve([2*indets(f, arctrig)[]=t,f=0],{b,p});

@Carl Love 

Yes, you are right of course, thank you; sum should be add in my formulation.

@Adam Ledger

It is not clear what you try to obtain. Why do you think that f(n) deserves to be considered?
If you want better asymptotic approximations for ithprime(n)  and Pi(x), there are many results, e.g.

nthprime:=n->
n*(ln(n) + ln(ln(n)) -1 + (ln(ln(n))-2)/ln(n) - ( ln(ln(n))^2 - 6*ln(ln(n)) + 11 )/(2*ln(n)^2)); #  + 0(n/ln(n)^2) 

#  Remark
abs(Pi(x)-Li(x)) <= sqrt(x)*ln(x)/(8*Pi);   # assuming RH, x>=2657

But (1) is trivial and has not much to do with Prime Number Theorem; it is true for any sequence p_n > n.

sqrt(n^2 - n) <= f(n) <= n,  so f(n)/n --> 1.

@rahinui 

For some reason (probably a bug) assuming in this context produces the error.
Of course here the assuming clause is useless, and removing it ==> the expected result.

BTW, restart(); does nothing. It should be restart;

@Mariusz Iwaniuk 

Actually a workaround is not needed because F works. The problem is about interface & typesetting.
(F is the first user procedure I met which refuses to be printed).