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

@das1404 You can multiply Matrices and Vectors (even without loading the LinearAlgebra package) using `.` which is a noncommutative multiplication command. For example, and note the absence of executing any statement like with(LinearAlgebra) below,

When I was making wild guesses about your earlier code went astray when re-executed, I suggested unassigning u and s. Note that I used single right-quotes (aka unevaluation quotes) for that. One uses single left-quotes (aka name quotes) in order to use a language keyword like union in a prefix function call, as you did. But these two kinds of quotes serve different purposes. The unevaluation quotes act to delay evaluation, so that you can refer to an assigned name and get at its name rather than its assigned value. Here are two ways to unassign,

s:={a,b,c};       # now assigned a value
                           {a, b, c}

s:='s';           # single right-quotes
                               s

s;                # no longer assigned
                               s

s:={a,b,c};       # now assigned a value
                           {a, b, c}

unassign('s');    # single right-quotes

s;                # no longer assigned
                               s

Next, for a Matrix M the syntax M[1,..] refers to the first row. In very old Maple versions that did not support that syntax an equivalent would be M[1,1..-1] or even M[1,1..n] where n is the number of columns.

Moving on... If you are a student then you can purchase the latest Maple version for some relatively low cost (like $150 or something). You might even be able to find someone who'd sell you a used copy of a version less than 5 years old. There have been a lot of improvements since Maple 7.

It's just my opinion but I'd say that Maple's programming language and functionality are its jewel in the crown. The introductory User Manual of modern Maple has unfortunately had a great deal of its basic 1D Maple language information removed. But modern Maple's Programming Manual contains a lot of good information, though it may be a difficult first read for a Maple beginner.

A reasonably good introductory text on basic Maple, suitable for older versions, is the Learning Guide. That link is to the Maple 9 version of it. The oldest online version I'm aware of is the Maple 8 version available from under here. A good older book on Maple programming, suitable also for beginners, is Andre Heck's book. A good modern book on Maple programming, suitable also for beginners, is Ian Thompson's recent book.

If the topic is of interest to you, another way to compute these determinants is:

restart;

det := proc(n) local x; resultant(x^n-1,(x+1)^n-1,x); end proc:

seq( det(k), k=1..10 );

    1, -3, 28, -375, 3751, 0, 6835648, -1343091375,

    364668913756, -210736858987743

@das1404 You could try the command,

interface(rtablesize=20):

to allow Matrices of dimension up to 20x20 to be displayed in full. Otherwise they just print in the short form. This relates only to how they get printed -- tersely, or in full. Accessing them should work regardless of this setting. I am not 100% sure whether that interface call worked the same in Maple 7, or what the default setting was. My memories of the year 2001 are not that clear.

I believe you'll find that the one-line code I gave to construct the Matrix does produce it as expected, invoked like M(12), M(13), etc.

The oldest version to which I have access to the commandline interface is Maple 9, and the oldest version to which I have access to the GUI is Maple 11 (I think).

In very old versions of Maple it is true the sets were ordered and stored internally according to memory address. That was still true in Maple 9 too, but in that version I have not been able to reproduce the erratic behavior you described.

When you say that you ran the code "again" does that mean that you did a restart between them, or otherwise unassigned both s and u?  You would need to do that because of the way your code assigns to s using table references to s itself (and similalrly for u). If s and u are not first unassigned and have their previous run's values then the code will not work properly (producing an error message in modern Maple and possibly your stated problems in your version). If you don't do a restart then at least put  s:='s': and u:='u':  at the top of your computational code. Better yet put the Matrix construction code all into a procedure where s and u are declared local variables.

@mbras On the help page for sum there is a clear Note about using add instead of sum for adding up up a finite number of terms.

On the help page for topic sum,details there is more mention of this, and a discussion in the later part of the Examples, titled "Comparing sum and add". That explains quite a bit of the differences, and what's going on.

Reading the help pages for a command with which you're having difficulty is often a good place to start.

@exality The inability to protect to the name sqrt happens regardless of whether Units:-Standard is loaded or not, ie. regardless of whether the name is bound to the package export name Units:-Standard:-sqrt or to the global :-sqrt .

Both of those are protected names, which is Maple's way of ensuring that you don't clobber the system names.

But as you now know, you can just apply sqrt~(...) and don't need to first make any assignment to the name.

In my 2nd usage example I used a custom, anonymous operator only because it let me utilize the pretty 2D radical symbol.

@rlopez 

The problem occurs because Component action code picks up current name bindings when executing. The key item here is that when `=` is rebound to Units:-Standard:-`=` then DocumentTools:-Do does not interpret a first argument like %Plot0=P as intended.

IMO the DocumentTools:-Do command is ill-designed, and people should always use DocumentTools:-SetProperty and DocumentTools:-SetProperty instead.

Here is a worksheet that exhibits the problem. It fails with DocumentTools:-Do when Units:-Standard is loaded, but works with DocumentTools:-SetProperty.   Do_equals.mw

I notice other problems in this and several other Task Templates. Their action code is generally not mint clean, in the sense that unprotected global names are used without proper protection against evaluation or misidentification as locals.

For example, color=red instead of 'color'=':-red'. If the global name red gets assigned a value then the code no longer works.  (Most plotting command optional keyword values can be supplied as strings, so 'color'="red" also works.)

Another misuse of global names is in referenced commands in the form Student[Precalculus][Distance] , which also suffers because that involves unprotected references to names (as if global, but not denoted as global). If the user assigns a value to the unprotected global name Precalculus then the code no longer works. More robust would be either Student[':-Precalculus'][':-Distance'] or Student:-Precalculus:-Distance . See the help page for topic colondash for more.

In the Bezier curve Task Template I see about a dozen instances of these issues.

As I mentioned, you haven't uploaded a Worksheet or Document that contains code to reproduce the problem, ie. code that constructs such a Matrix as well as the way the command is being called. Without that the best we can do is guess at the cause.

You can attach a worksheet to a response here using the green up-arrow in the Mapleprimes editor.

@vv It seems to be an undocumented kernel thing, only working for symbols (which it does not evaluate).

restart;
kernelopts(version);
        Maple 2017.3, X86 64 LINUX, Sep 27 2017, Build ID 1265877

T:=table([eleventeen=P]):
eleventeen:=37:

T['eleventeen'];
                              P

T[eleventeen];
                            T[37]

T:-eleventeen;
                              P

@MDD Try replacing simplex:-minimize by simplex[minimize] .

Adjustment to spacing (though not really more robust or general purpose...)

Download typeset_math_text_2.mw