It works for me (not a blank plot), using Maple 2022.2.

Please don't put a close followup query on this topic in a wholly separate and new Question thread.

You could put it in a Reply here, or use the Branch button to connect them.

Your can zip up a .m file and then attach that in this forum.

@Rouben Rostamian  It's not a matter of Worksheet vs Document. It's a matter of the choice of input mode.

Inside text mode (after Crtl-t, say), one can direct enter the "approx" entry from the Common Symbols palette.

Inside text mode (after Crtl-t, say), one can also enter Ctrl-r and switch to 2D Math input mode, and then back to text if wanted. In Maple 2022 one may need to select the entered math use the right-click menu to convert to non-executable math, however.

Download text_math.mw

@Mikhail Drugov If you mouse-select and then do the right-click menu action,

   2D Math -> Convert To -> Atomic Variable

then afterwards you could use Maple's lprint command to see the underlying structure that is being pretty-printed.

Below we can see that in the case of the superscript the result is a Maple name (ie. surrounded by single left-ticks, also known as name quotes). The structure of the name looks similar to MathML.

Download msup.mw

Sometimes it's even convenient to use nprintf to programmatically construct the special name.

@Mikhail Drugov Here are three ways to get the * in the superscript without getting either single  left-ticks visible, or any parsing as conjugation, etc.

Note the the first way uses a methodology I mentioned in my earlier Answer.

misc_superscripts.mw

@zenterix These examples led me to notice a GUI regression in lprint of HFloats, which I suspect began in Maple 2021.

I submitted a bug report.

@zenterix I'd likely have gotten there sooner if the second attachment's example in the original Question had not been mistakenly cast, which purported to show the background motivation or, as you wrote, "...why I want to create such a table". That example had all integer indices, or "keys" as you phrase it.

So it isn't true that, "..the issue in both cases I presented boiled down to this one thing", where one thing is, "...accessing an entry in a table with a decimal key." It isn't true because you gave three examples in three attachments, not two cases. And the third example had all integer keys.

Also, the problem was not merely because the indices were floating-point values ("decimals" as you phrased it) , but more precisely because some of the indices were hardware floats.

It's possible that the process might be rewritten to use listdensityplot, which at least could get rid of the trunc (though perhaps less efficient). I didn't bother with any major rewrite.

I didn't suggest anything like setting UseHardwareFloats to false, (or elementwise Matrix multiplication, etc) as I don't know how well this whole process has to scale.

@zenterix I don't understand why you didn't provide the actual example of what you really wanted to accomplish, with the appropriate data, up front.

Here is one way,

Download convertArrayToTable_ac.mw

Please don't start a completely separate Question thread for close followups of this.

@sand15 As an afterthought: I'm not sure I see why the triangulation isn't just lucky to not have any triangle that spanned across a key portion of the input region, and that when transformed would not (split and) hence not respect some concave aspect of the output region.

It that is so then I'm not sure that an algebraic analysis (and some kind of splitting) might not be needed in general, to accompany an approach of fill-by-triangles/polygons. Am I wrong? I often am.

While discussing alternatives, here's another quick alternative - possibly in said class of luckiness.

restart; with(plots): with(Optimization):
ineq1 := u^2+v^2<4: eq1:=u^2+4*v^2<=4: eq2:=(u+2)^2+2*v^2<=4*v:
(Eineq1,Eeq1,Eeq2) := subsop~(0=`=`,[ineq1,eq1,eq2])[]:
K := solve([Eineq1,Eeq2]): T1 := eval([u,v],K[1]): T2:=eval([u,v],K[2]):
Tumax:=Maximize(solve(Eeq2,u)[1],v=T1[2]..T2[2])[1]:
Tumin:=Minimize(solve(Eineq1,u)[2],v=T1[2]..T2[2])[1]:
display(shadebetween(solve(Eineq1,v)[1],solve(Eeq2,v)[2],u=Tumin..T2[1]),
        shadebetween(solve(Eeq2,v)[1],solve(Eeq2,v)[2],u=T2[1]..Tumax),
        shadebetween(solve(Eeq1,v)[1],solve(Eeq1,v)[2],u=-2..2),
        overrideoption,transparency=0,color="Niagara Azure",axes=boxed):
plottools:-transform((u,v)->[u^3-v^2,u^2-v^3])(%);

