@mmcdara You can also see the Help page for topic Complex. It wasn't clear to me whether you wanted details on that as well as on I.

And the DAG internal structure COMPLEX is mentioned in the Appendix to the Programming Guide.

I don't quite see why you'd find disassemble more to the mark than dismantle here (unless you needed to programmatically manipulate the DAG type results). Each to his own, I suppose.

(You might also be interested in the Float and SFloat constructors, if you're digging around.)

@rlopez In the original the name `a` is buried within a proc, so naturally Explore doesnt see it.

My solutions made the a name literally present as part of the first argument passed.

One of my suggestions was to use the expression a*x+y , just as you had it. In that case Explore replaces nonparameter assigned `a` with its value in what it stores in the Components . (Having `a` as a parameter is also possible, as you did.)

Here are four ways to adjust your example so that the earlier value assigned to name a is re-used in the earlier exploration, even following reassignment to a.

I am leaving out simple mechanism of simply having the execution group that calls Explore also do the desired assignent to a. In that case you could just rexecute that group, recreating the exploration while reassigning a as wanted.

The next four ways involve being able to immediately manipulate the Sliders in each of the explorations, without reinvoking Explore, and have them respect the value of a when the explorations were created.

1) Use uneval quotes and an eval call, so that the call f(x,y) evaluates and produces the returned expression in which the current value of a has replaced the instance(s) of a.  Explore_problem_ac1.mw

2) Use an expression rather than a procedure, to define f.  In recent Maple versions the assigned name a in the expression will get resolved to its value when Explore is/was called.  Explore_problem_ac2.mw

3) Call Explore on a procedure call of a procedure that takes a as an additional argument. (It works for the same reason as 2) above.) You could alter your procedure f, but since that might be awkward for you I show how you can create a wrapping procedure F.  Explore_problem_ac3.mw 

4) It's inefficient to F, and better to rewrite f. So here it is with rewritten f instead. You may find this the simplest way.  Explore_problem_ac4.mw

I suppose that the example you attached in a Reply to Carl's Answer might be merely a toy example, and that you actual work might be more involved. If, say, some more involved procedure f cannot be invoked with arguments nonnumeric x and y (due to conditionals needing to resolve, etc) then approaches 1) and 2) may well not work for you and 4) might need Explore(plot('f'(x, y, a)), y = 0 .. 10) instead.

@vv There will always be further examples requiring further work. In anything.

More problematic is something like  (x+sin(x))*_C2  since "sorting" wrt its first term is a problem.

restart;
F := proc(Sol,Cbase::name,cbase::name)
  local Cnames,cnames,csol,K,k,S,t;
  Cnames := indets(Sol,suffixed(Cbase, posint));
  if nargs=3 then
    S := [seq(Cbase||k=cbase[k],k=1..nops(Cnames))];
    cnames := map(rhs, S);
  else
    S := [];
    cnames := Cnames;
  end if;
  csol := subs(S,Sol);
  K := indets(csol,
              And(`*`,satisfies(u->ormap(type,[op(u)],
                                         {identical(cnames[]),
                                          identical(cnames[])^anything}))));
  for k in K do
    t:=remove(type,[op(k)],
              {identical(op(cnames)),identical(op(cnames))^anything,
               And(`+`,Not(polynom)),`+`^anything,function^(rational)});
    sort(k,t);
  end do;
  return csol;
end proc:

sol := y(x) = _C1*x*sin(2*ln(x))+x*cos(2*ln(x))/sin(x)*_C2:
F(sol, _C);
                                     _C2 x cos(2 ln(x))
         y(x) = _C1 x sin(2 ln(x)) + ------------------
                                           sin(x)      

# more irritating, and even shorter
#sol := x*(x+sin(x))*sin(x)^p*cos(2*ln(x))/(x+cos(x))*_C2^2;
sol := (x+sin(x))*_C2;
                    sol := (x + sin(x)) _C2

F(sol, _C); # oof
                        (x + sin(x)) _C2

@vv The probability isn't very low, as evinced by the fact that the OP has already run amok of inadvertant/undesired ordering even in his generated results containing the _Cn names.

My scheme in the other thread has been adjusted for your example there. Other adjustments are also possible. I aver that a suitable approach for obtaining a desired manner of ordering of terms in output is to have a programmatic mechanism for forcing the reordering (if such a thing is generally possible -- it might not be).

[edit] Thanks for changing the names to which things were assigned. Those assignments were not necessary for my counterexample, so I changed them too.
Using a local name c is possible, as long as no other process resorts any of the results, which might be unlikely. But having escaped locals, with further manipulations being programmatically awkward (and breakable by resorting) is somewhat dodgy -- a bit like asking for difficulties later. But maybe it's the most generally applicable solution.

@vv Thanks. This too can be accomodated.

Here one can use a modified procedure to correct this example too, following misordering.

