@Markiyan Hirnyk If one wants to execute the 2D Math Input containing the doubly underscored 4 then it should be an atomic identifier (because otherwise the 2D parser has no uderstanding of it, as syntax). Note that Maple doesn't do so much with this computationally, since it's interpreted just as a name and not as something mathematically related to the number four.

But if the 2D Input is only used as typeset math without execution (eg. inlined as math within some text paragraph) then it is not necessary to convert to atomic identifier, I believe.

@toandhsp I was windering whether Mathematica produces the same kind of result as this which is what my link above (to WolframAlpha) points to. That is, five results similar to,

    8 n!=1 and x = (-2 sqrt(n-4 n^2)+4 n-1)/(8 n-1) and n element Z

Or does it recognize how substitution using these results might simplify to a smaller set of solutions (because of periodicity).

How might this be adjusted or further manipulated (evalc?) so as to get these purely real solutions? I mean, something neater than just crudely plugging in some integers for the two _Z?? in the above solution.

   1/2-(1/10)*5^(1/2),  1/2+(1/10)*5^(1/2),  1,  1/2-(1/2)*5^(1/2),  1/2+(1/2)*5^(1/2)

@toandhsp Did you use Mathematica? I got just a rather ugly and unsimplified result from www.wolframalpha.com .

@Joe Riel I got all roots found by `asolve` if Digits=30 in Maple 17.02 on 64bit MS-Win. But it took about 5 secs.

One problem with repeatedly calling `fsolve` with its `avoid` option is that fsolve keeps trying various (random) initial points, hoping for convergence. The previously found roots don't help it with trying to find initial points in the basins of attraction of the remaining as-yet-not-found roots. As more and more of the roots are found any randomly chosen initial point will more and more likely converge to a previously found root rather than the desired as-yet-unfound remaining roots. In other words, such an approach can be slow if it does not make a systematic survey of the domain. The problem gets worse with problems with more and more possible solutions. That's one reason why it is slow.

Why fsolve doesn't find the roots between 60 and 100 unless Digits is set higher than default is another question, perhaps (a guess) related to how fsolve does not allow separate control of both working precision and requested accuracy (having both tied to Digits). Of course, having to use higher working precision also slows it down.

@rab285 This site seems to be having problems with attachments at present.

Here is the code from the intended attachment "p3interp.mw" that may be broken in the followup Comment above.

It uses a plaintext comma-separated-value file "y0.csv" (which could be saved from you original, in Excel say). That file should have 383 rows, since I removed the first row which was just a header. This is used to produce `M` a 383-by-3 Matrix.

restart:
M:=ImportMatrix("y0.csv",source=csv,datatype=float[8]):
with(plots):
#
# Smoothing approach (slow. points need't lie right on surface)
#
P1:=Statistics:-ScatterPlot3D(M,lowess=true,bandwidth=0.15,
                              fitorder=2,showpoints=false):
#
# Approach of 1D interpolation to fill in gaps.
#          (may extrapolate poorly, ie. see plot at point (1.1)
#
A:=Matrix(21,21,datatype=float[8]):
s:=1: T:='T': T[1]:=s:
for i from 2 to 21 do
  ini:=M[s,1];
  for j from s+1 to op([1,1],M) do
    if M[j,1] <> M[j-1,1] then
      T[i]:=j;
      s:=j;
      j := op([1,1],M);
      next;
    end if;
  end do;
end do:
T[i]:=op([1,1],M)+1:
for k from 1 to 21 do
  c:=Matrix([Vector(21,(k-1)*0.05),
        Vector(21,i->(i-1)*0.05),
        CurveFitting:-ArrayInterpolation(M[T[k]..T[k+1]-1,2..3],
                                         Vector(21,i->(i-1)*0.05))],
        datatype=float[8]);
  A[k,..]:=c[..,3];
end do:
P2:=surfdata(A,0..1,0..1,gridsize=[42,42]):
#
# This is the uninterpolated surface (with gaps)
#
B:=Matrix(1..21,1..21,Float(undefined),datatype=float[8]):
for i from 1 to op([1,1],M) do
  B[round(M[i,1]/0.05)+1,round(M[i,2]/0.05)+1]:=M[i,3];
end do:
P3:=surfdata(B,0..1,0..1):
#
# Now plot both, with an without the points overlaid
#
Ppoints:=Statistics:-ScatterPlot3D(M,color=red):
display(Array([[ display(Ppoints,P1), P1 ],
               [ display(Ppoints,P2), P2 ],
               [ display(Ppoints,P3), P3 ] ]),
        view=min(M[..,3])..max(M[..,3]),
        orientation=[45,45,0]);

@rab285 Which Maple version are you using?

The following (zipped) .csv data file and worksheet run ok for me in Maple 17.02.

y0.zip

p3interp.mw

I implemented the idea I mentioned about doing 1-D interpolation, repeatedly, to fill in gaps. That probably uses size and dimensions particular to your data set, ie. you'd likely need to make it more careful if attempting to use it on another set of data. I also added another method (surfdata, with gaps) since the data points lie on a regular grid (even if they do not fill it).

I suppose that yet another attempt (which I have not done) might be to rip out the rtable from the surface portion of the result from ScatterPlot3D and replace the given data points (by walking through M, similar to what was done in the 3rd approach in this attached worksheet). Then all the supplied data points would lie directly on the drawn surface, the gaps would be filled, and it might extrapolate in problematic corners better than happens with the 2nd interpolatory approach of this attachment.

