@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.

@vv That gives the transpose of the Matrix M that I had above. I believe that just means that the first 9 entries of the 10-valued PROJECTION substructure of a PLOT3D structure can be interpreted scanned as the columns of the rotation Matrix (rather that as its rows).

Your idea to use Explore is very nice. I attach a revision, which may demonstrate the (new, transposed) rotation Matrix alongside the action of plots:-display with the `orientation` option.

rot3dexplored.mw

@vv It doesn't help that Psi and Phi are switched in the main menubar, relative to the order in the `orientation` option.

Have I got the multiplication order ok in the attached sheet, or have I just confused myself?

I notice that when the GUI puts a 3D plot into a Plot Component it merges the ORIENTATION substructure and a 1-value PROJECTION substructure into a 10-value PROJECTION substructure. I wonder whether my interpretation of the GUI's notions are correct.

rot3d.mw

Have you tried running Maple 2015 or Maple 2016 on Windows XP and encoutered problems, and if so then how severe?  I mean 32bit Maple, if on 32bit XP, naturally. (I had a dual-boot 32/64bit XP machine once, but I don't think that use of 64bit XP was common...)

As far as I know, that kind of information was available in advance (respectively) of the M2015 and M2016 releases, as https://www.maplesoft.com/products/roadmap.aspx. I would like to see that information updated for "Maple 2017", and have mentioned that before on this site.

By the way, that roadmap page also indicates that people have reported success running Maple 2015/2016 on Windows XP. The removal of official support for Windows XP is therefore not the same kind thing at all as the dropping of the PowerPC OS X line (by no longer producing product installers for that hardware).