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.

@wswain You have misunderstood my subsindets calls, I'm afraid.

Let's look at this call:

   subsindets(convert(Array3[1, 2..], list), string, u -> u[5..])

The first argument is convert(Array3[1, 2 .. ()], list) , which produces a list.

The second argument, string, is not a transformer. It is a type, that subsindets uses to distinguish which subexpressions to transform.

The third argument, u -> u[5..] is the transformer.

There is no fourth argument there, ie. none like rest in the Calling Sequences on the subsindets Help page.

I could see that the only strings in the first row were the ones with the substring prefix "RPM " which I wanted to remove. I could also have used StringTools:-Drop, or a few other StringTools commands. It seemed to me that indexing was simpler. Eg,

ee := "RPM 101 - 200":
ee[5..];

             "101 - 200"

StringTools:-Drop(ee, 4);

             "101 - 200"

Contrary to your followup query's claim, I did not convert the entries of Array3[1, 2..] to strings. They already were strings.

I could also have used map directly on the entries of that particular sub-Array, instead of having subsindets target its subexpressions of type string (which happened to be all that sub-Array's entries, anyway). Eg, using that Array3, these last three lines accomplish the same thing.

L := convert(Array3[1,2..],list):
subsindets(L, string, u->u[5..]);
map(u->u[5..], L);
map(`?[]`, L, [5..]);

There are often several ways to accomplish manipulations. I didn't think much about which might be best here -- whatever "best" means.

Your example is small, and you might not need the code to scale up. At some point you may choose to balance between legibility, flexibility, and efficiency.

[edit] I am not a big fan of arcane and slick functional programming if the efficiency needs don't demand it. I don't think that it's highly legible for newcomers to Maple, and it can be difficult for them to debug.

@ceight1 Here is one way, which you adjust to other examples.

The embedded Table looks better in the actual Maple GUI than it does inlined in this forum.

HELP_CODE_ac_tab.mw

@wswain At the very least you should explain what you mean by,

     ...RPM range text =  "0-100, 101-200, 201-300", etc.  for each
     bin and rotated vertical to fit.

Keep in mind that you haven't even explained what the two axes of your plot are supposed to represent, if the above quote truly relates to axis labeling. If it instead relates to some kind of colorbar legend for the ranges of values of the data then please indicate as much.

Providing code that reproduces the output or plots in your Question is usually helpful, often useful to those answering, and polite.

Upload and attach a worksheet that contains code to reproduce.

Why the need to use typeset? Does it not render similarly without that?

@Carl Love When the OP started with his queries [1, 2], there was no mention of LaTeX in the Question bodies. And so my previous responses [1, 2] were only about printing in the Maple GUI, and not about LaTeX export.

I have previously had some small success in using an XML add-on package in LaTeX, to cope with some marked up "TypeMK" Maple names. But some entities were a pain. I don't think that I'd go there to make it easier.

@BrettKnoss The second example doesn't need the DataFrame, I just threw it in at the end. It only needs M, a Matrix which stores the data.

The Matrix M gets extended at each iteration by use of the round-bracket "programmer's indexing". The seems simpler than Append on a DataFrame.

@Carl Love From the OP's edited description it reads as if the bug was in his own code, which had a mismatched type declaration on the local variable to which the FetchAll result were assigned.