Hi,
On Thu, Aug 23, 2012 at 4:57 AM, spyros wrote:
> I have seen that the following versions exist:
> NTL-LLL, fp-LLL heuristic, fp-LLL fast, fp-LLL wrapper
>
> I still don't know to which algorithms the heuristic, fast and wrapper
> packages
> correspond to...
fplll is an external library that
Thank you all for your replies!
I have seen that the following versions exist:
NTL-LLL, fp-LLL heuristic, fp-LLL fast, fp-LLL wrapper
I still don't know to which algorithms the heuristic, fast and wrapper
packages
correspond to...
Would it be interesting to develop the following variants?
> 1)
I've added this into Trac as: http://trac.sagemath.org/sage_trac/ticket/10544
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google
For more on what NTL does, the documentation is quite good but
otherwise try asking Victor Shoup directly. I have done that in the
past and he has been helpful.
John
On 9/22/07, Martin Albrecht <[EMAIL PROTECTED]> wrote:
>
> > (first) try the FP variants of NTL's LLL first (I overlooked those b
Check out Matrix_integer_dense.lllgram, e.g.
EXAMPLES:
sage: M = Matrix(ZZ, 2, 2, [5,3,3,2]) ; M
[5 3]
[3 2]
sage: U = M.lllgram(); U
[-1 1]
[ 1 -2]
sage: U.transpose() * M * U
[1 0]
> (first) try the FP variants of NTL's LLL first (I overlooked those before)
> (then) try Damien's fast.c implementation, also the proved version seems
> interesting, given the discussions on this list.
So, after I understood a bit better what makes LLL algorithms fast, here is
what I came up wi
qflllgram is the gp function I use. It takes as input the gram matrix
and outputs the unimodular transform.
John
On 9/21/07, Martin Albrecht <[EMAIL PROTECTED]> wrote:
>
> > > (first) try the FP variants of NTL's LLL first (I overlooked those
> > > before)
> >
> > These use real arithmetic "int
> I hope somebody (e.g., Martin?) can build Damien's code and
> do some benchmarks very soon.
Right now I am wrapping NTL's FP variants. The reason NTL was beaten so badly
is because MAGMA uses FP variants while NLT's LLL uses exact arithmetic.
However, MAGMA can do FP by default, because they
On 9/21/07, David Kohel <[EMAIL PROTECTED]> wrote:
> Since LLL and LLLGram in Magma V2.13 are written by Damien Stehle,
> using his asymptotically better algorithm. The previous version was
> not
> even mathematically correct (adhoc "improvements" or post-processing
> could destroy the LLL reduct
> > (first) try the FP variants of NTL's LLL first (I overlooked those
> > before)
>
> These use real arithmetic "internally", I think, but do not alow real
> input data as in my previous posting.
Yes, it seems so. I am not very familiar with GP/Pari, which function
implements what you want (gf
On 9/21/07, Martin Albrecht <[EMAIL PROTECTED]> wrote:
>
> On Friday 21 September 2007, David Kohel wrote:
> > Since LLL and LLLGram in Magma V2.13 are written by Damien Stehle,
> > using his asymptotically better algorithm. The previous version was
> > not
> > even mathematically correct (adhoc
On Friday 21 September 2007, David Kohel wrote:
> Since LLL and LLLGram in Magma V2.13 are written by Damien Stehle,
> using his asymptotically better algorithm. The previous version was
> not
> even mathematically correct (adhoc "improvements" or post-processing
> could destroy the LLL reduction
Since LLL and LLLGram in Magma V2.13 are written by Damien Stehle,
using his asymptotically better algorithm. The previous version was
not
even mathematically correct (adhoc "improvements" or post-processing
could destroy the LLL reduction condition).
Damien provides C code under GPL and can be
Implementing LLL well is a black art. I don't know enough to know
why the Magma one is so much better, but at least part of the reason
may be that the experts in LLL are using Magma for their development
work. Hence, once everyone in te world uses Sage, ...
Thanks for wrapping NTL's LLL. But
14 matches
Mail list logo
