eclib update
John Cremona
http://www.warwick.ac.uk/staff/J.E.Cremona/eclib-20071231.p1.spkg
This version, which builds on mabshoff's eclib-20071231.p0.spkg,
handles the interface with NTL's ZZ_p class better (using a cached
list of ZZ_pContext's for those who know NTL) which should certailny
be a lot more efficient, and might even solve the problems people had
trying to compile this with gcc-4.3 (which I do not have).
Since other parts of Sage use the ZZ_p class it might be worth using
what I did here (in src/procs/gf.{h,cc}) elsewhere too. I have a
global object of type map<ZZ,ZZ_pContext> consisting of an in
initially empty list of pairs [p,c] where p is a prime and c is a
ZZ_pContext which stores the internal NTL data for working mod p.
When I need to switch to a new modulus, instead of just calling
ZZ_p::init() each time (which was happening a lot of times for the
same p in programs such as mwrank), I look to see if that p has a
saved context and if so just restore it. If not, is do ZZ_p::init and
then save the context. So each prime only gets init'ed once.
It is possible that this will have solved other mysterious problems,
since the NTL documention (see http://www.shoup.net/ntl/doc/ZZ_p.txt)
says
"One should also not presume that things will work properly
if the modulus is changed, but its value happens to be the same---
one should restore the same "context", from either a ZZ_pBak
or a ZZ_pContext object."
Up to now I *had* been making such a presumption.
It is still true that this spkg will not build correctly in Sage 2.9.1
(or even 2.9.2) since there is a small change to the interface which
requires a similar small change to the wrapping code, but this has
been put off at least until after the AMS meeting. But it should
build fine as a stand-alone package.
John
--
John Cremona
mabshoff
On Jan 4, 12:55 pm, "John Cremona" <john.crem...@gmail.com> wrote:
Hi John,
> I have put an updated eclib athttp://www.warwick.ac.uk/staff/J.E.Cremona/eclib-20071231.p1.spkg
> This version, which builds on mabshoff's eclib-20071231.p0.spkg,
> handles the interface with NTL's ZZ_p class better (using a cached
> list of ZZ_pContext's for those who know NTL) which should certailny
> be a lot more efficient, and might even solve the problems people had
> trying to compile this with gcc-4.3 (which I do not have).
>
> Since other parts of Sage use the ZZ_p class it might be worth using
> what I did here (in src/procs/gf.{h,cc}) elsewhere too. I have a
> global object of type map<ZZ,ZZ_pContext> consisting of an in
> initially empty list of pairs [p,c] where p is a prime and c is a
> ZZ_pContext which stores the internal NTL data for working mod p.
> When I need to switch to a new modulus, instead of just calling
> ZZ_p::init() each time (which was happening a lot of times for the
> same p in programs such as mwrank), I look to see if that p has a
> saved context and if so just restore it. If not, is do ZZ_p::init and
> then save the context. So each prime only gets init'ed once.
>
> It is possible that this will have solved other mysterious problems,
>
> "One should also not presume that things will work properly
> if the modulus is changed, but its value happens to be the same---
> one should restore the same "context", from either a ZZ_pBak
> or a ZZ_pContext object."
>
> Up to now I *had* been making such a presumption.
>
> It is still true that this spkg will not build correctly in Sage 2.9.1
> (or even 2.9.2) since there is a small change to the interface which
> requires a similar small change to the wrapping code, but this has
> been put off at least until after the AMS meeting. But it should
> build fine as a stand-alone package.
>
the gcc 4.3 problems. I am hoping that somebody participating in the
coding sprint at the AMS meeting will find the time to fix the
interface issues.
> John
Cheers,
Michael
> --
> John Cremona