@Markiyan Hirnyk The question of low a degree a polynomial may approximate (to within a specific tolerance) the given expression on 0..1 is interesting theoretically, because of some potential numerical difficulties at both end-points.

In practice so-called range reduction (which is really domain reduction) could be used. And this allows the target error of 0.01 to be met by using only the restricted domain or 1/2..1 while computing the polynomial, since the mathematical function has a symmetry of reflection about the point (1/2,Pi/4) even if it lacks symmetry by reflection across a line.

If we take p as,

p:=1.135971747717227*x+.1950071341939759+.4815612713662410*(4*x-3)^3
-2.439038982375010*(4*x-3)^4-12.66183100870810*(4*x-3)^5
+41.62555613174249*(4*x-3)^6+164.1652491121847*(4*x-3)^7
+975.5300610456691*(4*x-3)^22+1785.055305607627*(4*x-3)^23
+11358.38836456872*(4*x-3)^18+23013.15164101551*(4*x-3)^19
+26106.22796515134*(4*x-3)^15-14347.77165088372*(4*x-3)^16
-30967.64393191083*(4*x-3)^17+.1043967698939514*(4*x-3)^2
-359.5777009952230*(4*x-3)^8-1176.044314414133*(4*x-3)^9
+1804.767818275263*(4*x-3)^10+5127.986643910732*(4*x-3)^11
-5625.866345976549*(4*x-3)^12-14311.88358476918*(4*x-3)^13
+11225.66738216834*(4*x-3)^14-5070.302621042330*(4*x-3)^20
-9728.730684483163*(4*x-3)^21:

then I believe that arcsin(sqrt(x)) may be approximated to within 0.01 over the doman 0..1 by using the translation evalf((Pi/2)-eval(p,x=1-x),16) for x in 0..1/2.

With Maple 17,

restart:
with(numapprox):
e:=proc(x) Digits:=100; arcsin(sqrt(x)); end proc:
c:=chebpade(e,1/2..1,[23,0]):
Digits:=16:
p:=sort(eval(c(x),T=orthopoly[T]));
sol:=piecewise(x>=1/2,p,evalf(Pi/2)-eval(p,x=1-x)):

Finding the minimal degree polynomial in the Chebyshev basis that meets the target tolerance for even the restricted domain seems tricky if using `numapprox`, and that might be due in part to some hard-coded constants within the `evalf/int/ccquad` procedure. I wonder whether some integrations could be done with more manual control.

@Preben Alsholm Does this get an error better than 0.016? Is it about 0.01543?

.785398163397445*T(0, 2*x-1)+.638238282327978*T(1, 2*x-1)
+0.723739716042111e-1*T(3, 2*x-1)+0.271442813438863e-1*T(5, 2*x-1)
+0.147364292749009e-1*T(7, 2*x-1)+0.969627362219072e-2*T(9, 2*x-1)
+0.722513270043944e-2*T(11, 2*x-1)+0.590232940948517e-2*T(13, 2*x-1)
+0.519621737331440e-2*T(15, 2*x-1):

Or how about,

.78539816339744830960*T(0, 2*x-1)+.63823828232797760017*T(1, 2*x-1)
+0.72373971604211358200e-1*T(3, 2*x-1)+0.27144281343886350513e-1*T(5, 2*x-1)
+0.14736429274900909502e-1*T(7, 2*x-1)+0.96962736221907198717e-2*T(9, 2*x-1)
+0.72251327004394449383e-2*T(11, 2*x-1)+0.59023294094851786867e-2*T(13, 2*x-1):

which might do better than 0.015?

@Carl Love Ok, it seems that in Maple 17 the hue proc is getting passed a hardware float value (for the right end-point of the input range 0..1) which is slightly larger than 1.0, when the hue proc is run under evalhf (the default). This results in a negative value of very small magnitude being produced, and that seems to trigger a rescaling of all the computed hue data to fit the range 0..1.

So, another kludge to workaround the problem, for this particular example, might be to instead use something like,

   (x,y)-> abs(1-x)^Gamma/3

