Raising Digits may affect which local max NLPSolve attains for the bivariate problem, but if that then gets the global max (in a range) it is likely "by luck". It's still using a solver which only promises a local max.

Alec's demonstration of using the symbolic `maximize` rather that the numeric `NLPSolve` is nice here.

Of course, quite often a multivariate expression will not be a product of univariate expressions, nor will the symbolic `maximize` always be able to find an explicit solution. In general, finding a numeric global max of a multivariate expression is not so easy (especially without the GlobalOptimization add-on, which itself can require fiddling with options).

acer

You haven't added any more detail of what you expect to be done for the lengthier expressions.

By "characterize" I meant something like giving an explicit description. I don't see a pattern in your lengthy expression (involving kc,dn, etc) that matches the much shorter examples involving x1,x2,x,y,etc. In particular, you may wish to clarify what you mean by terms being relevent (or not) to the factorization. (You may find that hard and it might even be that recourse to a stated goal of simplification to an end-pattern, or simplification by length, is easier. If so, then the pattern might be spelled out by you much more clearly.) But maybe I am just being slow.

acer

You haven't added any more detail of what you expect to be done for the lengthier expressions.

By "characterize" I meant something like giving an explicit description. I don't see a pattern in your lengthy expression (involving kc,dn, etc) that matches the much shorter examples involving x1,x2,x,y,etc. In particular, you may wish to clarify what you mean by terms being relevent (or not) to the factorization. (You may find that hard and it might even be that recourse to a stated goal of simplification to an end-pattern, or simplification by length, is easier. If so, then the pattern might be spelled out by you much more clearly.) But maybe I am just being slow.

acer

The first step is easy enough to accomplish. I hadn't bothered to post it because, easy as it is, I don't see how it assists in the final goal.

> map(normal,collect((x^2+2*x+1+y)/(x+1)^2,y));
                                    y
                                 -------- + 1
                                        2
                                 (x + 1)

The final goal doesn't seem to be clearly characterized (to me, at least).

acer

The first step is easy enough to accomplish. I hadn't bothered to post it because, easy as it is, I don't see how it assists in the final goal.

> map(normal,collect((x^2+2*x+1+y)/(x+1)^2,y));
                                    y
                                 -------- + 1
                                        2
                                 (x + 1)

The final goal doesn't seem to be clearly characterized (to me, at least).

acer

Supply the simple bounds on variables like so (when using "expression form"),

GlobalSolve(..., Kguess[1]=3..17, Kguess[2]=19...27 );

The [bl,bu] option is related to the "operator form" (which you're no longer using). Replace those numbers such as 3,17,etc with your known bounds.

With such positive bounds supplied, the assume=nonnegative option should not be necessary.

acer

Supply the simple bounds on variables like so (when using "expression form"),

GlobalSolve(..., Kguess[1]=3..17, Kguess[2]=19...27 );

The [bl,bu] option is related to the "operator form" (which you're no longer using). Replace those numbers such as 3,17,etc with your known bounds.

With such positive bounds supplied, the assume=nonnegative option should not be necessary.

acer

I believe that {..} curly braces are required around the constaints, so that they get passed as a set (even when there is just a single constraint).

acer

I believe that {..} curly braces are required around the constaints, so that they get passed as a set (even when there is just a single constraint).

acer

I see. The problem is in the creation of procedure p.

Consider the following example. Here, the formal parameter x of procedure p is not the same as the x in F.

> F := x:
> p := proc(x) F; end proc:
> p(1);
                                       x
> x:=17:
> p(1);
                                      17

Sometimes, a way to get the intended effect is to use unapply to create the procedure. But for your code you'd want to somehow "unapply" w.r.t the Kguess[i] so that the formal parameter was Kguess (to be passed as a Vector). Which is awkward. Another way might be to create the proc with the add call, etc, in its body.

But maybe it can be easier still. Do you really need to use the "operator form" in calling NLPSolve? Could you instead call it with the objective in "expresion form"? The expression would be the result of the add call. Ie,

Optimization:-NLPSolve(
   add(ObjectiveFunction[i], i = 1 .. nn)/nn,
   assume = nonnegative);

acer

I see. The problem is in the creation of procedure p.

Consider the following example. Here, the formal parameter x of procedure p is not the same as the x in F.

> F := x:
> p := proc(x) F; end proc:
> p(1);
                                       x
> x:=17:
> p(1);
                                      17

Sometimes, a way to get the intended effect is to use unapply to create the procedure. But for your code you'd want to somehow "unapply" w.r.t the Kguess[i] so that the formal parameter was Kguess (to be passed as a Vector). Which is awkward. Another way might be to create the proc with the add call, etc, in its body.

But maybe it can be easier still. Do you really need to use the "operator form" in calling NLPSolve? Could you instead call it with the objective in "expresion form"? The expression would be the result of the add call. Ie,

Optimization:-NLPSolve(
   add(ObjectiveFunction[i], i = 1 .. nn)/nn,
   assume = nonnegative);

acer

That is a clever trick. But it's a little risky as it deliberately subverts the error/warning mechanism of detecting a missing (called) routine. One then needs special care to ensure that all called exports are properly redefined with their "full" versions.

I'd like to see a Suggested Coding Practices document, that includes things such as (eg. Joe's earlier) recommended forms of using uses, cat vs || and seq vs $ evaluation distinctions, etc. The new Portal might be a good place for it.

acer

Hmm, all those comparisons with X-oldX could be tidier. More like simply  if X-oldX<5 then... else... end if;

acer

Hmm, all those comparisons with X-oldX could be tidier. More like simply  if X-oldX<5 then... else... end if;

acer

Sorry, you are indeed wrong.

Suppose the function f is thread-unsafe, or that it calls a thread-unsafe Library routine. Then the answers computed in different Threads may partially clobber each other and then be incorrect.

A typical way for a routine to be thread-unsafe is for it to write out and store partial results in a global variable. Thread A writes a partial result, which gets overwritten by Thread B, and then Thread A accesses that variable's value so as to use the intermediary value it stored there (but which is now replaced, ooops).

In Maple, there are a delightful number of ways to "write an intermediary result, globally".

acer