@acer 

Yes, and I think that the anisotropic plots specially manifest at large grid density arise in rectangular grid cells being divided into two triangles, similarly as described by Allan here.

@Kitonum 

The level curves are constructed purely numerically, using the float values of the function computed on a rectangular grid, and joining those ones that are close, within some tolerance. So, the mathematical information that the level curves are circles is not taken into account. And the problem is that large values of the function, as they occur near the origin, increase the numerical errors, producing those distortions in the level curves.

The tricks presented in these thread have the effect of bounding the values of the function on the grid, thus reducing the numerical errors. But certainly, a systematic solution by improving the error handling in the code is needed. And as I have commented to Robert, this improvement looks quite easy to implement.

@rlopez 

This bounding trick to keep numerics on the safe side would be very easy to implement as an improvement to the code of plots:-contourplot, if not running automatically, by an option, thus improving the quality of the output.

@Axel Vogt 

First, "Maple works over the Complex" is an overstatement. At some point in its development it was set as a target but it has not been reached yet. Moreover, diverse class of computations do need being done on subdomains of the Complex (Reals, Integers, etc), and Maple is even more inconsistent about providing them.

About Maple's sqrt, it is a function over a branch-cut Complex space, rather than over the Complex plane. And indeed, this difference is a good example why an improved handling of function domains is needed for providing satisfactory answers. This issue has been discussed by Jacques many times here. 

If I interpret your German saying correctly, my opinion is that an ecosystem-like approach is not very fruitful for CAS development. Maple is an actual example!

@Kitonum 

However easy these examples are, the fact is that facilities computing the domain and range of a function are missing in Maple, as Mathematica has nowadays: FunctionDomain and FunctionRange. Indeed, requests for these facilities are FAQs. Probably, there are many pieces of code hidden in the library, providing this functionality, as indeed is needed for diverse purposes.

@acer 

This page shows some ideas and code for gnuplot. I think that similar things could be implemented in Maple.

@Axel Vogt 

Indeed, it is up to the user to decide what is best for his needs. The point is that Maple should provide such a facility, if the user wants to use it, as other plotting software do.

@Markiyan Hirnyk 

Indeed, choosing the locations for text items based on the paths of the associated contour curves is a work that makes much more sense to be done automatically by a program, than by hand, at least in year 2014... This is a missing facility in Maple that has been asked frequently and for a long time, here and elsewhere.

@Joe Riel 

The OP has not shown the integral, but another reason could be that the integral is a periodic function.

@Preben Alsholm 

But the same help page ?solve,details > Parameters states for "variables" only (set/list of) names...

In my interpretation, the solve sector (as many other sectors of the system) has been in the hands of diverse developers at different times. Missing a specification for this sector, their diverse contributions to the code and documentation are not coherent. And in these circumstances, what is a bug becomes a subjective issue. And its recognition as such will depend on the criterion of the developer in charge at the time of submitting the SCR.

@acer 

Such representation with fully qualified conditions is indeed very needed. For instance, for the reinsertion of these conditions as properties into assume/assuming statements. Note, by the way, that a facility of this kind, ConditionalExpression, was introduced in Mathematica 8.

@Mac Dude 

Both diff and series are procedures built in the kernel. So, we cannot inspect their code but we can know when they execute. For instance this way:

> trace(series):
> trace(diff):
> series(sin(theta(t)),theta(t)=0,2);
execute series, args = sin(theta(t)), theta(t) = 0, 2
Error, invalid input: series received theta(t) = 0, which is not valid for its
2nd argument, eqn
> diff(g(f(x)),f(x));
execute diff, args = g(f(x)), f(x)
Error, invalid input: diff received f(x), which is not valid for its 2nd
argument

It shows that series does not call diff. Also, the error messages are produced at the time of argument processing. So, probably, the underlying reason is that both procedures were implemented with the same design not to admit functions as "variable" argument.

@Carl Love 

Something like this:

> series(sin(theta(t)),theta(t)=0,2);
Error, invalid input: series received theta(t) = 0, which is not valid for its 2nd argument, eqn

@bifurcationman 

As mentioned above by acer, fsolve works wrong because RootFinding:-Isolate with option RS has a bug (after Roman). You can see how it is called by tracing RootFinding:-Isolate like:

> trace(RootFinding:-Isolate):
> f:= -32829/50000-(9277/50000)*x-(37251/20000)*x^2-(6101/6250)*x^3-(47777/20000)*x^4+(291213/50000)*x^5:
> fsolve(f);
{--> enter RootFinding:-Isolate, args = 582426*x^5-238885*x^4-97616*x^3-186255*
x^2-18554*x-65658, x, format = list
                   5           4          3           2
     f := [582426 x  - 238885 x  - 97616 x  - 186255 x  - 18554 x - 65658]
                                 comp := "uni"
                   5           4          3           2
     f := [582426 x  - 238885 x  - 97616 x  - 186255 x  - 18554 x - 65658]
                   5           4          3           2
     f := [582426 x  - 238885 x  - 97616 x  - 186255 x  - 18554 x - 65658]
                                  vars := [x]
                                  avars := {x}
                                   pars := {}
                                   cons := []
                                   cons := []
                               outpt := "numeric"
                                 fmt := "list"
                                  mthd := "RS"
memory used=1.0MB, alloc=38.3MB, time=0.06
                                    R := []
                                     C :=
avg := proc(L)
    `if`(nops(L) = 2 and type(L, 'list'('rational')), 1/2*L[1] + 1/2*L[2],
    map(procname, L))
end proc
                                    R := []
                                    R := []
                                       []
<-- exit RootFinding:-Isolate (now in fsolve/polynom) = []}

Now, ?RootFinding,Isolate states:

The method option specifies the algorithm to use.  It can be RS (the default) or RC.  method=RS returns the result by using the RealSolving (RS) C library by F. Rouillier.

And as users, we have no access to the source code of this C library (sadly). Hence, besides an eventual bug fix for a future version, I agree that it would be desirable an explanation of the problem by someone with access and knowledge of the code, possibly the author.

@Carl Love 

In Maple 18 Classic it goes the other way: Kitonium's original order works fine, while the changed order displays bad as you show.

The current behavior in Standard, a regression, is observable from Maple 16 on.