or

   (x,y)-> (1-min(1.0,x))^Gamma/3

as the hue proc.

I suppose that the input values for x are being produced by some formula involing the end points and the x-grid size, and that this is resulting in a roundoff problem such that the computed last value is not the same double-precision float as the end-point might be.

So, what changed between releases was the default grid size, which went from [25,25] to [49,49]. Using 40 for the x-component of the `grid` option reproduces the problem in Maple 14, 15, etc.

One can compare these two,

plot3d(0, 0..1, 0..1,
       color=[proc(x,y) eval(printf("%y\n",x)); (1-x)^1.0/3; end proc,
              (x,y)-> 1, (x,y)-> 1,
              colortype= HSV], grid=[39,2]);

plot3d(0, 0..1, 0..1,
       color=[proc(x,y) eval(printf("%y\n",x)); (1-x)^1.0/3; end proc,
              (x,y)-> 1, (x,y)-> 1,
              colortype= HSV], grid=[40,2]);

@Carl Love The problem seems to have been introduced between Maple 15.01 and 16.02. (I don't have 16.00 or 16.01 on hand to double check, right now.)

I suspect something to do with the `color` option procs running under evalhf. (Perhaps an exception not handled the same? I haven't dug in yet.) Making the hue proc be un-evalhf'able seems to get the expected result. Ie, since lists are not supported in evalhf,

   proc(x,y) []; (1-x)^Gamma/3 end proc

Perhaps another hint: grid=[39,40] does ok with the evalhf'able hue proc, but grid=[40,40] does not.

What exactly do you mean by, "math clickable popup"?

acer

How about just scaling the input and using custom tick marks?

acer

You added other suggestions to a list entitled 16+2, a year ago.

acer

@nicholasfbennett Yes, my answer was just to get your original design to work. I made the comment about having a checkbox instead of a button because I was guessing that what you really wanted was this other behaviour.

Here is a revised Document, with that check box idea.

Parabolascb.mw

Note that the action codee behind all 4 components (3 sliders and the checkbox) is exactly the same. You could make future editing easier if you defined a short procedure in the StartUp code of the Document which made this action. Then you could put just a single call to that procedure as the action for each component. This would centralize your code.

@Markiyan Hirnyk I think that the key issue is how can we get numerical roots out of a general RootOf. Or, perhaps more the point, how can we request that? The `evalf/RootOf` routine and its interoperation with `allvalues` is complicated. If there are infinitely many solutions then what might help is a better or new way to specify the request, eg. some way to request all roots within a finite range, or the ith root moving left/right from a particular starting points, etc. I think that your question raises some very important points about how Maple's functionality could be improved.

RootOf's can be utilized for some purposes other than this kind of numerical requests, so I don't quite see why difficulties with computing them should in itself bring into question the purpose of SolveTools[Engine].

How would you like the Sliders laid out?

As if you had repeatedly hit the Slider entry from the EmbeddedComponents palette? Ie, left to right in an input line?

Or, perhaps, laid out in a Table?

What should trigger the insertion? Some Button press, which reads the content of the TextArea component? Or a call of a procedure (of your authoring)?

acer

The short answer is... yes.

It's the weekend, sorry, and I won't be able to write a short procedure for it until this evening or tomorrow evening.

acer

@fluff That should be "end proc" not "ens proc".

And "randomize()" rather than "rendomize()" which does nothing.

And your proc's parameter name is "switch" but in the code you use "switches".

@Syeda The equations do not appear to have a solution for x when z is not a value above 1.249642 or so. You have now used z=1, for which there may be no root. When fsolve returns unevaluated it means that it has not found what it considers to be a root.

@Syeda Can you not just use fsolve?

Eg,

fsolve(eval(rhs(eq1)-rhs(eq2),z=1.2497),x);

                        0.0008311824617

@Carl Love Thanks, Carl, I had misread the exponents. But it only affects the result a small amount, and the the minimal z for which there is a root is still greater than 1 (or 0.5044).

I have edited my answer accordingly.