@Anthrazit When you load one of the Unit computational environments (Units:-Simple, Units:-Standard) it rebinds various commands (`+`, `*`, etc) to the respective package exports which also combine the units of the results.

By combining the units I mean that the units get converted to the standard or base units for the given system (eg, SI). Thus 10*millimeter+4.0*meter produces 4.01*m, etc.

That affects computations done that explicitly utilize those commands. For example, computations done at the top-level are such explcit calls.

(**) But loading the package does not change such computations (even arithmetic) with units inside most (almost all) procedures that are part of the main Maple Library (.mla of interpreted procedures). Loading the Units package by the with command rebinds the command names but it does not reassign the global command names.

That is why arithmetic that happens during Matrix addition does not combine the units.

That is why you might also want to call combine(...,units) on scalar results, or map that across Matrix/Vector/Array results.

By the way, the distinction I made in paragraph (**) above affects all packages which rebind names of exports. For user-authored packages an alternative is sometimes to use objects which have their own static methods (keyed upon global command names, for example). But Units have not been re-implemented as objects, and it is tricky to do so robustly.

note. Earlier I had been under the impression that you already knew these further points, which is why I have limit myself to addressing deeply only the matter of the multiple, distinct, local unit symbols in your result. The business with the multiple local symbols is an unusual and rare quirk (and a bug that I reported), whereas this further business of combining units is more common and (for better or worse) part of the current Units design.

@mmcdara (I suspect you meant to address Carl -- who responded -- and not me.)

You might have a look at the extension Help page.

What kind of plot do you want to obtain? Please be specific.

Do you want a 3D plot were the modulus and argument are used to get (say) the height and shading color respectively? (Or, even a 2D plot since the modulus in a particular example may simplify to just 1.)

Do you want a 2D density plot where the modulus and argument are used to get (say) the intensity and hue respectively? (Again, the modulus may simplify to just 1 for a particular example.) Or some kind of contour plot?

@Anthrazit The Programming Guide has some examples (eg. of modules, and procedures, and  packages).

I am happy to make the edits I mentioned later this weekend (and a workaround for your issue). I just wanted to make sure that it would be OK with your ongoing project if I altered the programming style in such ways.

@Carl Love The original won't work in Maple 2020.1 in pasted into a 2D Input region.

But, the revision does. conf_2dmath.mw

@Anthrazit It is not good programming to initialize with all those calls to with, prior to defining all the procedures. It would be better to utilize fully qualified calls (eg, Units:-UseUnit, etc) in the places that need them, or to utilize the uses facility in the procedures in a case-by-case, by-necessity fashion.

It would also be better programming technique to create a parent module for the procedures, so that they can share key variables' values (lg, etc) without them being declared and assigned as globals.

I can fix the problem with the "duplicate" units (un-combined), but I feel that there's less long-term and robust merit in addressing the Units (and Units:-Simple) difficulties unless the programming methodology is overhauled for the points I've mentioned.

@Anthrazit I think that I understand now. It always worked for me, with the various ways of re-executing the whole sheet, extending and re-extending, etc. I'm using Maple 2020.1 for 64bit Linux.

I don't understand what your point is, or I cannot reproduce the problem as I interpret the Question. Your Question's contents are somewhat unclear to me.

The original attachment on your Question was last saved in Maple 2020.1. When I open it in Maple 2020.1 then the component with identity "DataTable1" shows 2 columns.

If I set the number of visible columns of "DataTable1" to one, save and close the Document, re-open it and re-run the whole contents with the !!! (or Evaluate-->Execute Worksheet from the menubar) from the menubar then it updates to reveal the second column.

If I extend rtable b with the command
   b(1 .. 3, 3) := 17
add a line (but not execute it) like,
   SetProperty("DataTable1", visibleColumns, 3)
and then execute the whole Document from the menubar then the third column becomes visible.

Have I misunderstood? Does those experiments behave differently for you?

@ns523 You wrap with a call to the round command, to make it round to an integer value.

@Rouben Rostamian  Thanks. That is the reason why I asked -- which situation was at hand was not evident (to me) from the very short inlined bit of Maple code in the question, and I am on a cellphone with limited access this week and have not followed through the OP's links.

Have you tried the plots:-implicitplot3d command?

(I'm away from Maple, and cannot check.)

Your reasoning about what has happened is incorrect. That is to say, this claim you made is false, about how the internal representation was automatically changed when the expression was formed by the command num/den:

    "Maple automatically replaced -1+x/exp(y) by (-exp(y)+x)/exp(y) and then moved
     denominator of this, which is exp(y), down to the denominator of the orginal expression."

You can check the internally stored form using the lprint and dismantle commands.

What is actually happening is that that numer and denom are not behaving as you would like. (There is a kind of expansion, somewhat akin to what normal does, when those commands are used here. A change like what you described is made to temporary constructs during computation by numer and denom, but even then the original is not altered.)

@Rouben Rostamian  This has been previously reported.

Aside from whether solve can handle the given example, I see some related regression bugs that I will report.

In Maple 2016.2 the first of these below produced a conditional solution involiving a RootOf, and the second issues a warning and set _SolutionsMayBeLost to true.

But in Maple 2017.2 and 2020.1 both return NULL and neither set _SolutionsMayBeLost, which is wrong.

restart;
solve({sin(x)*x-1,x>=-200}); # returns NULL
_SolutionsMayBeLost;

# ..and similarly for solve({x^3*sin(12*x)-1, x>6/5, x<2})

restart;
eq1:=x^3*y=1:
eq2:=y-sin(12*x)=0:
solve([eq1,eq2,x>0],{x,y}); # returns NULL
_SolutionsMayBeLost;

@janhardo Earlier, I had the wrong sign for the new RHS. I corrected that in the answer.

I also showed a couple of ways to adjust the appearance of the terms.

In order to obtain (programmatically) some specific manner of arrangement of the terms then is it not reasonable to first characterize that with a definition?