Tag Info

Hot answers tagged

10

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 + ...


9

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 ...


5

I don't think there's a general function built in that can deal with all possible cases. But Reduce is quite powerful. Here is a function that seems to work for the last two examples given: singularCondition[func_, variable_] := Reduce[1/func[variable] == 0 || 1/func'[variable] == 0, variable, Reals] singularCondition[h, x] (* ==> x == -b *) ...


4

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}}*)


1

It might be interesting for you to compare @Jens' answer with FunctionDomain (new in V10): compare[fun_] := { fun[x], FunctionDomain[fun[x], x, Reals], FunctionDomain[fun[x], x, Complexes], analyticityCondition[fun, x], singularCondition[fun, x]} TableForm[ compare /@ {Sin, Tan, f, g, h}, TableHeadings -> {None, {"Function", "RealDomain", ...



Only top voted, non community-wiki answers of a minimum length are eligible