       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.
>
>
> 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:= 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= {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

```

• Prev by Date: Re: RE: Re: Dot Product in Cylindrical Coordinates
• Next by Date: Re: solve the following problem
• Previous by thread: Re: Problems with NMaximize.
• Next by thread: Re: efficient term collection algorithm