@Christiawanta Well, you use x already in your sum; and NLPSolve minimizes a function by varying its independent variables (indets in Maple lingo) so no, you don't need or want x explicitly in NLPSolve. While your data table suggest this is a kind of least-square-type minimization, it is formulated as a minimization problem for a function and does not explicitly deal with x other than in the sum of the terms. Since the terms are all squared the sum should be positive definite (unless you have complex terms, which you should not) and should have a minimum.

Some observations: You use a both as a "function" as well as a variable storing one of your constraints. I suggest you get rid of the line a(x):=qtopi[x] as you don't need it. Just put qtopi[x] into your expression to be minimized. While you are at it, please change sum() to add(); sum() tries to evaluate a symbolic sum into a closed expression, which is not what you want here.

I would also try to get rid of the first constraint (the sum of the psi angles to be 1) by eliminating one of the angles (psi3=1-psi1+psi2). You have already more constraints than is healthy so getting rid of one can only help.

I would also try to evaluate your expression numerically for a set of parameter values that fulfills all the constraints, just to see if the answer makes any sense. If you have such a set you can even consider building up the number of variables to be included in the optimization problem, thereby finding when the algorithm gets into trouble (if it gets into trouble).

Cheers,

M.D.

@greenloafer Ahh... the plot thickens, so to speak.

It appears that the amer_approx code calls functions out of the bs program. The way to do this properly in Maple would be by wrapping up all the functions from bs (after conversion to proper Maple syntax) in a module, or even better a package (which is a module with option package specified) and export each function (which we then should call a method). So

bs:=module() option package
export N,phi,... ; # sequence of all the function names in bs
<here come all your functions, one after the other in arbitrary order, just following the template I gave earlier>
end module;

Since you are not familiar with Maple I suggest you pre-pend this whole module to your converted amer_approx code and call (execute) bs on the first line. After that you can use all the functions just like having written them without the module construct. The (better) alternative would be to save this as a .mla file and put it into a library and loading it using with(bs); but that involves some trickyness in getting Maple to do this and later find it & I do not recommend this until you have gotten your feet wet in Maple and also debugged the routines. If you expect to use these more often, however, that is what you will eventually want to do.

Just for completeness, there is a more pedestrian alternative: you can put the Maple code into a text file, save it with extension .mpl and then code

read("/path/bs.mpl");

This will read and execute the code and thereby define all the functions. Here /path/ is the directory path to the file (in Windows it would be something like C:\...\). You can still make a module and may have to execute that.

Presumably the thesis referenced in the header of amer_approx.txt has explanations how this model works and maybe even test cases.

M.D.

@greenloafer Ok, you have in your python file

def phi(z):
        return exp(-.5 * z * z) / (sqrt( 2 * pi ))

This obviously defines a function phi(z). In Maple, the general way to do the same thing would be to define a procedure like this:

phi:=proc(z)
  return exp(-.5 * z * z) / (sqrt( 2 * Pi ))
end proc;

(and before this gets side-tracked, since phi is a function the more terse way would be to write
phi:=z -> exp(-.5 * z * z) / (sqrt( 2 * Pi ));
but that would not work with a more procedural routine. proc() always works.)

You then use your function by assignment:

y:=phi(z);

I urge again to make the effort reading some of the documentation. It is worth it if you want to use Maple on a routine basis and derive the benefit.

M.D.

Edit: Pi is capitalized in Maple.

@greenloafer I don't really program in python, but this code looks straightforward to port to Maple.

def function() becomes function:=proc()...end proc;

= assignments become := in Maple

** becomes ^

pi becomes Pi

and all statements need to be terminated with ; or with : (if you want to suppress output),

and that seems mostly it, with one important caveat: Maple being a symbolic environment will keep anything that isn't assigned a number to as a symbol. This leads to the potential of accumulating huge expressions and slowing things to a crawl just because of a spelling error or a forgotten assignment. You can partially avoid this trap by wrapping your functions and/or expressions in an evalhf() statement, but that can fail in other ways. evalf() does not work, it will just evaluate what it can & leave the rest symbolic.

You may run into some names that Maple considers reserved works in which case you'll have to rename them.

M.D.

Edit: removed incorrect comment about N() being undefined. It is in fact defined at the top of the file.

Although I never use palettes, I can see this being useful for large packages with many different functions or procedures. Having the package—upon loading—create a palette as you describe thus giving access to the top-level functions of the package should be a nice facility esp. for novice users.

Thanks for sharing this,

M.D.

@akhmeteli I don't have time right now to try this myself (and the math is beyond my knowledge) but if your algorithm is a loop construct (like 2.25 in the paper) then I would, as a first step, use print() to have it put out some status info on each pass. Yes, it'll litter your worksheet but at least you can see where it slows down or hangs. Per se, >1 GB should not be a problem on a 64-bit system; maybe a problem on a 32 bit system, though (and on macOS at least I have seen the mserver process take twice as much memory than it advertises on the status like). And I have seen Maple choke on large expressions like this.

