@Preben Alsholm 

So, evalf prevents the evaluation of the first argument, just like
evalf := proc(x::uneval) ... end proc;

to generate polynomials with real roots would be to construct orthogonal polynomials wrt a (random) measure.
This way you can prescribe an interval containing the roots.

@Preben Alsholm 

It is very nice that Maple was able to compute the limit, but I am not at all sure that limits such as

limit( RootOf( f(x,y,_Z) ), y=1 );

are to be trusted mathematically, without a serious analysis.

@Carl Love 

But it's OK. I truly like your style.

@Carl Love 

You are (as always) a perfectionist :-)
 

@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});