@Jak So just use the red curve(s), and not the blue curve(s).

The red is for eq1=0, and the blue is for eq2=0.

They already (each) have a line style (dash, solid) that changes when eq1<eq2 or not.

I threw both the red and the blue. It is trivial to exclude either in the code I gave.

You can also restrict to any particular quadrant -- just specify the ranges and/or view.

For example, also using an alternate approach with an explicit solve, instead of an implicit plot, for eq1=0. You may wish to treat x[u]=0 specially, or exclude it, say with the view. I used a style dot instead of dash. Adjust as desired.

Download eq1eq2_rev2.mw

@Jak I don't understand what you're saying, sorry.

In what I showed the red curve denotes eq1=0 and the blue curve denotes eq2=0, and their linestyle is solid when eq1<eq2 and dashed otherwise.

Could you explain more explicitly how that is not what you requested?

Is it just that you want the two linestyles reversed in purpose? That's a simple edit to the code I gave -- by just switching the instances of the linestyle override. eq1eq2_rev.mw 

Such a flip produces these:

The cube of the rhs of the first equation is not equal to the rhs of the second equation, so are you sure that you have transcribed it correctly?

You had them as,

  y = (sqrt(x) + 10)^(1/3) - (sqrt(x) - 10)^(1/3);

and

  y^3 = 20 - 3*(x - 100)^(2/3);

[edit] As member vv has observed, you may have written down the second equation wrongly, and intended to have written it instead as,

   y^3 = 20 - 3*(x - 100)^(1/3)*y;

Have you considered uploading and attaching a worksheet that reproduces your problem?

Attach the original document that contains all the relevant definitions (i(t), delta, sol4, and so on).

@gawati2611 Your example was exp(w*x*I) and you stated that x and w should be real-valued, and that you'd want the height to be taken as the modulus.

abs(exp(w*x*I)) assuming x::real, w::real;
                 1

evalc(abs(exp(w*x*I)));
                 1

(I mentioned this earlier, in my original Comment, for the very reason that I wanted to check with you that you understood this.)

You could contact Maplesoft Technical Support about this.

The OP also asked about floating-point error and using the Optimization package.

There is no general facility in that package for estimating quantity of the floating-point error, but there are options for controlling (bounding it). Depending on the method, there are options for specifying a tolerance for optimaility of the objective as well as a tolerance for maximal, absolute constraint violation. (See the Help pages.)

Apart from specifying those tolerances, you can also get additional printing of what value gets used for them (either specified, or as defaults).

Note that actual results may be more accurate (ie. smaller error) than the tolerance -- which is meant to serve as a bound, not an estimate.

Note that additional working precision (Digits) may be required in order to ensure that the tolerances are not met accidentally (wrongly) due to numeric round-off error.

Note that there may be a hard limit (16?) on the number of major iterations for some methods.

Download Opt_userinfo.mw

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