@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

@sand15 The idea of using DelaunayTriangulation is nice. Vote up for ingenuity.

I get the following image and timing of the computation, in my Maple 2022.2. (I corrected some missing statement terminators in the code you showed, but made no other significant changes.)

If I may make some constructive comemnts:
- The boundary is still somewhat rough. I still believe that this is cured better by superpositioning curves along the boundary than by refining the implicitplot options. [I am going to add such an attempt in another Answer thread.]
- There appears to be a chunk missing from the bottom-most tip of the transformed region.

Download plot_transform_sand15.mw

@FDS Note that the changes that I made to your Maple code make it more like what you showed for Mathcad: I made operator f take both p and i as parameters, and inside f it has Hb[i] and k[i] as indexed references.

For fun, here's another approach, this time dealing with the OP's first example.

restart; with(plots):
P := densityplot((u,v)->`if`(`or`(u^2 + 4*v^2 <= 4,
                                  `and`(u^2 + v^2 < 4,
                                        (u + 2)^2 + 2*v^2 <= 4*v)),0,1),
                 -2..2, -1..2, grid=[301,301], style=surface, labels=[u,v]):
P2 := subsindets(P,rtable,r->ImageTools:-Threshold(r,0.6,low=0.0)):
display(plottools:-transform((u,v)->[u^3-v^2,u^2-v^3])(P2),
        view=[-8.2..8.2,-4.2..4.2], axes=boxed);

I suppose that implicitplot could produce a boundary curve, which when transformed would give the boundary of the above a cleaner look.

note: The higher-than-default grid resolution puts a greater burden on the GUI's plot renderer. But the approach has the advantage of being simple. It also avoids some difficulty that thin-polygon-strip-fill approach can have when the region is not convex.

note. Other approaches are possible.

@Thomas Dean It works on (ubuntu) Linux, for me, using either Maple 2021.2 or 2022.2.

ps. You tagged your Question as Maple 2021.  Your latest Reply mentions Maple 2022.2. Which is it?

@Thomas Dean You mention having explicit multiplication symbols in the output. It sounds as if that is your primary motivation here.

In the following attachments I first set the GUI menubar item:
   Tools->Option->Display->Maple Notation

Then I executed the whole worksheet. That gave me line-printed expression output (with explicit multiplication symbols) and properly rendered plots.

That worked for me in either Maple 2021.2 or Maple 2022.2, both for Linux.

plot-problem_ac_M2021.2.mw
plot-problem_ac_M2022.2.mw

I left other items as their defaults, ie:
 -- Maple 2021.2  interface(typesetting) returns standard
                            interface(prettyprint) returns 3
 -- Maple 2022.2  interface(typesetting) returns extended
                            interface(prettyprint) returns 3