May be because of how grey is generated on screen. May be also an issue of pixels and screen resolution. The fact is that even thickness values, like 2 or 4, produce blurred borders, while for odd ones, like 3 or 5, the borders look sharper.

Interesting workaround. However, with thickness=4 I see these thick axes with blurred borders on my screen. They show sharper, with e.g. thickness=5.

Interesting workaround. However, with thickness=4 I see these thick axes with blurred borders on my screen. They show sharper, with e.g. thickness=5.

No, because 'ln' stands for the principal branch of log (cf ?ln):

ln(-1/2);
                            -ln(2) + Pi I

ln(-2);

                             ln(2) + Pi I

 

No, because 'ln' stands for the principal branch of log (cf ?ln):

ln(-1/2);
                            -ln(2) + Pi I

ln(-2);

                             ln(2) + Pi I

 

The generic implicit assumption is that the variables are complex (cf ?RealDomain).

The generic implicit assumption is that the variables are complex (cf ?RealDomain).

simplify(log(1/r)) assuming r>0;
                                -ln(r)

simplify(log(1/r)) assuming r>0;
                                -ln(r)

But max(L1) and min(L1) just reproduce, in float form, the values xmin:=-2*Pi and xmax:=2*Pi set before. I.e. you do not get anything new by doing that. I had thought that you was looking for something different, but not sure what. 

But max(L1) and min(L1) just reproduce, in float form, the values xmin:=-2*Pi and xmax:=2*Pi set before. I.e. you do not get anything new by doing that. I had thought that you was looking for something different, but not sure what. 

e1:=x^2/2500+y^2/200=1:
e2:=y=x^2:
solve({e1,e2},{x,y}):
allvalues(%):
evalf([%]);

[{x = 3.755288564, y = 14.10219219}, 
{x = -3.755288564, y = 14.10219219}, 
{x = 3.765925144*I, y = -14.18219219}, 
{x = -3.765925144*I, y = -14.18219219}]

And two nonreal ones.

e1:=x^2/2500+y^2/200=1:
e2:=y=x^2:
solve({e1,e2},{x,y}):
allvalues(%):
evalf([%]);

[{x = 3.755288564, y = 14.10219219}, 
{x = -3.755288564, y = 14.10219219}, 
{x = 3.765925144*I, y = -14.18219219}, 
{x = -3.765925144*I, y = -14.18219219}]

And two nonreal ones.

In Standard GUI you can change the typesetting mode by:

interface(typesetting=extended);

and get the desired output.

In general I prefer going to source mode as I have greater control on the tagging, but it is largely a matter of taste.

In source mode ordinary text ,as this one, will go between <p> </p> tags. But normaly I just write it "untagged", as will it get enclosed by these tags in the preview stage anyways.

Then, code goes between <pre> </pre> tags and 2D math between <maple> </maple> tags. Like:

<p>ordinary text</p>

<pre>code</pre>

<maple>2D math</maple>

Just check that they do not "overlap". I.e. close one region before opening the next one. And check to have Filtered HTML set in "Input format" below.

Preview, and most frequently it will work.  Well, 2D math sometimes will not work fine. In such a case, I just put the output as code.

Experiment a bit and you will get it.