@PhearunSeng 

Tom's worksheet has eqs as a list.

Your image shows that you rewrote that so that eqs is a Matrix.

You claimed that your image shows you running Tom's worksheet. But your image shows that the command's that you are using are different from his.

Download Tom's attachment. Open that .mw file, and run it. Don't paste in something else.

Also, it makes little sense to have the equations be some scalars expressions added to Vectors. Be more careful about your syntax.

@PhearunSeng You are still calling restart after you define eqs.

You wrote, "Is there a way to print points that have..." (italics mine). But then you talk of "graphs".

So, are you trying to plot the point data, or print it like output, or...?

And you want hover-over information to popup, for different points?

(You description of how you're reading in the data, and the slowness of that, seems to be a quite different query. But it's difficult to offer best advice when you don't show code-to-reproduce.)

@Carl Love The OP sent me a link to another paper.

https://www.sciencedirect.com/science/article/pii/S0377042708003555

He said, "I used equation 14, Method 1 , and took values for alpha and gamma = 1".

And he sent me a worksheet that had an implementation of the formulas. As a rough test of that I plotted its "escape-time" using densityplot.

Download Wei_method_ac2.mw

I haven't time to figure out why my earlier EscapeTime template runs away on it...

[note: in my original answer here I preprocessed the Newton's method (compounded) formula and hit its Im and Re components with evalc and simplify. I happened to do the same for my King's method implementation in that same Answer. But I did not do that in my followup implementation of the "Haf1" (Hafiz paper) 4th order method. There I left the Im and Re calls alone, since the simplify/evalc time is large, it's of little merit, and these days evalhf and the Compiler can handle those better.]

@Dkunb Here are a couple of ways to get that first image -- the contour N(beta,alpha)=0.

I used Axel's idea of integrating only out to 6 instead of infinity, and using oscillating method _d01akc instead of semi-infinite method _d01amc.

I used a list of values by rootfinding (in two ways), instead of contourplot or implicitplot.

I also show a simple (simplistic) idea of using Interpolation and using a coarser list of points. But the final curve appears quite smooth.

I also tried Grid:-Seq, and you might try tweaking that.

I may not have any more spare time for looking at this interesting problem. But this might illustrate a few alternate approaches.

Download Negativity_v1_acU0.mw

Please don't create duplicate Question threads of your followup (below) about an 8th order method.

(I hope to find time to look at your formulation. But the fact that nobody's yet done so here is not justification to submit duplicates.)

You could try renaming your .mw worksheet with a file-name that doesn't include special characters (`+`, "(), etc). Try it with only alpha-numeric characters, underscores, and a period.

Some special characters can confuse the backend of this forum, preventing downloads.

@Carl Love Does your Windows Task Manager show a similar CPU load if the option engine=triade is used instead?

@MaPal93 It is counter-productive and unnecessarily difficult for the readership if a derivative followup query is separated from its parent, since that obscures connections amongst the information and details given by the original poster as well as the responders.

@Carl Love Despite the wording of the error message I don't see that the sign command is necessarily the problem here.

I'd guess that signum is being used at some internal juncture, and the calling routine is not properly prepared to deal with its result...

@MaPal93 Please do not put that followup in a (duplicate) separate Question thread.

How would you feel about taking limits instead of using eval? Or do you want to know precisely how dsolve's internals are handling it differently?

note: in Maple 2017.3 (and 2022.1) a single call to limit can do the same.

Download SomethingWrong_ac.mw

Shout if you have reservations.

@jalal Here is my suggestion for 2D math in the "headers" together with Carl's suggestion for additional substitution of complex values.

DocumentTools:-Tabulate(subsindets[flat](
                          Matrix([<["",F(x)[]]>,
                                  ((Vector@[u->u,F[]])~(C))[]]),
                          {undefined,And(complexcons,Not(realcons))},
                          ()->dne),
                        width=50,
                        fillcolor=((T,i,jj)->`if`(i=1 or jj=1,
                                                  [210,230,255],
                                                  [255,255,235]))):

You could put that into a reusable procedure, if you'd like, which could be hidden in a document's Startup code or a collapsed Code-Edit-Region. Such a procedure could simply take F and C as its arguments.

@jalal You could instead use a Matrix for the whole thing, with data and headers together, to get the header expressions to render in pretty-printed 2-D math.

DocumentTools:-Tabulate(subs(undefined=dne,
                             Matrix([<["",F(x)[]]>,
                                     ((Vector@[u->u,F[]])~(C))[]])),
                        width=50,
                        fillcolor=((T,i,jj)->`if`(i=1 or jj=1,
                                                  [210,230,255],
                                                  [255,255,235]))):

That summation index variable n1 is not entirely like the variable n. That name n1 represents a bound variable, since your sum call denotes that it would only take integer values between 1 and n-1.

There's not much significant difference between using the name n1 instead of the name i, or what have you. For example, these next two are conceptually similar:

    sum(f(i), i = 1 .. n-1)
    sum(f(n1), n1 = 1 .. n-1)

The end result of both of those would usually be the same; the results depend on (any value of) n in the upper end-point of the index, but the results don't depend on which choice of name is used for the summation index.

Maple knows a bit of that, which can be useful:

depends(sum(f(n1),n1=1..n-1), n);

         true

depends(sum(f(n1),n1=1..n-1), n1);

         false

depends(sum(f(i),i=1..n-1), i);

         false

expr := sum(f(i),i=1..n-1):

indets(expr, And(name,
                 satisfies(nm->depends(expr,nm))));

          {n}