Gotta go,

M.D.

@Lali_miani As written, you do not have a "system". In your file there are merely three procedures, or functions, each one takes three arguments.

Now, you can rewrite these three procs as one vector function that transforms the vector <x,y,z> into a new one <x2,y2,z2>. Then you can talk about things like fixed points etc., which would be the vector <x,y,z> that gets transformed into itself. I am not sure it exists for your system as it is not homogeneous (actually, I am sure it does not exist in general as e.g. f1 returns II + something, which can never be x unless II is 0, likewise for f3 which returns alpha). A quick try with solve did not return a solution for such a vector <x,y,z>, as expected.

Maybe I am missing something here, but then the problem needs to be clarified.

Mac Dude

@Christopher2222 Maple is a computer-algebra system. I really do not see how web-browser functionality is essential for that.

Besides, there are more than enough bugs and problems with Maple I am dying to see fixed. Sidetracking the Maple develper team with providing web-browser functionality seems a distraction and only likely to further delay bug fixing.

My $0.02,

Mac Dude

Consider yourself lucky. Maplesoft stopped supporting my perfectly fine G5 PowerMac after Maple 15 (and there is no 20 in front of the 15)... :-)

Mac Dude.

@vv Thanks much for your suggestion.

Let me give a little more detail: My problem arises from expression involving constructs like this:

(and the real ones are a lot longer that this snippet). The difficulties for taylor are then obvious: id d1kQ1 is negative (in this case) the sqrt can get imaginary. This should be easily solved by assuming dkQ1 to be within (-1..+1), say (which would be totally acceptable for my case). Except that I find mtaylor to barf at the assumptions, or ignore them, or just return unevaluated (I found the behaviour to be not reproducible). Sometimes regular taylor works better.

I am enclosing a worksheet that demonstrates some of the issues. It also shows my attempt to use vv's mseries, which was not successfull. I spare MaplePrimes listing it here as it involves too many endless numbers (all of course generated expressions).

I cooked up a quick & dirty one:

mymseries:=proc(f,vars,norder)
      local i,fs:=f;
          for i from 1 to numelems(vars) do
              fs:=convert(series(fs,vars[-i],norder),polynom);
          end do;
          return fs;
      end proc;

but it has some issues. First and forward, it does not control the order the way mtaylor does in that it will keep bilinear and higher-order products as it only expands by one variable at any given time. I can fix that with a final mtaylor (which will work on the result) but certaily have not proven yet that the end result is correct. I also don't like the for...next loop.

Thanks again,

M.D.

mtaylor_test.mw

So while the underlying problem is not any different, I did find a work-around to address my problem: In the original definition I used the self:- construct in a function definition to refer to another element in the same Record (which should be perfectly legal code in a function). That, in conjunction with the subs command, appears to be broken now (and contrary to my assertion above, it is already broken in Maple 2015). So I moved some of the expressions out of the Record definition and made them functions and then use these in the Record definition. That seems to work. I am concerned, however, as I have other packages that use similar constructs. I guess I should be prepared for some breakage.

For completeness sake I am appending the updated version of the package code.

M.D.

BooMBA.mw

@Carl Love I stand corrected.

Still the OP should get the Programming Guide. It is a treasure trove, even if one does not write many modules or packages.

M.D.

@Ronan You really want to get a (pdf-) copy of Maple's Programming Guide. You can download it from Maplesoft's support pages, specifically, this page has near the bottom a link to the Programming Guide:

http://www.maplesoft.com/documentation_center/

It answers most of your questions (and some you didn't even know you had).

Some easy answers: Yes, you can have a variable number of parameters. You can set defaults for each one. You can use Null as a parameter value when you call a function or procedure. The Programming Guide explains all of that.

As for your types; I have written packages that define and use their own types. So I know the scheme Carl proposed (with the AddType statements in a ModuleLoad proc) works. Make sure you are calling ModuleLoad(); before the end module statement. The module definition and ModuleLoad() can appear anywhere, I think...

I am not sure about your use of the "uses" clause. AFAIK, you just say "uses TypeTools" after which TypeTools is added to the list of namespaces that get searched. In other words: your equation in uses may not work. Personally, I get around such bother by using fully qualified names everywhere in my packages (i.e. TypeTools:-AddType()). Yes, more typing when writing these packages, but much easier to debug & trouble-shoot.

I hope this helps,

M.D.

Edit: Replaced some redundant remarks.

I somewhat beg to differ: one confirmation dialog before nuking and post should be ok. After all, one does on occasion hit the wrong button (well, I do at least). It could be argued, however, that similar safety escape can be provided with an undo button that shows up after a deletion (spam or otherwise) of an entry.

M.D.

@Ronan Well, the .help file has to be where Maple can find it. libname has the list of directories (folders) Maple will search. Myself, I prepend the directory with my own files to the others in libname and comingle the .mla code files and the help databases in there. In that way, my own stuff comes first should there be any name clashes (which you really want to avoid).

So, yes, moving the .help file to such a directory matters.

Mac Dude