General:
========

* improve the use of free relations: currently we generate free relations
  up to the algebraic factor base bound (alim). We can do much better:

  (a) after the purge phase (removal of singletons), find all remaining
      primes on the algebraic side
  (b) determine those primes for which the algebraic polynomial completely
      splits into linear factors
  (c) add free relations for those primes

  In particular when using the lattice siever, all special-q's for which f(x)
  completely splits should appear in (b).

* portability: we should check improve portability on Win64, where
  long has 32 bits (http://technet.microsoft.com/en-us/library/bb496995.aspx).
  See http://gmplib.org/list-archives/gmp-discuss/2008-June/003243.html and
  the 3 possible models (most C programs in CADO-NFS assume LP64):
  * LP64 defines "int" as 32 bits and "long" as 64 bits.
  * LLP64 defines "int" and "long" as 32 bits, and an additional type
    (usually called "long long") as 64 bits.
  * ILP64 defines "int" and "long" as 64 bits.

* reintroduce the "skip" parameter: the idea is that we remove some columns
  corresponding to dense prime ideals before the linear algebra (or even
  before merge or purge), and we "recover" those ideals with "characters".
  Thus the matrix has smaller weight, and hopefully bwc will be faster.

Polyselect:
===========

* use the other definition of the E-value, see formula (5.8) page 87 of
  Murphy's thesis. Currently CADO-NFS uses the definition on page 99,
  where Murphy says that the former definition is more reliable.

Purge:
======

* in the first pass, we can identify all algebraic ideals corresponding to a
  given prime p, and even identify them to the ideal p on the rational side,
  to reduce the memory usage. Some singletons will not be identified in this
  first pass, but later passes (with fewer remaining relations) will remove
  them.

* For now, purge cannot handle relations generated by two non-linear
  polynomials. Moreover, purge rely on the fact that the first primes come from
  the rational side and the last from the algebraic side.

Sieve:
======

* An (a,b)-pair where the sieving leaves a value not exceeding the sieve
  report threshold on both the rational side and the algebraic side
  goes to the cofactorization phase. However, if on both sides the
  remaining sieve value is just a little below the respective threshold,
  then this (a,b)-pair has little chance of becoming a relation:
  since the lambda value is increased a little to account for rounding
  errors, one of the two cofactors may be too large, and even if they
  aren't, we know they're both pretty large so it's unlikely that both
  split completely into primes < lpb.
  We can add another threshold, a combined lambda
  clambda < alambda + rlambda
  and add the condition that the sum of remaining values after sieving
  must not exceed lpb^clambda.
  That should reduce the number of sieve survivors that don't become
  relations, thus reducing pressure on the cofactorization phase,
  without losing too many relations.

* take into account prime powers in las (the makefb command can do it,
  however this is currently disabled since las does not correctly deal with
  prime powers). An experiment made by Alexander Kruppa in October 2011 with
  the c59 shows that taking into account prime powers increases by 15% the
  number of relations found, and by 10% the yield per second.

* [idea from Alexander Kruppa, October 2011] run a sieve test to determine,
  for each pair (s,t) of bit-sizes of cofactors on the algebraic and rational
  sides, the probability p(s,t) that we find a relation. Then we run again the
  siever with input that file and a probability threshold p0. If p(s,t) < p0,
  then we don't run the cofactorization.

Linear algebra:
===============

* write some conversions routines from the CADO-NFS format to the msieve format
  and vice versa. From Jason Papadopoulos: "The cycle file and matrix file
  formats Msieve uses are described in the Readme.nfs document in the Msieve
  source."