acer

32348 Reputation

29 Badges

19 years, 329 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are replies submitted by 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

As mentioned here, some components can be refreshed in mid-computation, in Maple 13.

For example, given embedded meter Meter0,

for i from 1 to 4 do
  DocumentTools:-SetProperty(Meter0, 'value', i*25,
                             'refresh'=true );
  st:=time[real]();
  while time[real]()-st < 2 do end do;
end do:

acer

As mentioned here, some components can be refreshed in mid-computation, in Maple 13.

For example, given embedded meter Meter0,

for i from 1 to 4 do
  DocumentTools:-SetProperty(Meter0, 'value', i*25,
                             'refresh'=true );
  st:=time[real]();
  while time[real]()-st < 2 do end do;
end do:

acer

It is interesting, that it works for you. A couple of things could be mentioned, if I may.

Your example procedure (sub1, the Maple one) is not complicated and should execute quickly.

However, if your external `sub` function will call back very many times, and if the formulae in `sub1` become very involved, then you might consider "compiling" procedure sub1 to get more speed and less symbolic garbage. By that I mean typing it appropriately and then either applying Compiler:-Compile or giving it 'option autocompile'.

When you use the WRAPPER option to define_external, Maple actually writes out a C wrapper file and compiles it to a .dll. (It might be located in a hard to find temp dir, or in the working dir -- I forget.) If you examine that .c wrapper file (before the Maple session ends and it gets deleted) you could see that it does the callback through a C function named something like `EvalMapleProc`. Autogenerated wrappers always use that mechanism for the callback, I believe. But there is also a  EvalhfDataProc that  can be used to  make the callback  use  Maple's  fast  evalhf  interpreter.  To use it, one would have to either write a custom  wrapper for define_external (possibly by heavily editing the autogenerated wrapper as a  sort of template).  But this  approach  would almost always  be slower  to run than would the simpler approach of using Compiler:-Compile.

acer

First 486 487 488 489 490 491 492 Last Page 488 of 592