@zenterix 

I suspect that the problem has something to do with how densityplot is constructing the x-y values. Any deviation in how it constructs, say, the y-values and you could get a slightly different value (float or HFloat, it hardly matters) and a mismatch with the indices of the inner tables. It seems like a fragile idea to try and match those values with more than one routine that splits the range. I think that I won't bother to try and further adjust that methodology.

Instead of relying of densityplot to get a precise match in the index values, you could turn the tables in T into Vectors, ie. turn all of T into a Matrix. In this way the actual indices are re-used to access the inner entries, with no mismatch.

You could then plot that Matrix using listdensityplot or surfdata.

Download table-hfloat_ac.mw
 

note: If the Matrix m1 has its entries arranged in an orderly fashion (ie. sorted wrt to both 1st and second columns -- I didn't bother to check) then the Matrix I used to plot could be constructed more directly, without need for all this table business. Or unprovided process which generates the m1 Matrix could be adjusted to construct the Matrix I used just above for plotting.

The Matrix MMM above, and Vectors of the common x- and y-values, could be used to build an interpolating procedure. That could be used to provide a smoother gradient of color. It could also be used with densityplot.

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.