@Axel Vogt I was being obsessive about ensuring that the evaluations of the integrand were not done under evalhf. And under evalhf a proc that creates a list will error out.

The `forget` may not be necessary, I didn't test without it. Again, I was being obsessive. I was guarding against remember tables under evalf/Int being keyed on the name of the integrand procedure rather than its content. (I recall hitting that some other day, for some other example, possibly fundamentally different...)

I too would like such 2D contour plot labeling. 

3D color keyed levels are nice, but I'd still like better 2D. And while coloured contours may sometimes be helpful, there are still times when labeled B&W contours fit the bill (eg. some publication..).

And the example image the OP has shown illustrates an important feature, namely separate labeling of the same contour value on disconnected curves. More than one separate  curve section can share the same contour value.

It's pretty easy to postprocess the output of plots:-contour plot and add a label for each contour value. Slightly more work to remove a bit of curve section so that the label can be right on the contour but not overlaid. Harder but not impossible, to obtain "usually" decent placement. 

I'm trying out some ideas for this, and will post when done. (I have a bad cold...)

But first I'm tackling a preliminary task. Currently, each contour value produces a CURVES structure which contains a sequence of line segments that together make up the one or many curve segments the attain that value. But when there are multiple separate curve segments then all of their component line segments are jumbled up together -- out of order. I'm trying to write a decent routine to split them up, so that its easy to apply the same label to each of the distinct same-valued curve segments that merit it.

I think that more flexible colouring should also be possible.

acer

@Bendesarts If `solve` returned a sequence of solutions then put those into a list before calling `remove`. Ie,

remove(has, [sol], I);

@dgem Ok, so how about trying the routine `findroots` I posted in reply on math.stackexhange.com? It returns numeric results, and it accepts arguments which specify a real range over which to find roots. Is there some reason you have not to try that routine?!

The other alternatives Student:-Calculus1:-Roots, RootFinding:-Analytic, and the add-on DirectSearch approach also meet your two criteria a) and b).

If you are bent on using fsolve, then you could try using it repeatedly with its `avoid`. But that's just what Student:-Calculus1:-Roots does internally. (It's not a great approach, in the presence of many roots.)

See my answer to the same question, posted last week on another forum. It contains code with two working approaches: one using Student:-Calculus1:-Roots, and the other a (faster) custom procedure.

Another approach sometimes cited for similar questions is to use the RootFinding:-Analytic command. I am a little more uncomfortable about the reliability of that approach, since using it to determine purely real roots involves either (potentially) too much work being done in a wide strip of the complex plane or (potentially) missing rootts due to using too narrow a strip. Nothing will be foolproof, however.

Have you asked the question because you do not yet see that an approximate floating-point numeric (nonexact) solution may be necessary here? Or that you do not see why supplying finite bounds on x may be necessary here?

acer

@Carl Love It might be worth noting that piecewise structure is such that the case shown by the conditional m<2+sqrt(5) is also implicitly dependent upon the negation of the two conditions above it, ie, m<>2-sqrt(5) and m>2-sqrt(5).

Hence the "middle" case is a solution under restrictions m<2+sqrt(5) and m>=2-sqrt(5). How could one best obtain some representation in which the branches are fully qualified (independently, each in full and simplified)? This could be useful in some situations, I imagine. For this example, one might go further, towards RealRange representation. Something like PiecewiseTools:-Support?!?

@Kitonum If that is so, then does this return something useful?

solve(x^2 - 2*(m+1)*x+m^2 - 2*m + m^2=0,{x},real,parametric=full);

Please provide some clear example of the commands that are failing for you.

acer

@bifurcationman A significant portion of fsolve is implemented as interpreted (Maple language Library) code, and as such can be viewed. In this case, (taking line numbers from Maple 18),

showstat(`fsolve/polynom`,33..34);

@Markiyan Hirnyk Yes, that's why I mentioned using the `complex` option for this example in my Answer made previously.

@Markiyan Hirnyk That's not the same polynomial as in the Question. You left off the minus sign in front of the constant term.

@Markiyan Hirnyk I agree, it is easier to set up this kind of problem in Mma, and the surface is rendered more cleanly. Here it is in Maple, with some additional look & feel tweaks.

lts:=[x^2+x*(y+2*z)-1, y^2+y*(x+2*z)-3]:
eqs:=y*z*(x+y+2*z)^3-8:

plots:-implicitplot3d( min(eqs,-max(lts)),
                       x=-10..10, y=-10..10, z=-10..10, grid=[80,80,160],
                       style=surfacecontour, contours=14, orientation=[-62,54,0],
                       color=gold, lightmodel=light2, glossiness=0.7 );

I half expected the Std GUI to get bogged down at that grid resolution, by in 64bit Maple 18.01 for Windows the computation and rendering times were just a few seconds, and manual plot rotation stayed reasonably responsive for me. In Classic for 32bit Maple 16.02 the rendering took much longer but the manual rotation stayed fast.

@Carl Love As far as I know all other kernel threads (Grid child mservers excepted) stop while gc is working. That's why it can make sense to think of the gc real time as being a simple portion of the total real time for a computation.

It's great that gc can be done using multiple threads acting in parallel in Maple 18. But the number reported as `gc time` is the sum over all such gc threads (acting concurrently), so it can't sensibly be compared with other timing numbers. That's similar to how `cpu time` is the sum of the computation time over all (possibly concurrent) threads, and as such cannot easily be sensibly compared to other timing results.

But the wall-clock `real gc time` and the wall-clock `real time` are two numbers that can be compared sensibly.

And indeed CodeTools:-Usage already computes `gc real time` internally. It just doesn't include that by default as part of the printed results.

It is interesting how the non-kernel dispatch works, in that it invokes the non-kernel procedure body of the same name (like how procname works), and not the Library Vector procedure.

So, in the second example below it is f that gets invoked, and not the Library Vector command.

restart:
f:=proc() option builtin=ConstructRow; J; end proc:
trace(f):

f(x,y,z); # computed in the kernel
execute f, args = x, y, z
                                  [x, y, z]

f(sin(x),y,z);  # not computed in the kernel
execute f, args = sin(x), y, z
{--> enter f, args = sin(x), y, z
                                      J
<-- exit f (now at top level) = J}
                                      J

@Alejandro Jakubi Yes, I did know this. But it doesn't affect my wish for commands Vector, Matrix to be made into faster builtins (like the Array command).

I did not write that `<|>` is of type builtin. I wrote that it is a builtin, which to me means that it has option builtin and can compute some results via a built-in kernel function. But one could also sensibly call it partially builtin.

The behavior is a bit complicated.

<sin(x)|y|Pi|sqrt(2)> gets dispatched to the Library Vector procedure, while <x|y|Pi|sqrt(2)> does not.

The presence of at least function calls, tables, sets, and names which evaluate to procedures can get dispatched to the interpreted Library procedure. But some nonnumeric data gets done just by the kernel.

If Pi has been assigned to name `a` then <a> is done by the kernel but <'a'> is dispatched to the Library procedure.

It can also make a difference whether one is at the top level. At the top level the following will be done by the kernel.

b:=a: a:=Pi: <b>;

But inside a proc the following (with 1-level evaluation of LOCALs) gets dispatched to the Library procedure.

proc() local a,b; b:=a: a:=Pi: <b>; end proc();

This has become a tangent discussion.