@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}

@David Mazziotti Maple's GUI renders a certain kind of markup for its 2D Math pretty-printing, a.k.a. typesetting. There is a strong resemblance to MathML. The Maple specifics are not user-documented.

The "mo" stands for math-operator, and "mi" for math-identifier. (See here, for similar details.)

It can come in two forms. One construction consists of specially formed names, and the other of special function calls using exports of the Typesetting module. For example,

Download typemkex.mw

It can be very handy to be able to programmatically construct things which print in special ways (including the case where there is no usual Maple structure that would normally print in that manner).

Quite often one can infer how these forms work by creating some 2D Input, then using the right-click context-menu item,
   2-D Math -> Convert To -> Atomic Variable
and then executing, and then calling lprint on the result to show its structure.

See also the results of,
   exports(Typesetting);
which are mostly undocumented.

@MalakMMK I don't think that you coded the formula from the Hafiz paper correctly; at least some brackets are missing.

For example you had, as the first step,
   u - (2*F(u)/3*dF(u))
but the paper shows the denominator of that as all of 3*dF(u), hence,
   u - 2*F(u)/(3*dF(u))
Also, you had,
   v - F(u)*W/dF(u)+dF(v)
but the paper show the denominator of that as all of dF(u)+dF(v), hence,
   v - F(u)*W/(dF(u)+dF(v))

The paper defines "eta = f'(x)/f'(y) without the index n", which seems a little confusing. Below I used eta := dF(u)/dF(v) and get apparent success. Please edit and explain, if you think that's wrong.

[edit: Below I used a value of 20 for the maximal iteration cutoff, ie the third argument passed to H. So for a sensible comparison with the earlier Newton's and King's methods you might want to re-run those with that same value.]

Haf_Newton_ac1.mw

@Sradharam In the original example pde was assigned an equation, ie, something=0. That's why I used lhs(pde).

In your followup worksheet pde is no longer assigned as an equation. So the lhs call is no longer needed.

How_to_collects_the_coefficents_ac.mw

Please stop putting additional details and followup queries for this in new and separate Question threads.

Instead, you can add your additional details and followup queries for this here.

Please put your followup queries and additional details or attempts for this problem in a Reply/Comment in this same Question thread, instead of spawning a separate and new Question thread.

@Dkunb What is the significance of the curve separating the red and gray areas in the plot on the left? Is it supposed to denote a contour (level curve) of value of N(beta,alpha)?

If that is so then what is the common value that N attains along that contour? If that is not so then what does that curve represent?

ps. I'm trying to figure out what's going on with the alpha range, ie. any discrepency.

[edit: As alpha and beta get large (but especially as alpha gets large) the surface becomes relatively much flatter, which might confuse some commands or approaches for attaining a nice, smooth contour near N(beta,alpha)=0. It's possible that implicitplot might handle that better...]

@ijuptilk You have now stated that you expect,

  ((2*I)^2)/0.002;

to return,

   -2000.000000 * I

instead of,

   -2000.000000

Why do you expect that?

The original .mw worksheet attachment has been removed from this Question. Here is an earlier copy.

Case3_Ijuptilk_Contourplot_pmin_290822_orig.mw

It is very poor etiquette on the part of whoever removed the original.

@Dkunb You should explain -- properly, clearly, and adequately -- what the coloring and lines represent on those plots.

@Dkunb 

The internal plotting routines will attempt floating-point evaluation, using evalf (or evalhf) as appropriate.

That's how the plot can still be made, even if N is returning only inert Int calls from L.

You are free to call evalf(N(...)) to get any individual/scalar float result, if you prefer. Or you could add an evalf call in the L procedure itself. Of you could call evalf(L(...)) from within N. It's your choice.

@ijuptilk The code inside doCalc is not particulalrly good. It is not fast, for any single x-y input point. So the 5x5 grid is not very fast, and takes a few minutes on my machine.

And now you talk of an 81x81 grid. That is 260 times as many x-y points as a 5x5 grid. Naturally, using the same approach that would be much slower.

You had posted versions of some of it in several older postings, eg. here. I had looked at some of those and made a few suggestions which you appear since to have mostly not taken up. Eg. I suggested parallelization using the Grid package as an alternative to using plot3d to construct the 2-D data.

Parallelization is possible, but it won't give you an enormous speedup. If you raise the grid to 81x18 and make it 250 times slower then a 3-8 times speedup from parallelization won't help much. It's also a back-to-front approach to improving efficiency. You should focus first on the timing of a single call to doCalc, and only after that is good look at parallelization.

You also have a persistent habit of not explaining what exactly it is that you are trying to compute in adequate detail. Without adequate detail it is very difficult to make suggestions that pertain to anything but small aspects of the existing approach. I suspect that large portions of your approach could be replaced, but haven't received enough explanation to do so.

There is also some detail on the root-finding portion, here. And I also deleted my responses from at least one other thread (in which some details appeared), in frustration over the lack of complete detail, the way you kept changing and adding details, your omission in several prior Questions (until after people had put effort into your problem) of the important detail that you are using a very old Maple version, and your reluctance to utilize some suggested improvements.

I likely won't be able to spend more time on improving it.

@ijuptilk I ran the following in Maple 18.02.

I cast the data to a Matrix, before passing to listcontplot.

I used method=QR in the call to LinearSolve below. I don't know enough about what you're computing to pass judgement on whether that a valid approach. What do you think ought to happen in the case that your linear system is, say, underdetermined?

You still haven't bothered to upload an attachment with a worksheet that contains any corrections to the x-axis (range) that you mentioned in a Reply comment on your own Question.

Download Case3_Ijuptilk_Contourplot_pmin_290822_acc.mw