The plots:-inequal command, which you're already using, provides options for fine control of the lines.

But you have already included the 'nolines' option. So, instead of using that you could simply specify the color of the lines (and without a specified linestyle, it won't be dotted).

Also, you can supply options to implicitplot (which plots:-inequal uses under the hood), to get more clearly defined internal edges of the colored regions (even when the lines are not made visible).

For example,

Download Regional_new_ac.mw

It seems that the expanded ln term on the rhs is the problem.

By utlizing combine on that term, either solve or RealDomain:-solve can be used.

These work quickly,

Download nm_solve_01.mw

Here are various ways you can evaluate the fitted polynomial at arbitrary values of the independent variable.

You can do it with or without forming the polynomial explicitly. You can do it using procedures or eval. And, if forming the procedure explicitly, you can do it with expanded form or Horner form.

The very simplest way (shown at end), is to simply pass an extra name as an argument to the command, and have the command return the explicit polynomial rather than (as you had it) a Vector of the coefficients:
    Statistics:-PolynomialFit(10, X, Y, x)
See also the Help-page, which also describes a returned solution-module which can access various statistics, etc.

And you can then evaluate it for single values, or map that across the elements of X (or any other Vector).

Here are several of those choices. The second to sixth ways include forming the polynomial explicitly. It's your choice whether to also convert such to Horner form.

I also show the ~ syntax for so-called elementwise application of commands, which is a terse way to apply the evaluation across a Vector such as your X.

Download regr_fun.mw

You had misplaced extra double-quotes in your color strings, eg, ""Red".

The markup for those subscripted items is a kind of name, and with the special characters such names have to be enclosed in single left-ticks (aka name-quotes in Maple). Eg,

    `#msubsup(mi("π"),mi("r"),mn("B"));`

and not just (as you had it),

    #msubsup(mi("π"),mi("r"),mn("B"));

which gets interpreted as a comment since the # is bare.

nb. Those left-ticks might not(!) show in the rendering on the inlined worksheet below. See the attached worksheet in actual Maple.

Download Graph_legend_error_ac1.mw

You could look at this general support page, in the section (near the bottom) titled "Contact Technical Support". There are three phone numbers there, for different geographic regions.

Note the effect of wrapping the Re and Im calls by evalc.

Download wingho_1_ac.mw

Download TESTE_ac.mw

You can use the caption option for that, and one way to construct that from your DATA values would be using sprintf.

caption=sprintf("sigma=%.1f, Cn=%.2f, Crm=%.2f, b=%.2f",
                eval([sigma,Cn,Crm,b],DATA)[])

Q_legend_ac.mw

Or, if you'd like that any/all of those names pretty-printed, eg. sigma rendered as the Greek letter glyph,

Q_legend_ac2.mw

note: I have deliberately not merely used uneval quotes (single right-ticks),
because those are ephemeral, and if you later assigned to any of those
names then an evaluation of the plot construct would result in the caption
turning into, say, 0.65=0.65, etc. Maybe unlikely, but that's defensive programming. Q_legend_ac3.mw

[edit] Yet another reasonable way to construct the caption, and to guard names against further evaluation, involves using InertForm:-Display. This too pretty-prints the sigma character as the Greek letter, etc. This might even be my preferred way, over the 1st and 2nd ways. Q_legend_ac4.mw

This duplicates each frame three times (to slow down the exported .gif file).

It reduces the line thickness as n increases.

Download graph_anim01.mw

Or, with labelled vertices, up to n=50, with just two repetitions per frame, and with lines getting thinner slightly more slowly.

Download graph_anim02.mw
 

Here's an example for the legend, and making the axes' labels and tickmark values bold.
 

Q1_3_ac.mw

I look forward to reading about what other bits you might have forgotten to mention.

The title option seems to have been broken in Maple 2023. It works ok in Maple 2022.2 and earlier.

I will submit a bug report.

The problem seems to be simply that a new outer Table (hidden borders on those inside it) was put around the assembly. And the title is still being put on the a Table that is just inside that. But the GUI only shows Table caption & title on the outermost of a collected of nested Tables. So the title's being attached to the wrong Table now, and not shown in consequence.

Here are two workarounds:

1) Use Explore's overview option instead (adjusting the padding, for the width),

Explore(plot(a*sin(b*t),t=0..10),
   parameters=[[a=1..20], [b=1..20] ],
  initialvalues=[a=6,b=5],placement='right',width=300,
  'overview'=cat("\n"," "$32,"My Explore"));

2) Utilize a (re-usable) procedure instead, which constructs the xml, fixes it up, and embeds it,

NExplore := proc(U::uneval,{title::string:=""}) local temp;
 temp:=XMLTools:-FromString(Explore(U,_rest,insert=false,returnxml=true));
 DocumentTools:-InsertContent(subsop(1=_XML_Table("captionalignment"="1",
   "title"=title,"captionposition"="0","drawtitle"="true",
   remove(type,[op([1,..],temp)],
          identical("captionalignment","title",
                    "captionposition","drawtitle")=anything)[]),temp));
 return NULL; end proc:

NExplore(plot(a*sin(b*t),t=0..10),
         parameters=[[a=1..20], [b=1..20]],
         initialvalues=[a=6,b=5], placement='right',
         width=300, title="My Explore");

explore_title_ex07.mw

Your Question's title asks, "why Explore gives error...", but it did not give an error. It gave 2 Warnings  and the exploration appears to run ok.

Internally, Explore makes a couple of evaluations of the expression, using right & left parameter end-points, to try and gauge what the maximal viewing range might be. It's only substituting the Slider value, not the TextArea value, when doing that.

