> On 3/04/2015, at 20:52, Thomas Kahle <[email protected]> wrote: > > Bump request was open for a while already: > https://bugs.gentoo.org/show_bug.cgi?id=542682 > I bumped it yesterday, is the ntl-62 compat patch essential?
Well ntl 6.2.x only live in the sage-on-gentoo tree but I would imagine it helps with later version. My pull request has actually been merged in master before the 2.4.5 release but it seems to only live in master for future flint 2.5: https://github.com/wbhart/flint2/pull/95 > Patrick reported a test failure that I cannot reproduce yet: > https://bugs.gentoo.org/show_bug.cgi?id=545378 > Do you know anything about it? > No. I am running tests again to see if it is brought by a recent change. I’ll see if I can track to something. François > On 03/04/15 00:53, François Bissey wrote: >> Speaking of flint would you mind importing 2.4.5 from the sage-on-gentoo >> overlay to the main tree. I should have opened a bump request last month >> when it was released. >> >> François >> >>> On 3/04/2015, at 01:33, Thomas Kahle <[email protected]> wrote: >>> >>> Bumped, but now flint became incompatible: >>> >>> https://github.com/wbhart/flint2/issues/131 >>> >>> On 28/03/15 20:54, François Bissey wrote: >>>> And Victor just announce ntl 9.0 on sage-devel: >>>> >>>> With much trepidation, I have introduced a (hopefully minor) >>>> backward incompatibility into NTL. >>>> >>>> The interface to the single-precision modular arithmetic >>>> routines has been modified slightly. >>>> This interface change allows for more flexible and more >>>> efficient implementation of these routines, >>>> which play a crucial role at many levels in NTL. >>>> >>>> Basically, these changes to the interface abstract away >>>> some implementation details that arguably should never been there >>>> in the first place. >>>> By coding to the new interface, NTL clients will be able to >>>> benefit from the current and future improvements. >>>> >>>> In particular, on 64-bit x86/GCC platforms, single precision >>>> moduli can now be up to 60 bits, rather than 50 bits. >>>> While some operations may in fact be a little slower, the most important >>>> ones (like MulModPrecon) should not be. >>>> Using larger moduli speeds up a number of things, like ZZ_pX >>>> arithmetic, as fewer primes need to be used in Chinese Remaindering steps. >>>> Other applications benefit from larger moduli as well. >>>> >>>> It is expected that most NTL clients will not be affected at all. >>>> Moreover, any code that needs to be updated will be detected >>>> by the compiler, and the updates should be simple and mechanical. >>>> There is also a configuration flag that will enable the legacy >>>> interface (although this is not recommended practice). >>>> >>>> For more, go to http://www.shoup.net/ntl >>>> >>>> >>> >>> -- >>> Thomas Kahle >>> http://dev.gentoo.org/~tomka/ >>> >> >> > > -- > Thomas Kahle > http://dev.gentoo.org/~tomka/ >