Also, in jest, one can even get lucky if plots:-inequal is called in a (here ad-hoc) special manner. (Naturally, this lacks the smoothest boundary since no boundary curves are constructed.)

restart; with(plots):
ineq1 := u^2+v^2<4: eq1:=u^2+4*v^2<=4: eq2:=(u+2)^2+2*v^2<=4*v:
F := plottools:-transform((u,v)->[u^3-v^2,u^2-v^3]):
copts := gridrefine=0,crossingrefine=20:
opts := optionsimplicit=[copts],nolines:
P2a := inequal(eq1, u=0-1e-6..2, v=-1..2, opts):
P2b := inequal(eq1, u=-2..0-1e-6, v=-1..2, opts):
P1a := inequal(And(ineq1, eq2), u=-2..-1/2, v=0..2, nolines,
              optionsimplicit=[grid=[7,29],copts]):
P1b := inequal(And(ineq1, eq2), u=-2..-1/2, v=0..2, nolines,
              optionsimplicit=[grid=[29,7],copts]):
display(F(P1a),F(P1b),F(P2a),F(P2b),axes=boxed);

@C_R It seems on-topic, then, to mention to your that the contents in the plotting substructure created by the (lowercase) typeset function call are not guarded against further evaluation.

That's also a consequence of the fact that plotting structures are just unevaluated function calls of (mostly) protected names. That's very old functionality.

In consequence, some differences may occur if such a plot gets further evaluated (by a top-level reference and full evaluation, being passed to a function call, etc).

Consider the following example, in which one wants the call sin(Pi/3) to be pretty-printed but not evaluated. Notice the accidental evaluation resulting in the unwanted sqrt(3)/2, and ways to avoid it.

I'm not going to bother to show the poor workaround of throwing extra unevaluation quotes (single right-ticks) around the expression.

(Inside a procedure, if name P were declared local, then referencing it after assignment would incur only 1-level evaluation -- with this problem not occuring.)

Download typeset_plot_eval.mw

These days there are alternative data structures that the system might better use for plotting. But too much code to change. It might be better if the plotting command preprocessed such (lowercase) typeset calls more robustly.

Is this 1D input or 2D Input? If the latter, is it in an Execution Group (red prompt), or a Document Block?

Does it happen only with your created palette's item(s), or any other stock item from a stock palette?

What happens when there is some expression both to the left and the right of the cursor?

It's probably worthwhile mentioning that there are other approaches than applying plottools:-transform to the a plot of the u-v region imposed by the implicit constraints.

For example, one might combine several filled parametric plots (or shadebetween calls), constructed directly using the transforming formulas for the 1st and second coordinates. However this may require sophisticated splitting/decomposition of the u- and v-domains into several manageable subdomains, based on the supplied inequalities. Not so hard for this example, but harder to generalize.

@sursumCorda I suspect that the best way to get smooth boundaries is to superimpose actual curves over whatever is used for filling the interior region (MESH, POLYGONS, GRID, whatever).

Below I construct such boundary curves and lay them over a DelaunayTriangulation (the idea for using such being due to member sand15).

Since I construct these boundary curves, I also have their data points for use in the triangulation. That's in contrast to sand15's approach of using the vertex data from the POLYGONS that plots:-inequal generates. Both approaches have pros & cons.

- triangulating POLYGONS data from plots:-inequal
  Pros:  the triangulating data is generated automatically.
  Cons: misses a chunk from botton corner for this example.
             boundary is ragged unless refinement is exorbitantly high
             or boundary curves constructed anyway.
             no visual distinction between strict and nonstrict inequalities
             is present, absent separate construction of boundary curves.

- triangulating data from computed boundary curves
  Pros: same curve data can be used for triangulating,
           for this example at least apparently more robust at cusps.
           the curves can optionally distinguish which boundary curves
           arise from strict inequalities.
  Cons: far less automatic (I think I could automate it, but it's not easy.)
            note: These curves are not adequately produced by plots:-inequal

The code below produced this plot, in about 0.68 seconds in my Maple 2022. For this I commented out the line that reassigns to PI the curve with linestyle=dot.

And here is the code with the optional visual cue of a dotted boundary curve to indicate the strict inequality.

I suspect that I could speed up the transformer for the polygons and make this faster. But programmatically automating construction of the boundary curves is more intriguing.

Download plot_transform_example1c.mw