Is the pattern that `max` and `sort` are still using evalb for relation testing? Maybe it's time to consider promoting `is` to a new job.

For `sort` you can supply your own comparator (as I know you're aware) but there's still an argument to made for having it be more automatic. For `max` it's tougher to do it efficiently.

The generated 3D globe plot consists of POLYGONS with many (approx. 30-40k) elements, CURVES for the borders, and a MESH for the sphere/ocean. Those main substructires can all be manipulated separately, even obtaining a few customizations not easy (or possible) directly from the original command.

globe_fun.zip

@Preben Alsholm 

I'm not sure I understand why evalf/Int isn't succeeding (and quickly) by splitting the integral at x=1 the point of discontinuity in the given range x=0..5.

restart;
g:=sqrt(1/(1-x^2)):
CodeTools:-Usage(evalf(int(g, x = 0 .. 5)));
memory used=52.37MiB, alloc change=34.00MiB, cpu time=502.00ms, real time=502.00ms, gc time=39.53ms
                  1.570796327 + 2.292431670 I
restart;
g:=sqrt(1/(1-x^2)):
CodeTools:-Usage(evalf(IntegrationTools:-Split(Int(g,x=0..5),
                          select(x->x>=0 and x<=5,[op(discont(g,x))]))));
memory used=20.81MiB, alloc change=67.01MiB, cpu time=216.00ms, real time=216.00ms, gc time=15.67ms
                  1.570796327 + 2.292431670 I
restart;
g:=sqrt(1/(1-x^2)):
CodeTools:-Usage(evalf(Int(Re(g), x = 0 .. 5))
                 +evalf(Int(Im(g), x = 0 .. 5))*I);
memory used=6.15MiB, alloc change=33.00MiB, cpu time=67.00ms, real time=66.00ms, gc time=5.67ms
                  1.570796327 + 2.292431670 I

Everything has the same sign, approaching the discontinuity at x=1 from both sides.

plot([Re,Im](g),x=0..5,view=0..5,thickness=4,filled,color=[green,red]);

@Samir Khan Yes. I was supposing that the country data or its processing might confused about that disputed region. (I wrote lake in a dry attempt at humour)

@Samir Khan Is that a large lake along the border of Western Sahara and Mauritania?!

@assma My first suggestion (if diff can handle what you call the "known functions" but which you resist showing us in full) is,

w2:=unapply(diff(v2(x,y),x)-diff(u2(x,y),y), [x,y]):

For some strange reason you changed that to the following, which I did not recommend at all,

w2:=proc(x, y) options operator, arrow; unapply(diff(v2(x, y), x)-(diff(u2(x, y), y))) end proc;

@assma No, I did not suggest putting a call to unapply within the body of w2. Yes, what you've done does solve your original runtime error, but it is as bad for performance as calling diff within w2. That's exactly what I suggested not to do.

@itsme The over-conservativeness lies in LinearAlgebra:-Eigenvalues, but I recall that it's been mosty like that since Maple 6 (yr. 2000) when it was introduced. On the one hand mixed floats and symbolics has always been dodgy (and not just in Maple). On the other hand there's always been a struggle between pragmatism ("just give me an answer") and restricting functionality to clearly-defined domains for which correct behavior is understood (in theory).

@nidojan I think that it's not a very good idea to decrease the accuracy of the intermediate results (using evalf, say) duing the looped calculation. So I've left such rounding-down until the Array/Tabulated pretty-printing stage.

Below, I've moved the call to Jacobian outside the loop, on general efficiency grounds. I've gotten rid of the variable pointt. I changed sol[n] to just sol since the values are already stored in x and y. Also, there will always be an x[n],y[n] pair that is computed after the last instance of the Jacobian. (There's not much point computing the last point's Jacobian and not then definitely not using it.)

I've changed from J^(-1) to a call to LinearSolve, on general grounds of numeric robustness.

Ideally all the code could be put into a easily re-usable procedure. I've left that for you, and the same for fancy stopping criteria such as forward-error or x-increment tolerances.

The colored Table at bottom looks nicer in the actual Maple GUI.

q1nwtnnonlinearsys_2.mw

@Markiyan Hirnyk Yes, but that is advanced. People new to Maple should start with handling and manipulating expressions. Operators and procedures should come after they've understood the basics of expressions. I saw enough in this member's first three Questions to make the judgment call that an introduction to integrating with expressions would be a gentle start.

@Markiyan Hirnyk Yes, I deliberately omitted that one because I didn't want to lead him closer to difficulties with 2D Input and the typeset integral (ie. from palette, or via command completion), or toward the poor habit of defining an operator just for sake of only ever referencing it as a function call like f(x).

@tomleslie Since it is not the job of evalb to test `whether expressions are "equivalent"' then it's not the best tool for your example.

An advantage of `is` over evalb (when it's not hitting a bug) is that `is` can return FAIL in a broader set of (nonnumeric) cases where it cannot ascertain whether the result is true or false. In contrast, when evalb returns false you are left wondering whether some stronger intermediary command would produce the opposite result.

Also, within the context of a conditional test, it can be more awkward in my opinion to deal with evalb returning a relational argument unevaluated than it is to deal with `is` returning FAIL.

Download evalb_is.mw

[edit] It might also be of interest to some people that, while simplify neither combines or expands the rhs or lhs of that expression assigned to ee (since neither form is canonically simpler), it will simplify their difference to zero.

@Joe Riel Right. This is not supposed to be the job of evalb.

It is supposed to be the job of is, but unfortunately that can return FAIL for the example in question under the given assumptions (and false without them). I am submitting a bug report against is with this example as details.

note. I get exact zero from each of combine, expand, and simplify.

[edited]

What I would have expected to work is using is like so,

ff := c^10*c^n - c^(n+10):

is( ff  = 0 );
                      true

Possibly related, I notice this difference in behaviour,

restart;
ff := c^10*c^n - c^(n+10):
ee := 2^10*2^n - 2^(n+10):

combine(ee,power), combine(ff,power);                    
                       0, 0

simplify(ee,power), simplify(ff,power);           
                     n    (n + 10)
               1024 2  - 2        , 0

I included such details in my bug report for the original example. I also submitted a report that the following allocated large resources quickly (and required a kill from the OS):
   testeq( -4*2^(a+I*b)+2^(a+I*b+2) )

@ThU See this thread for an earlier discussion. You may scroll through the Comments on my Answer there, as there were refinements to the original for handling units, and addition of context-menu items. Here's a file. Phasors11.zip

I keep meaning to turn it into a special maplecloud/maple2017 package thing. (I started it... help page, move some stuff into ModuleLoad, etc, but then got busy.)  Perhaps it ought to be renamed "DegreePolar". Opinions?

What makes your correction to your nlc2 (to use the appropriate and documented form of procedure for the constraint) work is not that it returns W[1], but rather that it updates the entry of its second argument (the Vector W) inplace. It could return NULL and work as well.

Here is an example like what you first suggested (with strict equality constraints), working in both Maple 2017.3 and Maple 14.01 on 64bit Linux. I used both Operator form and Matrix form. For the Matrix form I also passed in procedures for the objective-gradient and constraint-jacobian. (I'm not sure how much general interest might be drummed up for the failings of Maple 14, seven years and seven major releases later. But I'm willing to help with specific examples.) NLPSolve_operator.mw

Can I ask, is it your goal to try and use NLPSolve as a root-finder?

Since this does not pertain specifically to LPSolve or the rest of this Question thread then it would be more useful all round if you started new discussion in some new thread, in future. You could use the Branch tab at the bottom of a Comment to link the two threads, if you'd like. Thanks.