Since Maximize promises only local maxima for multivariate problems, you may have to guard against false negatives. If it returns a positive max, then you're done. But if it returns a nonpositive max then you might have to fall back to verify (or is).

Could you call Optimization:-Maximize(), and check whether the result is positive? In doing so, the previous assumptions of bounds on the variables would be supplied as ranges or constraints to Maximize().

Could you call Optimization:-Maximize(), and check whether the result is positive? In doing so, the previous assumptions of bounds on the variables would be supplied as ranges or constraints to Maximize().

Instead of creating a procedure that differentiates the result of f(x1,x,x3,x4) for each input (x1,x2,x3,x4), could you not use the differential operator D?

Eg,

> f := (x1,x2,x3,x4) -> (x1+x2^2+x3^3+x4^4)^2;
                                                2     3     4 2
               f := (x1, x2, x3, x4) -> (x1 + x2  + x3  + x4 )

> df := (x1,x2,x3,x4) -> eval( diff(f(x1, x, x3, x4), x), x=x2 );
                                      /d                  \|
            df := (x1, x2, x3, x4) -> |-- f(x1, x, x3, x4)||
                                      \dx                 /|x = x2

> df(1,2,3,4);
                                     2304

> df:=D[2](f);
                                                 2     3     4
             df := (x1, x2, x3, x4) -> 4 (x1 + x2  + x3  + x4 ) x2

> df(1,2,3,4);
                                     2304

Is it really necessary to differentiate for each call?

Instead of creating a procedure that differentiates the result of f(x1,x,x3,x4) for each input (x1,x2,x3,x4), could you not use the differential operator D?

Eg,

> f := (x1,x2,x3,x4) -> (x1+x2^2+x3^3+x4^4)^2;
                                                2     3     4 2
               f := (x1, x2, x3, x4) -> (x1 + x2  + x3  + x4 )

> df := (x1,x2,x3,x4) -> eval( diff(f(x1, x, x3, x4), x), x=x2 );
                                      /d                  \|
            df := (x1, x2, x3, x4) -> |-- f(x1, x, x3, x4)||
                                      \dx                 /|x = x2

> df(1,2,3,4);
                                     2304

> df:=D[2](f);
                                                 2     3     4
             df := (x1, x2, x3, x4) -> 4 (x1 + x2  + x3  + x4 ) x2

> df(1,2,3,4);
                                     2304

Is it really necessary to differentiate for each call?

cf. plot,colornames

cf. plot,colornames

map2(map,combine,H);

map2(map,combine,H);

The modp1 Help Example in 1D format has

> a := modp1(ConvertIn(x^4-x^2+2,x),p);

which when switched to 2D Math input becomes

> a := (x^4-x^2+2) mod p

There is unwanted evaluation (of the typeset input) happening during the conversion to 2D Math. It happens for another ConvertIn call in the page.

It would be better if the 1D<->2D toggle in the Help didn't simulatenously switch multiple opened Help navigator windows (both when showing different or the same individual help pages).

The Online Help would be improved if copying from the Examples were possible.

A means to toggle the Examples to 1D Maple input would also be useful.

I see no problem with the units (if entered with correct syntax, since simplifying the mapped division by T makes the data Ratio dimensionless). The length of Ratio needn't match, and the revised lengths of Z and Ay match (19). The routine appears to call externally, so evalf[4] only hits the final results and fortunately doesn't appear to undesirably reduce the working precision of the computation.

It seems simple enough. All that's left is to call AY(x,T).

> x := [0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 7.5,
>       10.0, 12.5, 15.0, 17.5, 20.0, 22.5, 25.0, 30.0]*Unit(ft):

> T := 1.887*Unit(m):

> AY := proc(x, T)
> local Z, Ay, Ratio, beta;
>     Ratio := simplify(evalf(x / T));
>     Z := [0.0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6,
>           0.7, 0.8, 0.9, 1.0,1.2, 1.4, 1.6,
>           1.8, 2.0, 3.0, 4.0, 5.0];
>     Ay := [2.435, 2.273, 2.112, 1.952, 1.796, 1.644,
>     1.496, 1.353, 1.216, 1.086, 0.962, 0.738, 0.544,
>     0.381, 0.247, 0.142, -0.075, -0.050, -0.009];
> beta := evalf[4](CurveFitting:-ArrayInterpolation(Z, Ay, Ratio));
> end proc:

> AY(x,T);
[2.435, 2.174, 1.916, 1.667, 1.430, 1.206, 0.7269, 0.3708, 0.1379, 0.05023,
 
    -0.03740, -0.06924, -0.05914, -0.04844, -0.01532]

I see no problem with the units (if entered with correct syntax, since simplifying the mapped division by T makes the data Ratio dimensionless). The length of Ratio needn't match, and the revised lengths of Z and Ay match (19). The routine appears to call externally, so evalf[4] only hits the final results and fortunately doesn't appear to undesirably reduce the working precision of the computation.

It seems simple enough. All that's left is to call AY(x,T).

> x := [0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 7.5,
>       10.0, 12.5, 15.0, 17.5, 20.0, 22.5, 25.0, 30.0]*Unit(ft):

> T := 1.887*Unit(m):

> AY := proc(x, T)
> local Z, Ay, Ratio, beta;
>     Ratio := simplify(evalf(x / T));
>     Z := [0.0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6,
>           0.7, 0.8, 0.9, 1.0,1.2, 1.4, 1.6,
>           1.8, 2.0, 3.0, 4.0, 5.0];
>     Ay := [2.435, 2.273, 2.112, 1.952, 1.796, 1.644,
>     1.496, 1.353, 1.216, 1.086, 0.962, 0.738, 0.544,
>     0.381, 0.247, 0.142, -0.075, -0.050, -0.009];
> beta := evalf[4](CurveFitting:-ArrayInterpolation(Z, Ay, Ratio));
> end proc:

> AY(x,T);
[2.435, 2.174, 1.916, 1.667, 1.430, 1.206, 0.7269, 0.3708, 0.1379, 0.05023,
 
    -0.03740, -0.06924, -0.05914, -0.04844, -0.01532]

You could try running the procedure (which does everything, including writing to the Math Container) inside a Threads:-Create call.

You could try running the procedure (which does everything, including writing to the Math Container) inside a Threads:-Create call.