|
From: Bill H. <goo...@go...> - 2009-05-12 21:52:46
|
FLINT's trac system has been down for a long time. It relies on a server working, and every time it stops people "forget" how to restart it. I've tried and failed. However, if you post to the flint development list (in CC) that will suffice to let people know you are planning on working on this. Bill. 2009/5/12 David Roe <ro...@ma...>: > I will check with him. > > Do I get a login for Flint's trac from you or William? I may write an > analogue of mpz_remove for fmpz_t's (that's the main function that I use for > p-adics). > David > > On Tue, May 12, 2009 at 5:36 PM, Bill Hart <goo...@go...> > wrote: >> >> Hi David, >> >> Actually Gonzalo Tornaria wrote the montgomery code. I would imagine >> that there is always a gain. However maybe Gonzalo knows better. >> >> Benchmarking it would be the only way to be sure. >> >> Bill. >> >> 2009/5/12 David Roe <ro...@ma...>: >> > Hey Bill, >> > I'm writing code for p-adic polynomials in Sage right now, using >> > fmpz_poly_t's as the underlying data type. I'm wondering how >> > extensively to >> > use the fmpz_montgomery code in flint. I realize that I'm going to have >> > to >> > special case p=2 if I do. >> > >> > If I have an fmpz_montgomery_t around already, is fmpz_montgomery_mulmod >> > always at least as fast as fmpz_mulmod? For reasonably small moduli, is >> > there much of a gain? >> > >> > If I have to call fmpz_montgomery_init, do you have an idea of how many >> > mulmods or mods I need in order to make it worthwhile? >> > David >> > > > |