@Carl Love I have no initialization file in use. I was using Maple 17.02, and get the same results using both the 32bit and the 64bit version, run on Windows 7 Pro.

I also get the same results running each of Maple 11.02, 12.02, 13.01, 14.01, 15.01, and 16.02 in each of 32bit or 64bit Maple as available, all under Windows 7 in the Standard GUI. And I get the same results also from each of 10.03, 11.02, 12.02, 13.01, 14.01, 15.01, 16.02, and 17.02 in both 32bit and 64bit commandline Maple running on ubuntu 10.04. In all cases no initialization file was in use.

Also, the results are (to me) expected. Pi is approximated to floating-point by `evalf` via lookup up to 10000 digits. (Mma has 1000000 digits hard-code, if I recall...)

For example,

restart:
anames();
                       debugger/no_output

kernelopts(version);
    Maple 17.02, X86 64 WINDOWS, Sep 5 2013, Build ID 872941

UseHardwareFloats;
                            deduced

printlevel:= 1000:

evalf(3/Pi, 1);
{--> enter evalf/constant/Pi, args = 
                               3.
<-- exit evalf/constant/Pi (now at top level) = 3.}
                              0.9

Regardless of how it is obtained, for the first example `evalf` will evaluate (and round) Pi to just 1 decimal digit, obtaining 3. as that part of the intermediate computation. It doesn't matter whether that is obtained via lookup or via evalhf or external call to libhf or whatever.

Please pardon me, but I am going to repeat the aspects that I consider key to Christopher2222's question. What matters is that `evalf` will approximate the literal `3` in the input to one digit (result: 3.), then invert that and again round to one digit (result 0.3), then multiply that by the one digit approximation of Pi (final result 0.9).

@nm I have no problem with your approach; it is simple and understandable.

For fun, here are another pair (the second of which is similar to your own).

restart:
eq := (x+y)^2 + 1/(x + y):
G := ee -> `if`(ee::`+`,map(`*`,ee,denom(ee))/denom(ee),ee):
G(eq);

                                 3    
                          (x + y)  + 1
                          ------------
                             x + y    

restart:
eq := (x+y)^2 + 1/(x + y):
thaw(normal(subs(x+y=freeze(x+y),eq)));

                                 3    
                          (x + y)  + 1
                          ------------
                             x + y    

Being able to distribute a multiplication across a sum, without expanding, comes up now and then.

Are you using 17.02? It has some fixes for issues with international keyboards. See here.

acer

The key thing here is that evalf[d](...) or evalf(...,d) is not a request for `d` digits of accuracy in general. Rather, this syntax is a request to use a certain working precision, and intermediate values in the computation will get rounded at that working precision.

@Carl Love It will call `evalf/constant/Pi`, which rounds a precomputed result in the body of that procedure since Digits<51. (And _bigPi is another precomputed result, for slightly larger values of Digits, and then there is also `evalf/constant/bigPi` with 10000 digits).

> restart:         
> printlevel:=1000:
> evalf(3/Pi,1);   
{--> enter evalf/constant/Pi, args = 
                                      3.

<-- exit evalf/constant/Pi (now at top level) = 3.}
                                      0.9

And so now we have a hint to try,

restart:
showstat(`evalf/constant/Pi`);

@Alejandro Jakubi Hmm, I saw symbols displayed for pretty much all (or maybe all) of the values in 380..450, so the fact that all but five of those are excluded from the UnicodeToEntity list seems (to me) to indicate that list is not all related to font availability.

But I still wonder whether no symbol displayed for value 9813 is a font issue.

@Alejandro Jakubi I don't understand how that relates. I see only five results from `UnicodeToEntity` returned list, for the (lhs) number between 380 and 450, say.

kernelopts(opaquemodules=false):
T:=table(Typesetting:-UnicodeToEntity):
for i from 380 to 450 do
  try
  if assigned(T[i]) then print(i,T[i],cat(`&#`,i,`;`)); end if;
  catch:
  end try;
end do;

But I see the Standard GUI of Maple 17.02 running on Windows 7 Pro as being able to display symbols for many more numbers from that range. (I'm not sure that I can get them inlined in this comment, however.) All of the following print in my Maple 17.02 Standard GUI, as special symbols.

seq([i,cat(`&#`,i,`;`)],i=380..450);

But if I attempt to print for all unicode values then quite a few symbols do not get shown as anything except an empty box. To me this suggests a font issue.

It doesn't appear that the unicode entity need be recognized by Typesetting as an "Entity", in order for it to just print in the Std GUI.

@Alejandro Jakubi When I mentioned forming valid .mw I was thinking more of the the XML structure and the need for an up-to-date validating schema (more than, say, encoding of dotm) for the modern .mw worksheet.

@Alejandro Jakubi Turning expressions into the format stored in .mw can involve base64 encoding of "dotm" (aka .m format, like produced by sprintf with the %m descriptor), and sometimes Typesetting as well. Programmatically forming valid .mw files, to contain such encodings, is additional work.

It might be easier to just savelib results to a private .mla archive or save to a .m file, and then access them manually from there by making calls to evaluate or print them in a Standard GUI session.