Maximize violating constraints
Using a symbolic functionality like Maximize
with an expression involving approximate numbers is not in general a good idea, even though Maximize
calls automatically NMaximize
in such cases. However if we rewrite the expression to an exact form, then Maximize
will run very long time returning no symbolic results.
The problem one encounters here is most likely not a very smart approach for the constraint equation specified here as (l + d + H + h) == 669
. When the system puts the constraint to the expression involving fractional powers it fails, nonetheless we can simply solve this constraint getting rid off one variable e.g. h
. so we can get the result immediatley this way:
NMaximize[{(10 (669 - l - d - H))/(300 (100 - (l^(1/2) + d^(4/10) + H^(6/10)))),
l > 0, d > 0, H > 0}, {l, d, H}]
{0.23866, {l -> 12.8156, d -> 5.77564, H -> 38.2498}}
now we solve the constraint:
NSolve[(l + d + H + h) == 669 /. Last @ %, h]
{{h -> 612.159}}
I suspect you are correct in your assessment. Since there are approximate numbers in the input, Maximize
punts to NMaximize
, which uses penalty methods to enforce some constraints (not sure why it needs them here for linear constraints; I need to check into that).
You can get better behavior by forcing real values.
NMaximize[{Re[(h*10)/(300*(100 - (l^.5 + d^.4 + H^.6)))], (l +
d + H + h) == 669, l > 0, d > 0, H > 0, h > 0}, {h, l, d, H}]
(* Out[2]= {0.2386596519573097, {h -> 612.1588854816083,
l -> 12.8156550218952, d -> 5.775648336504858,
H -> 38.24981115999163}} *)
try FindMaximum.
FindMaximum[{(h*10)/(300*(100 - (l^.5 + d^.4 + H^.6))), (l + d + H +
h) == 669, l > 0, d > 0, H > 0, h > 0}, {h, l, d, H}]
(*{0.23866, {h -> 612.159, l -> 12.8158, d -> 5.77578, H -> 38.2499}}*)