Applying the evalf command to such a RootOf will cause Maple to use fsolve.  (This doesn't you all control over the various options to the fsolve command, though.)

Another way is to fix the hue layer of the color Array in the plot structure, after the fact.
 

Download coolhot2.mw

@Rouben Rostamian  Since the OP appears to have Maple 18, then the commands would be,

map(fnormal, M.v);

simplify(map(fnormal, M.v), zero);

map(fnormal, v);

simplify(map(fnormal, v), zero);

I'm not sure whether this might confuse the OP, but the smallest eigenvalue (in absolute value) of the given Matrix is not zero. It is small in absolute value, but not zero. So it's not clear whether he would prefer to find the eigenvector associated with that, or the singular vector (which is what NullSpace computes here). I note also that for higher working precision (Digits>12 ?) the numerical rank will compute as 4 and NullSpace will return empty.

@John Fredsted Fooling around and learning by experimentation is always good. Nobody was born knowing maple.

My attachment won't serve as oracle for other different examples. Perhaps the key thing to remember is that the commands zip, map (and map [n] variants) and elementwise operators are different. There is often overlap in their functionality, but no simple correspondence. 

@John Fredsted It seems to me that quite a bit of your difficulty in this example is due to misconceptions about what elementwise operators are supposed to do, and what the syntax means.

Your original map call was,

    map(x -> A . x,LM)

and one valid elementwise operator equivalent is,

    (x -> A . x)~(LM)

since the original operator in your question is x->A.x and not the `.` operator.

It may be that, conceptually, you were only considering that LM is a "container", and overlooking that it really does matter that A is also a "container". But that matters, in the attempted A .~ LM you tried. Bear in mind that your goal was a computation which does not act elementwise on A, so plain A would not be an argument to the successful elementwise operator call. Your attempt A .~ LM is the infix variant of the prefix call `.`~(A,LM) and so it's quite logical that would attempt to use both A and LM in an elementwise manner.

As for the map2 example I gave, it might help a little to think of map as map[1], and map2 as map[2]. You wanted to treat only LM (and not A) in an elementwise manner. The map[1] and map[2] commands allow you to have just one of the arguments be treated elementwise. And that extends to map[n] more generally,

    `*`~( [2,3], [a,b], [x,y] );

                               [2 a x, 3 b y]

    map[1](`*`, [2,3], [a,b], [x,y] );

                     [2 [a, b] [x, y], 3 [a, b] [x, y]]

    map[2](`*`, [2,3], [a,b], [x,y] );

                     [[2, 3] a [x, y], [2, 3] b [x, y]]

    map[3](`*`, [2,3], [a,b], [x,y] );

                     [[2, 3] [a, b] x, [2, 3] [a, b] y]

I'll attach a sheet. I hope it helps clarify, rather than not.

elementwise.mw

@tomleslie On the help page for topic operators,elementwise in Maple 2016 I see, "When mixed container types are present the return type will be determined according to the following precedence: object, rtable, list, set."

And that explains why both [1,2,3]*~{4,5,6} and {4,5,6}*~[1,2,3] return a list. It also (correctly) indicates that elementwise multiplication of a Vector and a set returns a Vector.

@fzfbrd The unapply call takes a list of 2^N entries, but the final optimized procedure takes 2*N arguments (which I presume will be passed in a numeric values). You don't say why generating 2^N expressions will take so long. Is it longer than than the time to produce the 2^N combinations of low and high pairs for each of the N variables? You have to generate all those anyway, as far as so far indicated. If the problem with generating the 2^N symbolic variants of the original expression is memory then you may well need some other approach. But if the problem is just time  -- because of unwanted evaluation during construction -- then it could be set up to use `subs` (and/or act in a procedure) and guard against that.

It's very difficult to give great advice when you haven't shown an explicit and complete example which exhibits the actual issues. Even the details are scarce, so far. Are the low and high values, and the computation, floating-point? How many variables are there, typically? Does the expression have a structure such that simply using has/select/op/indets might separate the independent subexpressions easily?

@fzfbrd If you print (and examine the bodies of) the procedures in my example (change colons to semicolons, or `print`) then you can see that the body if the original has the 16 full expressions while the body of the optimized procedure has only those 8 that you mention. That's why I gave this answer.

For your simple ("toy") example there are several other ways to get produce the reduced set of subexpressions. For example using customized `indets` calls, or here even just `op`. But those approaches will be suboptimal (or at least, very complicated to set up) for some much larger and more complicated original expression. Hence I am trying not to lead you down what I believe to be a much more difficult path.

With a little extra effort it would even be possible to programmatically construct a variant of the optimized procedure which returned just the common subexpressions. But then you'd be faced with the task of re-assembling them in all the combinations. That would be tricky, and it's not clear (yet) how it would improve on the concurrent return value generated by the optimized procedure as given above.

@fzfbrd If you call the optimized procedure (returned by codegen[optimize]) with particular instances of the low and high values (for all parameters) then the subexpressions are computed less often. For you given example the product subexpressions would be computed 8 rather than 16 times. I'm not seeing how this is not the effect you've described.

If you are hoping to have that effect for the line-printed 1D plaintext output from say the `showstat` command then you should mention it.

@Kitonum Is this going to be the same as remove(member,A,{A[]} minus {B[]}) ?

It would be interesting to know whether duplicates may appear in A, or whether the entries are all sorted (ie. whether one might not consider select(member,B,A) ).

Perhaps it is part of a programming exercise, though.

@Kitonum Very nice. I believe that the assumption you used is not strictly necessary there.

It may be that a more general rule could be attempted.

restart;
Int(Pi*(2*ln(y+sqrt(y^2-4))-2*ln(2))^2, y=2..exp(1)+exp(-1)):
raw:=value(IntegrationTools[Change](%, y+sqrt(y^2-4)=t)):

simplify(eval(simplify(raw),exp(4)-2*exp(2)+1=(exp(2)-1)^2));

                    4 exp(-1) (exp(2) - 4 exp(1) + 5) Pi

simplify(radnormal(subsindets(simplify(raw),specfunc(anything,exp),u->exp(1)^op(1,u))));

                        4 Pi (exp(1) - 4 + 5 exp(-1))

restart;

foo:=sqrt(exp(4)-2*exp(2)+1):

simplify(foo);
                                               (1/2)
                        (exp(4) - 2 exp(2) + 1)     

radnormal(subsindets(foo,specfunc(posint,exp),u->exp(1)^op(1,u)));
                                        2    
                                (exp(1))  - 1

I changed this from a Question to a Post. The literal question, "Do I really have to go through all of his replies on the page?" seems rhetorical. Weakness of the Search mechanism of this site have been made several times in the past, and indeed I have complained before about the particular aspect mentioned.

@Fzen Using simplify(...,symbolic) has the drawback that you don't then know that some branchcut might not have been ignored. But I also don't get the required form from using your suggestion.

Duplicates of these homework questions may be deleted.