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

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

Thanks, Erik, that's useful. On the one hand it's nice to know, as it increases the utility of evalhf. But on the other hand it's unfortunate, since the [] notation is less naturally safe than the :- notation. It would be simply better if evalhf supported both forms.

I once wrote some comments on the [] vs :- form for referencing module based package members. In this case, the generally safe form would be the longer Statistics[':-Mean'].

acer

Thanks, Erik, that's useful. On the one hand it's nice to know, as it increases the utility of evalhf. But on the other hand it's unfortunate, since the [] notation is less naturally safe than the :- notation. It would be simply better if evalhf supported both forms.

I once wrote some comments on the [] vs :- form for referencing module based package members. In this case, the generally safe form would be the longer Statistics[':-Mean'].

acer

Thanks. I did know that, and it was one thing that I had tried. However,

> kernelopts(version);
            Maple 12.01, X86 64 LINUX, Sep 23 2008 Build ID 363216

> p := proc(V::Vector(datatype=float[8]))
> eval(Statistics:-Mean(V));
> end proc:
> V := Vector[row]([1,2,3],datatype=float[8]):
> p(V);
                                      2.
 
> evalhf(p(V));
Error, module member referencing is not supported in evalhf

The same for 13.00, Build ID 388356.

acer

Thanks. I did know that, and it was one thing that I had tried. However,

> kernelopts(version);
            Maple 12.01, X86 64 LINUX, Sep 23 2008 Build ID 363216

> p := proc(V::Vector(datatype=float[8]))
> eval(Statistics:-Mean(V));
> end proc:
> V := Vector[row]([1,2,3],datatype=float[8]):
> p(V);
                                      2.
 
> evalhf(p(V));
Error, module member referencing is not supported in evalhf

The same for 13.00, Build ID 388356.

acer