@tomleslie Hmm, I wonder why the OP asks "is it possible to change {a°b} to a°b it would be very helpful" when we have posted right here two solutions to precisely that problem. And although I had my criticism of your solution, I nonetheless admit that it works.

@danielpf You wrote:

• One should be able to use any symbol outside sum as the particular symbol used for summation, like the integration variable for int, can be replaced by any other symbol.  

I agree; that was the entire point of the second paragraph of my Answer "Bound variables".

But you missed my overall point entirely: My primary goal when someone asks a Question here about solving a particular problem is not to tell them how Maple should operate; rather it's to teach them how Maple does operate so that they can proceed with their work. And then, if I also have some ideas about the should, perhaps I also discuss that.

• Mathematica does the right thing in such a case by replacing the summation symbol by another distinct one.

Yes, I agree, that's the right thing. And I'm trying to tell you that that's only currently implemented for seq, add, and mul (and some progress has been made with sum along these lines if you access it through the Physics package). I don't think that it should be that way, but that's the way that it is currently.

@taro 

[In this post, I often use the word symbol. I mean this in its ordinary English sense rather than how it's specially defined in Maple. Anything that I type inline in black boldface is meant to be literal Maple syntax. That's true of anything that I write on MaplePrimes.]

You wrote:

• So `or` (x,y) means just a sequence of
  words of "or, x and y", leaving its evaluation to people who so wrote.

No, I'm sorry to say that even that is not true; it's not even close to true. I'll try to explain:

Infix form, reserved words, back quotes: When an operator symbol can be used by being placed between its operands, as in A+B, we say that the operator is being used in infix form. The operator symbols that can be used in this way are quite special. For example, I can't use f (as an operator or function) in infix form (in Maple), because A f B is total nonsense to Maple. However, there a few (very few!) operator symbols that are purely alphabetic characters that can be used in infix form. The complete list of these symbols is [mod, intersect, union, minus, subset, in, and, or, xor, implies, assuming]. In order for the syntax to be consistent and unambiguous, it is necessary that these be reserved words (see ?reserved) which means that if they are used out of context, then they must be in back quotes. So, if for any reason we want to use or other than as an infix operator, it must be `or`. Furthermore, if it is being used infix, then it must be or, not `or`. Note very carefully that I have not (yet) stated a reason why we might want to do that; rather I said for any reason. It turns out that there are numerous reasons that someone might want to do that. In the next paragraphs, I will cover one of those reasons: functional form.

Functional form: When an operator or function symbol is used by being placed before its operands with the operands bracketed, as the f in f(A,B), we say that the function is being used in functional form. Of course, this is the way that the vast majority of function symbols are used. Most (but not all) of those very special symbols that can be used in infix form can also be used in functional form. For example, `+`(3,5) is the same as 3+5, and both return 8. Although the internal mechanism by which they return 8 is slightly different, that is mostly transparent to the user. One difference is that functional forms are not automatically simplified, and that is one (of many!) reasons why someone might choose to use them. Once again, note very carefully that the purpose of the quote marks on `+` is not to force the symbol to be used in functional form; rather, they're needed if the symbol is used in any syntactic context whatsoever other than as an infix operator, and functional-form usage is just one of those possible contexts. Also, there are some infix operators whose functional form is not obtained simply by putting quotes around the symbol. For example, the functional form for an elementwise operator such as +~ is `~`[`+`].

How all this applies to `or` and `and`: Likewise `or`(A,B) should be equivalent to A or B (and similarly for `and`), meaning that they should return the same thing although the internal mechanisms by which they do that may be different. And they are indeed almost equivalent. The functional form `or` is not inert, which is what you're claiming in the sentence that I quoted at the beginning. It's not even close to inert, even in VV's example. In the vast majority of practical cases, the two forms return the same thing. And even in VV's example, the infix and functional forms return almost the same thing, the only difference being that the functional form requires one final evaluation. It is this small difference (and only this difference) that was the initial subject of this Question.

The McCarthy rules for short-cut evaluation of boolean expressions: This topic hasn't come up yet in this thread, but it's important enough and relevant enough to be mentioned here. Compared to the way that all other predefined infix expressions are evaluated, there is a fundamental difference in the way that the expressions A or B, A and B, and A implies B are evaluated: If the truth value of the overall expression can be determined from the truth value of A, then B is not evaluated at all! This is true in most good, practical computer languages and facilitates profound simplification of nested control structures. For example, consider 

if x::realcons then
   if x <> 0 then
      if evalf(1/x) > 7 then ....

I believe that the above is safe to evaluate for any x (even NULL or a multi-term sequence). Because of the McCarthy rules, it can be simplified to

if x::realcons and x <> 0 and evalf(1/x) > 7 then ...

and still be safe to evaluate for any x. Unfortunately, these rules are not used for the functional forms `or`, `and`, and `implies`.

Forms other than infix and functional: There's a very small set of operators whose ordinary usage is neither functional nor infix that nonetheless have functional forms. The list of those functional forms is [`!`, `?[]`, `?()`, `[]`, `{}`, `<,>`, `<|>`, `%`, `%%`, `%%%`]. The infix operator assuming has the usual functional form `assuming`, but because of its very low precedence (see ?operators,precedence), a small change is necessary in the syntax for passing its arguments.There's no need to explain any of these things further in this post.

Inert form: When a function or operator (either infix or functional) symbol is changed by beginning it with %, the purpose is to make it inert. So %subs(a= 0, 'x or y') might as well be foo(a= 0, 'x or y') because neither do anything at all. The main reason to use % rather than changing the name in some other  way is that the command value will remove the % without any other instruction or options necessary. By combining the use of % and value you can change the time at which the function is actually called. 

@tomleslie I too would like to know why the original expression was created.

I'd call what you did to the expression "character-level surgery". It's quite dangerous because of the parse,

• which can only create global variables
• which wastes time also reconstructing the parts of the expression that don't need to be changed.

The best commands for dealing with nested and/or embedded objects that can be described by a type expression are evalindets and subsindets. Not only do they have the best functionality, but their syntax is very easy to understand.

@asceduardo You state

1. I hope that, if I get to join both plots, Maple might export it correctely.
2. Alternatively, I would be satisfied with correctly exporting the colorbar.

I would guess that the conditional probability P( 1 | not 2 ) is pretty close to 0, so I think that your effort would be more wisely spent persuing 2. If you post the code and any datasets that are needed to generate the colorbar, I'll have a look. Whether or not you include the code for the plot on the left is irrelevant.

@acer I don't know the answer to the question that you posed in your title, which is what I meant by "I don't know how this will interact with EPS, but you can probably test that faster than I can." I don't recall ever successfully exporting an array plot, but I haven't tried hard enough to say that it can't be done.

@taro The behavior that you're describing is not related to VV's issue, for at least two reasons:

1. It's the behavior of the prefix form, `or`(...), that seems unusual, not the behavior of the infix-form, ... or ..., which you've shown above.
2. The expression x or y in your subs command has already been evaluated to false before it's passed to subs, so the expression doesn't even contain any a for which 0 could be substituted. That is the totally normal behavior of passed arguments, not something special about subs. Compare with eval(value(subsindets(%subs(a= 0, 'x or y'), name, eval))), which returns true. (Hey! I think that that's the most sophisticated multi-level delayed evaluation that I've ever done!! And I think that every layer there is necessary!)

@taro I don't know the reason, and I don't believe (or perhaps it's that I don't understand) VV's argument for the intentionality or usefulness of the behavior. It just seems like a nuisance to me, although it's not such a great nuisance that I'd call it a bug. Note that in all of the of the most-common contexts that require that they be evaluated, such as in an if statement, they automatically evaluate anyway.

@danielpf In the way that it's used that's akin to how sum is used, i.e., with an index variable, add is much older than Maple 2015! I've used Maple extensively since Maple V r4 (circa late 1990s), and I don't recall any version that I've used not having add. What changed in Maple 2015 was possibly an update to add that allows an unindexed form of the command to be used on data containers, for example, add([3,5,7]).

@Rohith Sorry, I just now see that you changed my filter, and that you're now wondering why your change didn't have the desired effect. Specifically, you added `&/`(1, name) to the allowed operands. My Reply immediately above was written  under the assumption that you were using exactly the same filter as I had written. So, now your question makes much more sense to me, and I no longer think that your desired output is an unrealistic expectation!

So, I'd like to discuss at least four things about this:

1. State your desired rules as precisely as possible.
2. The new rule that I infer from your attempted change.
3. Why your attempt didn't work.
4. How to make it work, assuming that what I inferred in (2) is correct.

1. The Rules: This is pretty much what I said in my previous Reply. If you find it difficult to express your desired rules in English, I will be able to infer them from examples that you provide of complicated expressions matched with the desired extractions. The overall rule as I see it so far is that you want to extract all subexpressions consisting of an operator acting on exactly two atomic operands. There is some slight vagueness in that rule about the exact definitions of operator and atomic, and some even slighter vagueness about the definition of operand. That vagueness is what we seek to make more precise.

2. What I infer: I infer that you want 1/X to be considered atomic when X itself is atomic. Is that right? 

3. Why it didn't work: What we deal with here are called structured types, and they form an entire sub-language of Maple. The meta-operators of that language are detailed on the extremely dense help page ?type,structure. I've read that page surely more than a hundred times in the 18 or so years that I've used Maple. The keywords of that language are mostly described on individual help pages ?type,keyword. And it's trivial and common for one to add one's own keywords and meta-operators. This is best done with the package TypeTools.

The meta-operators `&*` and `&+` are predefined, but there is no predefined equivalent for any other operator; specifically, there is no `&/`. Thus your attempt to use `&/` makes it just an undefined function symbol (which is nonetheless allowed by the language). But the function that we're interested in is `%/`, not `&/`.^[1]

4. How to make it work: This is a relatively small change to the filter:

value(
   indets(
      InertForm:-Parse("1/v[0]*V1+1"), #string!
      #selects operators with exactly two operands, both of which are names,
      #negated names, reciprocals, integers, or floats:
      And(
         specfunc(
            {name, numeric, (-1) &* name, 1 %/ name}, #atomic operands
            {`%+`, `%*`, `%/`, `%^`} #desired operators
         ), 
         Not(1 %/ name), #subtract reciprocals
         2 &under nops #exactly 2 operands
      ) 
   )                                            
);

If the above is rejected by your system with a syntax error (which may happen due to an older Maple), replace 1 %/ name by `%/`(1, name) both places that it occurs.

This is getting complicated enough that we should now expand the type language with our own keywords to handle it. This will allow recursion. This will be the subject of my next Reply.

^[1]Although it's tangential to this discussion, you're probably wondering at this point What's the difference between & and %? And what do the quotes `` mean? And how's that different from the other quotes " " and ' '?

Answer: Prepending % to an operator or to an ordinary function name or to even to a plain alphanumeric symbol makes it inert. Applying value to an expression removes one level of inertness from all of its inert subexpressions. Multiple %s can be used, as long as it's done inside `` (aka back quotes, left quotes).

An effect akin to inertness (known as delayed evaluation or unevaluation) is achieved by enclsoing an expression in single quotes ' ', as in x:= 'x'. Whereas the inertness achieved with % is stable---an expression doesn't become active until you explicitly remove the inertness---the delayed evaluation achieved with ' ' is ephemeral and often quite frustrating to work with because there are many things that can cause expressions to spontaneously evaluate.

Prepending & to an operator or plain alphanumeric symbol allows it to be used as an infix operator, that is, it can be placed between its operands. Unlike the situation with %, there is no semantic connection whatsoever between an &-operator and its underlying symbol. Thus, this is the mechanism by which new infix operators can be defined.

Enclosing any string of characters whatsoever (no matter how complicated, reserved, lenghty, unprintable, or empty) between the back quotes ` ` turns it into a symbol. The kernel's parser then ignores its internal contents (although the GUI does not). This allows you to use it in a variety of contexts where its internal characters would otherwise confuse the parser. For example, if an &-operator is used other than as an infix operator, then it must be enclosed by ` `.  

Double quotes " " are very similar. They are used to form string literals. The difference between symbols and string literals is that symbols are used for a variety of purposes (e.g., they can be assigned values and be variables), but string literals are just simply string literals, as in most other computer languages.

All three type of quotes are always used in pairs in the Maple (1-D) Input. Prime symbols might be used for differentiation in the 2-D Input. I'm not sure because I try to avoid that Input form as much as possible.

@Rohith Like I said, you need to provide a large variety of more-complicated examples matched with the output you desire. If you don't, we're just going to go back and forth like this a hundred or so times, each time making a small adjustment to the code.

What part of the following rules don't you like? I may be able to change the rules:

1. 1 is an atomic operand.
2. v[0] is an atomic operand.
3. / is an operator.

Therefore, the only subexpression consisting of an operator acting on exactly two atomic operands is 1/v[0]. My code has precisely fulfilled the rules that you've put forth.

If you changed the input to V1/v[0] + 1, then you'd get the output that you expect. But I thought that part of the point of your project was to analyze the raw-form input, before it's simplfied (either manually or by Maple).

@taro VV has followed that help page advice 100% correctly. The problem being discussed here has nothing to do with the use of quotes.

@Kitonum The difference that this makes in the  layout of the problem is interesting. It can be simplified to

Grading:-Quiz("What is the sum?", (R,A)-> value(A)=R, ()-> `%+`((rand(1..20)$2)()), inertform);

@taro Compare the  output of these two:

eval(Diff(sin(x), x), x= 0);
subs(x= 0, Diff(sin(x), x)):

The eval knows that the x is a bound variable inside Diff, and subs does not.
 

@taro Although your subs command produces the correct result in this case, it's a bad choice for three reasons.

1. subs doesn't "know" any math, it can only blindly make substitutions, some of which may not be mathematically valid. That's why eval(e, x= a) is the preferred alternative to subs(x= a, e) in situations where something mathematical happens to e immediately afterwards, (which is most situations).

2. subs doesn't evaluate its result. For example, try subs(x= 0, sin(x)).

3. If x= a and y= b are independent substitions into e (in particular, the order that they're done doesn't matter), then subs([x= a, y= b], e) is far more efficient than subs(x= a, y= b, e).