Mathematica 9 is now available
Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2005
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2005

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: LatticeReduce problem

  • To: mathgroup at smc.vnet.net
  • Subject: [mg59040] Re: [mg59005] LatticeReduce problem
  • From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
  • Date: Wed, 27 Jul 2005 01:25:34 -0400 (EDT)
  • References: <200507260803.EAA00441@smc.vnet.net> <DCE7E3C8-B833-4DF0-972B-2D6B98982449@mimuw.edu.pl> <p06210200bf0c2f45282c@[10.0.1.2]>
  • Sender: owner-wri-mathgroup at wolfram.com

On 26 Jul 2005, at 20:39, dto_mba at skynet.be wrote:

>>
>> A more serious problem is your function dln will complain when  
>> called with symbolic coefficients but that is what will happen  
>> when you use NMinimize, since NMinimize evaluates its arguments.
>
> It is not clear to me how to overcome this problem.

Defining dln like this

dln[{x__?NumericQ}, { y__?NumericQ}]:=

avoids it. Unless both arguments are lists of numerics dln is not  
evluated but just waits for NMinimize to supply values for its  
arguments.

>> Another problem is that in spite of the constraint  NMinimize will  
>> attempt to compute dln for real values of x1,x2,x3 and x4 and  
>> LatticeReduce is not defined non-rational vectors. So I have re- 
>> written dln in the form:
>>
>> dln[{x__?NumericQ}, { y__?NumericQ}] :=
>>     Norm[ LatticeReduce[{IntegerPart /@ {x}, IntegerPart /@ {y}}]]
>
> Does NMinimize round the real values before it calculates the  
> objective function value?

No, I think it actually tries to compute the value of the objective  
functions for real number arguments and and uses penalties when the  
constraint is violated. According to the documentation with the  
default method setting:

If there are integer variables, or if the head of the objective  
function is not a numeric function, DifferentialEvolution is used.

DifferentialEvolution has as one of its options "PenaltyFunction"  
which is:

function applied to constraints to penalize invalid points

That implies however that "invalid points" will be used during  
evaluation so the function has to make sense on such points to. That  
is why I used IntegerPart.


>
>>
>> We also will fact the problem of dealing with the zero vector since
>>
>>
>> LatticeReduce[{{0,0},{0,0}}]
>>
>> {}

>
>>
>> Finally, the method NelderMead does not seem to work well in this  
>> case, but if we run the code with the default Method setting we  
>> now get:
>
> Interesting observation. I have to test it with my problem

As I mentioned above: DifferentialEvolution seems to be the method  
most effective when dealing with integer problems, at lest accoriding  
to the documentation.


Andrzej Kozlowski


  • Prev by Date: Re: Showing Mathematica notebooks within Firefox browser (like Adobe PDF's)
  • Next by Date: "Substract one and add one" algorithm
  • Previous by thread: LatticeReduce problem
  • Next by thread: Re: LatticeReduce problem