@mehdibaghaee The easiest way free up the memory used by A, whether it's an Array or something else, is

A:= 'A':

The memory may not be immediately freed, but the garbage collector will eventually get around to it.

@Joe Riel I totally understand the unfortunate theoretical need to substitute for both term and 1/term; however, did you find that necessary in this particular case? I did not.

@Carl Love I just noticed that you did something in your worksheet that provides examples of why you shouldn't re-enter output as input. When you assigned the value of Z, you changed the independent variable from t to x. In this case, that change does not cause any error, but in some other situations it could've. Another problem with it is that it seems unmotivated, and therefore could be confusing to the reader.

I don't know what you mean by f(x,1)=2x^2-x-1. Do you mean that you have a surface z = f(x,y), and you want to show its intersection with the plane y=1? I could show you how to do that with spacecurve; however, you may find the command plots:-intersectplot more convenient for your overall project.

@Rohith You wrote:

• I absolutely not expectede that I would end up at this stage. I would like to say sorry for extending this and kindly, excuse me.

It's no problem for me. I consider what we've done so far to be trivial, and I'm hoping that you will be providing more-complicated cases. Indeed, I will be disappointed if you don't.

So, in the present situation, you want associative operators (`+`, `*`) with three or more operands to have their operands grouped pairwise. This is called folding, and the Maple commands that handle it are named foldl and foldr, the difference in the two being whether a+b+c is changed to (a+b)+c or a+(b+c). 

Here's the code that handles this new issue, as well as all previous cases. I have handled the folding by active manipulation of the Parsed input rather than the type specifications that I used for the previous cases.

RohithExtract:= module()
uses TT= TypeTools, IN= InertForm;
local
   TryRemoveType:= (T::name)-> if TT:-Exists(T) then TT:-RemoveType(T) else fi,
   TryAddType:= (TH::(name= anything))-> (TryRemoveType(lhs(TH)), TT:-AddType(op(TH))),
   AddedTypes,
   ModuleUnload:= proc()
      (TryRemoveType@lhs)~(AddedTypes);
      :-`print/Rohith`:= ':-`print/Rohith`';
      NULL
   end proc,
   ModuleLoad:= proc()
      TryAddType~(
         (AddedTypes:= [
            #With recursive types, put base cases at beginning to avoid infinite loops!
            'Atomic'=     'Or'('name', 'numeric', 'InertRecip', 'Negated'),
            'InertRecip'= 1 %/ 'Atomic',
            'Negated'=    (-1) &* 'Atomic',
            'AssocOps'=   'And'('specfunc'({`%+`, `%*`}), 'patfunc'('anything'$4)),
            'Operators'=  'specfunc'('Atomic', {`%+`, `%*`, `%/`, `%^`}),
            'Rohith'=     'And'('Operators', 'Not'('InertRecip'), 2 &under nops)
         ])
      );
      :-`print/Rohith`:= Rohith-> value({args});
      NULL
   end proc,

   #Associative operators with > 2 operands are regrouped pairwise.
   Fold:= E-> subsindets(E, AssocOps, OP-> foldl(op(0,OP), op(OP))),
 
   ModuleApply:= (E::string)-> 'Rohith'(indets(Fold(IN:-Parse(E)), 'Rohith')[])
;
   ModuleLoad()
end module:

I've changed the way that the output is handled, so that it comes in both an inert form and a prettyprinted evaluated form. The "actual" output is the inert form, and you can view it as it's actually stored by using the lprint command. The fully evaluated output, which is what all prior versions returned, is displayed (aka "prettyprinted") by the GUI.

I've thought of one case of a Maple command that returns an unevaluated form with a bound variable that doesn't handle it in a way that is 100% naive: RootOf. Whatever bound variable that it's given on input, it changes to _Z for the returned form. This is still quite crude, and the protection of the bound variable is based only on convention. But it's a step in the right direction. One can see an example of the use of the convention in lines 6 - 8 of showstat(`diff/RootOf`).

@vv Thanks for the corrections. I was unaware of the distinction between functional and prefix, so you've taught me, and I've now removed the latter from my post. Do you think it'd be okay if I say functional form rather than functional notation?

Regarding not: It was my oversight to call it infix. It can't possibly be because it only takes one operand. I have corrected that.

Regarding `!`: It is true as you say that it doesn't mean factorial (nor did I claim that it does) and also (in Maple 2018) that it has no assigned value (nor did I claim that it does). I mentioned it because it's possible to assign a procedure to it and then use ! as an unary postfix operator for whatever purpose one wants.

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