If you don't want to be disable warnings you can avoid those messages by preventing the adaptive viewing mode (in which it tries to retain the largest `view` range found for any parameter values).

For example,

Explore(plot(a*sin(b*t),t=0..10),
   parameters=[              
        [a=1..20],
        [b,'controller' = 'textarea','label'="b" ]
        ],
  adaptview=false,
  initialvalues=[a=6,b=5],placement='right',width=300);

Notice how the vertical view changes dramatically as parameter `a` changes? It's somewhat awkward. That's what the (new in the past couple of releases) `adaptview=true` option is for, to get a more stable view experience.

Of course, you can force a widest view with,

Explore(plot(a*sin(b*t),t=0..10,view=-20..20),
   parameters=[              
        [a=1..20],
        [b,'controller' = 'textarea','label'="b" ]
        ],
  adaptview=false,
  initialvalues=[a=6,b=5],placement='right',width=300);

Yet another way to get rid of those two warning messages, while keeping the adaptiveview=true default, is to simply make it produce an empty plot (silently) when the parameter is non-numeric.

F := proc(ap,bp)
  if not ( ap::numeric and bp::numeric ) then
    return plot(axes=none); end if;
  plot(ap*sin(bp*t),t=0..10);
end proc:

Explore(F(a,b),
   parameters=[              
        [a=1..20],
        [b,'controller' = 'textarea','label'="b" ]
        ],
  initialvalues=[a=6,b=5],placement='right',width=300);

explore_slider_textarea_ex06.mw

As I explained in my Answer your Question yesterday, the slider controllers that Explore inserts are all Embedded Components Sliders. In fact, the very first URL link in my Answer yesterday is the very same link that you've cited here.

Consider this example, where the Slider snaps to only multiples of 10.

Explore( plot(a*sin(x), x=-3*Pi..3*Pi, gridlines),
         parameters=[ [a=0 .. 1000, majorticks=500,
                       minorticks=10, snaptoticks=true] ],
         initialvalues=[a=1000], width=500, placement=right );

nb. There is a minimal granularity that the GUI itself will allow, in terms of how it perceives small movements of a slider control. Ie, you can't make the slider be manually moved any arbitrarily small portion of the whole.

Also, the question about arbitrary values, entered manually, has come up before. (Prof. R.Lopez once asked me about that.) The code might be revised so that the (current, separate) Label component which shows the running Slider value is instead a TextArea component and that it serve double duty as both output (running value) and input (manual).

[edit] While they don't update each other, a Slider and a separate TextArea component can both be used in the same exploration to set the value of a common name in the "expression" (here, a function call F(a,aa) ).

F := module() local aval,ModuleApply;
  ModuleApply:=proc(a,aa) local use_a;
    if nargs=2 and aa::numeric and aval<>aa then
      aval:=aa; use_a:=aa;
    else use_a:=a;
    end if;
    plots:-display(plots:-textplot([5,30,typeset("a=",use_a)],color=blue),
                   plot(use_a*sin(x),x=-3*Pi..3*Pi,gridlines));
  end proc:
end module:

Explore(F(a,aa),
  parameters=[[a=0 .. 50, majorticks=10],
              [aa, controller=textarea, label="", width=3]],
  initialvalues=[a=50,aa=a],
  width=500, placement=right);

They each update the plotted expression (but not each other, as entry components).

explore_slider_ex05.mw

If you are using full-screen for the Maple GUI then you might try placement=right (or left) for the Sliders (optionally aligning them horizontally or vertically as you want). You can actually mix&match the placements. That might help keep your full plot visible while sliding. Of course for side-placementt you would not utilize your width=300 choice (which I personally feel is not going to be good for overall look&feel, in almost any event...).

I am not aware of a way to set the font family or size for the values markers shown on Sliders, a kind of Embedded Component (EC).

It can be mentioned that Table ECs don't have the fancy grid/etc layout or as many alignment choices that Maplets tables/cells do, and so fine placement within the assembly is cobbled together with a few invisible subtables. (It's a bit like trying to build a palace out of mud and sticks.) If I recall correctly the internal cell padding is already set to 0 for the internal layout of the Explore Tables. But you're right, it does look cludgy.

You can make the Sliders a bit longer, which can visually relieve a little bit of the awkwardness wrt the value markers.  Their length is constrained a bit by the internal layout (so they're limited by the overall width), but here's an example of the syntax: Explore_slider_width_ex01.mw

I'll also mention that the fonts in Embedded Components are quite different(!!) according to platform, including in terms of size as well as look/feel. Here's a Linux ubuntu screenshot, in which the Slider tickmark values look remarkably different than in the OP's screenshot (noticeably smaller, bolder, different font family, ie. noticeably different in all the key ways that fonts can be different). I don't know whether the differences are mostly a Java thing, a Maple GUI thing, or an OS thing.

I suspect that some of that vertical whitespace might be alleviated if the implementation were changed so that the hidden internal Table EC used for animation controls/etc were altogether not present when those controls are not used/shown. In EC, even an empty sub-Table with zero-padding adds bulk and white-space (again, unlike what can be done with Maplets, iirc). I could log a bug ticket for that.

How about a Matrix, using,

   <eval~(N, results) | eval~(tbo, results) | eval~(two, results)>

or,

   Matrix(map[2](eval, [N, tbo, two], convert(results, list)))

PrimesQuestion_ac.mw

Naturally, you could make a DataFrame from that Matrix, etc.