<?xml version="1.0" encoding="utf-8" ?> <!-- for emacs: -*- coding: utf-8 -*- -->
<!-- Apache may like this line in the file .htaccess: AddCharset utf-8 .html -->
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0 plus SVG 1.1//EN" "http://www.w3.org/2002/04/xhtml-math-svg/xhtml-math-svg-flat.dtd" >
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head><title>LLL(..., Strategy => ...) -- choose among different algorithms</title>
<link rel="stylesheet" type="text/css" href="../../../../Macaulay2/Style/doc.css"/>
</head>
<body>
<table class="buttons">
<tr>
<td><div><a href="___N__T__L.html">next</a> | <a href="___L__L__L_lp..._cm_sp__Change__Matrix_sp_eq_gt_sp..._rp.html">previous</a> | <a href="___N__T__L.html">forward</a> | <a href="___L__L__L_lp..._cm_sp__Change__Matrix_sp_eq_gt_sp..._rp.html">backward</a> | up | <a href="index.html">top</a> | <a href="master.html">index</a> | <a href="toc.html">toc</a> | <a href="http://www.math.uiuc.edu/Macaulay2/">Macaulay2 web site</a></div>
</td>
</tr>
</table>
<hr/>
<div><h1>LLL(..., Strategy => ...) -- choose among different algorithms</h1>
<div class="single"><h2>Synopsis</h2>
<ul><li><div class="list"><dl class="element"><dt class="heading">Usage: </dt><dd class="value"><div><tt>LLL(...,Strategy=>n)</tt></div>
</dd></dl>
</div>
</li>
<li><div class="single">Inputs:<ul><li><span>The strategy n can be one of the symbols or lists given below.</span></li>
</ul>
</div>
</li>
</ul>
</div>
<div class="single"><h2>Description</h2>
<div>There are several variants of the LLL reduction algorithm implemented. There are three all integer versions: <tt>NTL</tt>, <tt>CohenEngine</tt>, and <tt>CohenTopLevel</tt>. The NTL version (NTL is an excellent package written by Victor shoup) is generally the best, however, the top level version is written in the Macaulay2 language, and so is easily modifiable and can be used to understand the algorithm better. There are also a number of approximate LLL variants implemented in NTL. These use real numbers instead of exact integer arithmetic, and so are often much faster, but only provide approximate answers (i.e. the result might not be an LLL basis, only close to one). Much of the information here about NTL's algorithms comes directly from the NTL documentation (translated to be relevant here).<p/>
Here is the complete list of possible strategies:<ul><li>LLL(m, Strategy => NTL)</li>
<li>LLL(m, Strategy => CohenEngine)</li>
<li>LLL(m, Strategy => CohenTopLevel)</li>
<li><hr/>
</li>
<li>LLL(m, Strategy => RealFP)</li>
<li>LLL(m, Strategy => RealQP)</li>
<li>LLL(m, Strategy => RealXD)</li>
<li>LLL(m, Strategy => RealRR)</li>
<li><hr/>
</li>
<li>LLL(m, Strategy => {Givens,RealFP})</li>
<li>LLL(m, Strategy => {Givens,RealQP})</li>
<li>LLL(m, Strategy => {Givens,RealXD})</li>
<li>LLL(m, Strategy => {Givens,RealRR})</li>
<li><hr/>
</li>
<li>LLL(m, Strategy => {BKZ,RealFP})</li>
<li>LLL(m, Strategy => {BKZ,RealQP})</li>
<li>LLL(m, Strategy => {BKZ,RealQP1})</li>
<li>LLL(m, Strategy => {BKZ,RealXD})</li>
<li>LLL(m, Strategy => {BKZ,RealRR})</li>
<li><hr/>
</li>
<li>LLL(m, Strategy => {BKZ,Givens,RealFP})</li>
<li>LLL(m, Strategy => {BKZ,Givens,RealQP})</li>
<li>LLL(m, Strategy => {BKZ,Givens,RealQP1})</li>
<li>LLL(m, Strategy => {BKZ,Givens,RealXD})</li>
<li>LLL(m, Strategy => {BKZ,Givens,RealRR})</li>
</ul>
The first three are similar all-integer algorithms, basically the one which appears in H. Cohen's book. The rest of the algorithms are approximate variants, provided by Victor Shoup's NTL package. For these, there are three choices to be made: (1) the reduction condition, (2) the choice of orthogonalization strategy, and (3) the choice of precision.<h2>Reduction condition</h2>
<ul><li>default -- the classical LLL reduction condition</li>
<li>BKZ -- Block Korkin-Zolotarev reduction.This is slower, but yields a higher-quality basis, i.e., one with shorter vectors. For a description, see [C. P. Schnorr and M. Euchner, Proc. Fundamentals of Computation Theory, LNCS 529, pp. 68-85, 1991]. This basically generalizes the LLL reduction condition from blocks of size 2 to blocks of larger size.</li>
</ul>
<h2>Orthogonalization Strategy</h2>
<ul><li>default -- Classical Gramm-Schmidt Orthogonalization, This choice uses classical methods for computing the Gramm-Schmidt othogonalization. It is fast but prone to stability problems. This strategy was first proposed by Schnorr and Euchner in the paper mentioned above. The version implemented here is substantially different, improving both stability and performance.</li>
<li>Givens -- Givens Orthogonalization, This is a bit slower, but generally much more stable, and is really the preferred orthogonalization strategy. For a nice description of this, see Chapter 5 of [G. Golub and C. van Loan, Matrix Computations, 3rd edition, Johns Hopkins Univ. Press, 1996].</li>
</ul>
<h2>Precision</h2>
<ul><li>RealFP -- double</li>
<li>RealQP -- quad_float (quasi quadruple precision) useful when roundoff errors can cause problems</li>
<li>RealQP1 -- only availabel in the BKZ variant, uses double precision for the search phase of the BKZ reduction, and quad_float for the orthogonalization</li>
<li>RealXD -- xdouble (extended exponent doubles) useful when numbers get too big</li>
<li>RealRR -- RR (arbitrary precision floating point) useful for large precision and magnitudes</li>
</ul>
Generally speaking, the choice RealFP will be the fastest, but may be prone to roundoff errors and/or overflow.<h2>Putting it all together</h2>
This subsection comes directly from Victor Shoup's LLL documentation<p/>
I think it is safe to say that nobody really understands how the LLL algorithm works. The theoretical analyses are a long way from describing what "really" happens in practice. Choosing the best variant for a certain application ultimately is a matter of trial and error.<p/>
The first thing to try is <tt>Strategy => RealFP</tt>. It is the fastest of the routines, and is adequate for many applications.<p/>
If there are precision problems, you will most likely get a warning message, something like "warning--relaxing reduction". If there are overflow problems, you should get an error message saying that the numbers are too big.<p/>
If either of these happens, the next thing to try is <tt>Strategy=>{Givens,RealFP}</tt>, which uses the somewhat slower, but more stable, Givens rotations. This approach also has the nice property that the numbers remain smaller, so there is less chance of an overflow.<p/>
If you are still having precision problems try <tt>Strategy=>RealQP</tt> or <tt>Strategy=>{Givens,RealQP}</tt>, which use quadratic precision.<p/>
If you are still having overflow problems, try <tt>Strategy=>RealXD</tt> or <tt>Strategy=>{Givens,RealXD}</tt><p/>
I haven't yet come across a case where one *really* needs the extra precision available in the RealRR variants.<p/>
All of the above discussion applies to the <tt>BKZ</tt> variants as well. In addition, if you have a matrix with really big entries, you might try using <tt>Strategy=>{Givens,RealFP}</tt> or <tt>Strategy=>RealXD</tt> first to reduce the sizes of the numbers, before running one of the <tt>BKZ</tt> variants.<p/>
Also, one shouldn't rule out using the "all integer" LLL routines. For some highly structured matrices, this is not necessarily much worse than some of the floating point versions, and can under certain circumstances even be better.<table class="examples"><tr><td><pre>i1 : m1 = map(ZZ^50, ZZ^50, (j,i) -> (i+1)^8 * (j+1)^4 + i + j + 2);
50 50
o1 : Matrix ZZ <--- ZZ</pre>
</td></tr>
<tr><td><pre>i2 : m = syz m1;
50 47
o2 : Matrix ZZ <--- ZZ</pre>
</td></tr>
<tr><td><pre>i3 : time LLL m;
-- used 0.023997 seconds
50 47
o3 : Matrix ZZ <--- ZZ</pre>
</td></tr>
<tr><td><pre>i4 : time LLL(m, Strategy=>CohenEngine);
-- used 0.13298 seconds
50 47
o4 : Matrix ZZ <--- ZZ</pre>
</td></tr>
<tr><td><pre>i5 : time LLL(m, Strategy=>CohenTopLevel);
-- used 0.207969 seconds
50 47
o5 : Matrix ZZ <--- ZZ</pre>
</td></tr>
<tr><td><pre>i6 : time LLL(m, Strategy=>{Givens,RealFP});
-- used 0.029995 seconds
50 47
o6 : Matrix ZZ <--- ZZ</pre>
</td></tr>
<tr><td><pre>i7 : time LLL(m, Strategy=>{Givens,RealQP});
-- used 0.138979 seconds
50 47
o7 : Matrix ZZ <--- ZZ</pre>
</td></tr>
<tr><td><pre>i8 : time LLL(m, Strategy=>{Givens,RealXD});
-- used 0.162975 seconds
50 47
o8 : Matrix ZZ <--- ZZ</pre>
</td></tr>
<tr><td><pre>i9 : time LLL(m, Strategy=>{Givens,RealRR});
-- used 0.815876 seconds
50 47
o9 : Matrix ZZ <--- ZZ</pre>
</td></tr>
<tr><td><pre>i10 : time LLL(m, Strategy=>{BKZ,Givens,RealQP});
-- used 0.33295 seconds
50 47
o10 : Matrix ZZ <--- ZZ</pre>
</td></tr>
</table>
</div>
</div>
<h2>Further information</h2>
<ul><li><span>Default value: <a href="___N__T__L.html" title="use the all-integer LLL strategy from NTL library">NTL</a></span></li>
<li><span>Function: <span><a href="___L__L__L.html" title="compute an LLL basis">LLL</a> -- compute an LLL basis</span></span></li>
<li><span>Option name: <span><a href="../../Macaulay2Doc/html/___Strategy.html" title="name for an optional argument">Strategy</a> -- name for an optional argument</span></span></li>
</ul>
<div class="single"><h2>Caveat</h2>
<div>For most of the options, the columns do not need to be linearly independent. The strategies CohenEngine and CohenTopLevel currently require the columns to be linearly independent.</div>
</div>
<div class="single"><h2>See also</h2>
<ul><li><span><a href="index.html" title="lattice reduction (Lenstra-Lenstra-Lovasz bases)">LLLBases</a> -- lattice reduction (Lenstra-Lenstra-Lovasz bases)</span></li>
</ul>
</div>
</div>
</body>
</html>