sol := y(x) = _C1*x*sin(2*ln(x))+_C2*x*cos(2*ln(x))/(x+sin(x)):
bad := sort(sol, [_C1, _C2]):

lprint(sol);
  y(x) = x*sin(2*ln(x))*_C1+1/(x+sin(x))*x*cos(2*ln(x))*_C2

F := proc(Sol,Cbase::name,cbase::name)
  local Cnames,cnames,csol,K,k,S;
  Cnames := indets(Sol,suffixed(Cbase, posint));
  if nargs=3 then
    S := [seq(Cbase||k=cbase[k],k=1..nops(Cnames))];
    cnames := map(rhs, S);
  else
    S := [];
    cnames := Cnames;
  end if;
  csol := subs(S,Sol);
  K := indets(csol,
              And(`*`,satisfies(u->ormap(member,cnames,[op(u)]))));
  for k in K do
    sort(k,remove(type,remove(type,[op(k)],`+`^anything),identical(op(cnames))));
  end do;
  return csol;
end proc:

F(bad, _C):

lprint(%);
  y(x) = _C1*x*sin(2*ln(x))+1/(x+sin(x))*_C2*x*cos(2*ln(x))

@vv Your procedure Cc may not produce the desired result if the terms have been created misorderded previously in the session.

Eg,

restart;
ex1:=1/cosh(x)+   (cosh(x)^2+cosh(x)*sinh(x)+x)/cosh(x)*_C1 + x*exp(_C3+x+_C2)*C:
ex2:=_C1/cosh(x)+ (cosh(x)^2+cosh(x)*sinh(x)+x)/cosh(x):
ex3:=_C1/cosh(x)+ (cosh(x)^2+cosh(x)*sinh(x)+x)/cosh(x)*_C2:
1/cosh(x)+   (cosh(x)^2+cosh(x)*sinh(x)+x)/cosh(x)*c[1] + x*exp(c[3]+x+c[2])*C:
c[1]/cosh(x)+ (cosh(x)^2+cosh(x)*sinh(x)+x)/cosh(x):
c[1]/cosh(x)+ (cosh(x)^2+cosh(x)*sinh(x)+x)/cosh(x)*c[2]:
Cc:=proc(u)
  local Cc1 := C -> c[parse(convert(C,string)[3..])];
  subsindets(u, `*`,
    proc(u)
      local k,r;
      k,r:=selectremove(type, [op(u)], suffixed(_C,integer));
      if nops(k)<>1 then return u fi;
      `*`(Cc1(k[]),r[])
    end):
  subsindets(%, suffixed(_C,integer), Cc1)
end:
Cc(ex1); Cc(ex2); Cc(ex3);

@mmcdara No problem.

ps. It would be nice if 2D and 3D plotting allowed options to specify axis-direction easily, so that it wouldn't be necessary to fake the effect through tickmarks forced at negated values. (Mma and Matlab do.)

See an Answer to a recent Question.

It would be better if you showed us explicitly what you tried.

You can use the green up-arrow in the Mapleprimes editor to upload and attach a worksheet.

Download bsolve_2020.1.mw

The Calculus1:-Roots command tries several variant calls to solve. It also uses _EnvSolveOverReals=true which gives the same effect as passing the real option. I know that the real option is currently only properly documented under solve,parametric, but in fact it has some beneficial effects in some univariate cases without parameters.

[edit] Of course, supplying the real option alongside the allsolutions option should not be necessary in the presence of the inequalities which denote a real-range.

@Kitonum In my Maple 2020.1,

restart;
kernelopts(version);

  Maple 2020.1, X86 64 LINUX, Jun 8 2020, Build ID 1474533

assume(x, 'real'); assume(y, 'real');
verify(x^2 - x*y + y^2, 0, {'greater_equal'});

                 true

is(x^2 - x*y + y^2>=0);

                 true

restart;
verify(x^2 - x*y + y^2, 0, {'greater_equal'}) assuming x::real, y::real;

                 true

is(x^2 - x*y + y^2>=0) assuming x::real, y::real;

                 true

@KGaurav08 Something like this or this?

@Panas95 So that leaves the matter of why it worked for me but not for you. Do the commands I showed produce the same results in your Maple 2019? If not, were there any other assignments or assumptions on x or y in your problematic session?

@Carl Love Your commentary about precedence for unbracketed input may be true, but it is not directly relevant to the OP's example. Your comments about problems with precedence and parsing or inert operators input are not what went wrong in the OP's example.

The ife expression (containing inert operators) in the OP's example is properly nested, and comes from parsing (with precedence properly respected) of a string onvolving non-inert operators.

The problem in the OP's original example is in the typesetting of the properly nested inert operator expression, not in any parsing of an earlier input or representation.

The "more-important bug" that you describe is not what cause the OP's problematic typesetting here.

The "more-important bug" that you describe relates to parsing of 1D input. The OP's problem was in lack of bracketing in typesetting of 2D output.