This change to the hover-over (tooltip, bubble-help) for the subliteral entry on the Layout palette is a behaviour regression bug (mistake) that should be reverted.

acer

Ah, yes, I see that I was not paying enough attention to the actual problem specifics. Thanks.

acer

Ah, yes, I see that I was not paying enough attention to the actual problem specifics. Thanks.

acer

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

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