@C_R The small module L may be augmented to rebind lhs and rhs as well.

Logic_2DInput_lrhs.mw

(You could also guard against incorrect number of arguments, if you'd prefer some customized error message, etc.)

What exactly are you hoping to construct using the plot3d command? Please be clear.

@jrive An alternative approach to your example is to use a particular option with the simplify command. This calling sequence is called simplify-with-side-relations.

For this given example, that command can handle just the first substitution, or the entire problem.

Download jrive_ex4b.mw

@delvin You've mistakenly attempted to enter the various lines of a proc definition across multiple paragraphs. But it has to be entered in a single paragraph (or execution group).

@delvin There's no mystery as to how to end a Maple statement with a full colon -- it's a key on your keyboard.

Sometimes it's worthwhile checking the size of potentially large expressions, before printing them. There's often only so much insight to be had from looking at wallpaper of formulas. Simplifying large expressions before printing them can also be useful.

03_ac.mw

(You might want some other, alternate rearrangement of the terms, but if so you then haven't described it.)

Please put your followup example here, instead of spawning a wholly separate new Question thread for it.

@Thomas Dean with the local declared...

Download seqlocal.mw

@RezaZanjirani You are very welcome. I'm glad that you have it working as you want.

Note that what I did in your worksheet (in my Reply above) is the same approach that I'd shown in the first example&attachment in my Answer.

@Carl Love I recalled some of the OP's earlier postings using the same basic code layout. Some of his "parameters" are the global names to which he's assigned values, rather than some procedure's parameters having values passed into a call.

ps. It sure does help when people provide their actual code in an attachment to the Question.

@RezaZanjirani It seems to work, respecting the rhs&lhs of the inequality, as well as preserving the symbol c unevaluated, whether one uses,
   Typesetting:-Typeset(p__s < c)
or,
   Typesetting:-Typeset(c > p__s)

Scenario_ac.mw

Scenario_ac2.mw

So I'm not sure I understand what you mean when you state, "But it does not work on my own code".

ps. Your code has the input as c>p__s , by the way, though you indicate elsewhere that you want it as p__s<c.

@sand15 A fundamental danger of your trick is that some denominator involved in the computation for the generic x[i,j] could be mathematically zero when replaced by the B[i,j] expressions. Subsequent evaluation of the final result can then fall prey to the division-by-zero time-bomb.

@FDS To the right of an Answer's title is a thumbs-up icon and (if you posted the Question) a cup icon.

Anyone (with reputation score of at least 10) can vote-up an Answer by clicking the thumbs-up icon.

The person who posts the Question can also accept it as best by clicking the cup icon.

Naturally, you are free to do this for any of the Questions you post in this forum.

@Rouben Rostamian  The worksheet attached by simplevn1967 was saved by him using Maple 17 (released 2013).

@lemelinm The effect of your first suggestion -- to control the color of the surface "grid" lines differently from the color/shading of the surface -- is already mostly possible to achieve, and without having to recompute the surface's data points (eg. z-values).

The key here is to compute (once) the plot values, either as pure surface or pure wireframe style. Then the other can be constructed by overriding that option, ie. without recomputing the values.

For example, (and you could also adjust other qualities of these wire-frame lines, eg. thickness=2 , etc),

with(plots):
P := plot3d(-x^3+y^2,x=-1..1,y=-1..1,style=surface):
display(P,display(P,overrideoption,
                  color="Orange",style=wireframe));

Naturally, that example applied the override only to a single surface. One might well not want to have it as a blanket effect on all compound parts of a VolumeOfRevolution result. (But even there, it can be done selectively, with a bit of care.)

I'd agree that a simple choice of options for the effect you've described would be more user-friendly. On the other hand, there are several other things I'd rather take priority. Eg, separate x/z, y/z, x/y aspect ratios for the axes.

ps. I think that jtreiman's original suggestions (at top) produce a result that is easier to interpret than the default for the command in question.

@Christopher2222 Calls to time() ought to be calls to time[real]().