Re: Problems with NMaximize.

*To*: mathgroup at smc.vnet.net*Subject*: [mg69350] Re: [mg69168] Problems with NMaximize.*From*: Daniel Lichtblau <danl at wolfram.com>*Date*: Thu, 7 Sep 2006 23:58:47 -0400 (EDT)*References*: <200608310840.EAA19660@smc.vnet.net>

Nacho wrote: > Hello. > > I'm trying to solve a real-life problem using Mathematica and I am > having some problems with NMaximize. > > As background, the problem is related to VDSL2 technology. The physical > frame can be configured using different parameters (primary parameters) > and those parameters defines the secondary parameters. > > I want Mathematica to maximize the datarate in the line while > maintaining some performance on the secondary parameters. > > Now, the formulas. > > I want to maximize the datarate, definded as: > > l*(nfec-r-1)*4000/nfec > > the other constrains are: > > 4*d*r*i / (l*nfec) >= 4 > > nfec==q*i > > 0<= (i-1)*(d-1) / (l*500) <=0.016 > > And the parameters have the following restrictions: > > l, nfec, r, d, i, q are all Integers (but the calculations done with > them not neccessarily). > > 1000<=l<=23850 > > 1<=q<=8 > > 1<=d<=2048 > > 1<=nfec<=255 > > r can take even values between 0 and 16 (0,2,4,6,8,10,12,14,16) > > > > I think that this is all. > > I have been unable to Nmaximize the result, and as I tried different > approaches (leaving the variables as Reals and then making them > Integers little by little, eliminating some variables...) I get > different results. > > Sometimes the maximized value is really low, others it fails to > converge, others it finds a 1/0 indetermination... > > > The best approach I could find is this one, eliminating "i" from the > equation set: > > > NMaximize[{l*(nfec - > r - 1)*(4000/nfec), (4*d*r)/(l*q) >= 4, 0 <= ((-1 + d)*(-1 + > nfec/q))/(500*l) <= 0.016, l â?? Integers, > nfec â?? Integers, r â?? Integers, d â?? Integers, q â?? Integers, > > 1000 <= l <= 23850, 1 <= q <= 8, 1 <= d <= > 2048, 1 <= nfec <= 255, 0 <= r <= 16}, {l, nfec, r, d, q}] > > > > (I hope that the E indicating that a variable belongs to a domain are > displayed). But it complains about a lot of constraints, I don't know > why... > > > I don't know how to say Mathematica that a variable can take just some > values (as for r being even), but I just said it is between 0 and 16. > > > Any help is welcomed to solve the problem. > > Thanks in advance. > > Regards. As has been observed, NMaximize has problems with handling the constraints in the form of rational expressions. We are treating this as a bug. If you clear denominators, solve for nfec (not strictly necessary, but improves efficiency), assume i>=1 to maintain positivity of all relevant expressions, then you can get what may be a plausible result as below. vars = {l, r, d, i, q}; In[22]:= Timing[mm = NMaximize[{l*(q*i-2*r-1)*4000/(q*i), {d*2*r >= l*q, 0 <= (i-1)*(d-1) <= 8*l, 1000<=l<=23850, 1<=q<=8, 1<=d<=2048, i>=1, 1<=q*i<=255, 0<=r<=8, Element[vars,Integers]}}, vars, MaxIterations->500, Method->{"DifferentialEvolution", SearchPoints->50}]] NMaximize::cvmit: Failed to converge to the requested accuracy or precision within 500 iterations. 7 Out[22]= {13.7009, {8.26144 10 , > {d -> 1988, i -> 97, l -> 23850, q -> 1, r -> 6}}} Retrying with MaxIterations->5000 and SearchPoints->100 predictably took about 20x longer and gave the same result. Not exactly a proof of optimality, but at least gives some cause to believe it will take a bit of luck to do much better. Experiments in relaxing by removing the integrality constraints show that the max does not seem to improve much, and the parameter values are near to those indicated above. To the extent that the continuous optimization can be trusted to work better than discrete, this gives further reason to believe the above result is sound. Daniel Lichtblau Wolfram Research

**Re: RE: Re: Dot Product in Cylindrical Coordinates**

**Re: solve the following problem**

**Re: Problems with NMaximize.**

**Re: efficient term collection algorithm**