The basic BKZ algorithm can be implemented in about 60 pretty readable lines of Python code (cf. simple_bkz.py).
For a quick tour of the library, you can check out the tutorial.
How to cite
@unpublished{fplll,
author = {The {FPyLLL} development team},
title = {{fpylll}, lattice reduction for {Python}, {Version}: 0.5.6},
year = 2021,
note = {Available at \url{https://github.com/fplll/fplll}},
url = {https://github.com/fplll/fplll}
}
Requirements
fpylll relies on the following C/C++ libraries:
GMP or MPIR for arbitrary precision integer arithmetic.
MPFR for arbitrary precision floating point arithmetic.
QD for double double and quad double arithmetic (optional).
Numpy for numerical computations (e.g. with Gram-Schmidt values)
Online
fpylll ships with Sage. Thus, it is available via SageMathCell and CoCalc (select a Jupyter notebook with a Sage kernel). You can also fire up a dply.co virtual server with the latest fpylll/fplll preinstalled (it takes perhaps 15 minutes until everything is compiled).
Getting Started
Note: fpylll is also available via PyPI and Conda-Forge for Conda. In what follows, we explain manual installation.
We recommend virtualenv for isolating Python build environments and virtualenvwrapper to manage virtual environments.
We indicate active virtualenvs by the prefix (fpylll).
Some OSX users report that they required export CXXFLAGS="-stdlib=libc++-mmacosx-version-min=10.7" and export CXX=clang++ (after installing a recent clang with brew) since the default GCC installed by Apple does not have full C++11 support.
Some OSX users report that they required export CXXFLAGS="-stdlib=libc++-mmacosx-version-min=10.7" and export CXX=clang++ (after installing a recent clang with brew) since the default GCC installed by Apple does not have full C++11 support.
fpylll supports parallelisation on multiple cores. For all C++ support to drop the GIL is enabled, allowing the use of threads to parallelise. Fplll is thread safe as long as each thread works on a separate object such as IntegerMatrix or MatGSO. Also, fpylll does not actually drop the GIL in all calls to C++ functions yet. In many scenarios using multiprocessing, which sidesteps the GIL and thread safety issues by using processes instead of threads, will be the better choice.
The example below calls LLL.reduction on 128 matrices of dimension 30 on four worker processes.
System Message: WARNING/2 (README.rst, line 267)
Cannot analyze code. Pygments package not found.
.. code-block:: python
from fpylll import IntegerMatrix, LLL
from multiprocessing import Pool
d, workers, tasks = 30, 4, 128
def run_it(p, f, A, prefix=""):
"""Print status during parallel execution."""
import sys
r = []
for i, retval in enumerate(p.imap_unordered(f, A, 1)):
r.append(retval)
sys.stderr.write('\r{0} done: {1:.2%}'.format(prefix, float(i)/len(A)))
sys.stderr.flush()
sys.stderr.write('\r{0} done {1:.2%}\n'.format(prefix, float(i+1)/len(A)))
return r
A = [IntegerMatrix.random(d, "uniform", bits=30) for _ in range(tasks)]
A = run_it(Pool(workers), LLL.reduction, A)
To test threading simply replace the line from multiprocessing import Pool with from multiprocessing.pool import ThreadPool as Pool. For calling BKZ.reduction this way, which expects a second parameter with options, using functools.partial is a good choice.
Contributing
fpylll welcomes contributions, cf. the list of open issues. To contribute, clone this repository, commit your code on a separate branch and send a pull request. Please write tests for your code. You can run them by calling:
$ (fpylll) PY_IGNORE_IMPORTMISMATCH=1 py.test
from the top-level directory which runs all tests in tests/test_*.py. We run flake8 on every commit automatically, In particular, we run: