1 |
> On 3/04/2015, at 20:52, Thomas Kahle <tomka@g.o> wrote: |
2 |
> |
3 |
> Bump request was open for a while already: |
4 |
> https://bugs.gentoo.org/show_bug.cgi?id=542682 |
5 |
> I bumped it yesterday, is the ntl-62 compat patch essential? |
6 |
|
7 |
Well ntl 6.2.x only live in the sage-on-gentoo tree but I would imagine |
8 |
it helps with later version. My pull request has actually been merged |
9 |
in master before the 2.4.5 release but it seems to only live in master |
10 |
for future flint 2.5: |
11 |
https://github.com/wbhart/flint2/pull/95 |
12 |
|
13 |
> Patrick reported a test failure that I cannot reproduce yet: |
14 |
> https://bugs.gentoo.org/show_bug.cgi?id=545378 |
15 |
> Do you know anything about it? |
16 |
> |
17 |
|
18 |
No. I am running tests again to see if it is brought by a recent change. |
19 |
I’ll see if I can track to something. |
20 |
|
21 |
François |
22 |
|
23 |
|
24 |
> On 03/04/15 00:53, François Bissey wrote: |
25 |
>> Speaking of flint would you mind importing 2.4.5 from the sage-on-gentoo |
26 |
>> overlay to the main tree. I should have opened a bump request last month |
27 |
>> when it was released. |
28 |
>> |
29 |
>> François |
30 |
>> |
31 |
>>> On 3/04/2015, at 01:33, Thomas Kahle <tomka@g.o> wrote: |
32 |
>>> |
33 |
>>> Bumped, but now flint became incompatible: |
34 |
>>> |
35 |
>>> https://github.com/wbhart/flint2/issues/131 |
36 |
>>> |
37 |
>>> On 28/03/15 20:54, François Bissey wrote: |
38 |
>>>> And Victor just announce ntl 9.0 on sage-devel: |
39 |
>>>> |
40 |
>>>> With much trepidation, I have introduced a (hopefully minor) |
41 |
>>>> backward incompatibility into NTL. |
42 |
>>>> |
43 |
>>>> The interface to the single-precision modular arithmetic |
44 |
>>>> routines has been modified slightly. |
45 |
>>>> This interface change allows for more flexible and more |
46 |
>>>> efficient implementation of these routines, |
47 |
>>>> which play a crucial role at many levels in NTL. |
48 |
>>>> |
49 |
>>>> Basically, these changes to the interface abstract away |
50 |
>>>> some implementation details that arguably should never been there |
51 |
>>>> in the first place. |
52 |
>>>> By coding to the new interface, NTL clients will be able to |
53 |
>>>> benefit from the current and future improvements. |
54 |
>>>> |
55 |
>>>> In particular, on 64-bit x86/GCC platforms, single precision |
56 |
>>>> moduli can now be up to 60 bits, rather than 50 bits. |
57 |
>>>> While some operations may in fact be a little slower, the most important |
58 |
>>>> ones (like MulModPrecon) should not be. |
59 |
>>>> Using larger moduli speeds up a number of things, like ZZ_pX |
60 |
>>>> arithmetic, as fewer primes need to be used in Chinese Remaindering steps. |
61 |
>>>> Other applications benefit from larger moduli as well. |
62 |
>>>> |
63 |
>>>> It is expected that most NTL clients will not be affected at all. |
64 |
>>>> Moreover, any code that needs to be updated will be detected |
65 |
>>>> by the compiler, and the updates should be simple and mechanical. |
66 |
>>>> There is also a configuration flag that will enable the legacy |
67 |
>>>> interface (although this is not recommended practice). |
68 |
>>>> |
69 |
>>>> For more, go to http://www.shoup.net/ntl |
70 |
>>>> |
71 |
>>>> |
72 |
>>> |
73 |
>>> -- |
74 |
>>> Thomas Kahle |
75 |
>>> http://dev.gentoo.org/~tomka/ |
76 |
>>> |
77 |
>> |
78 |
>> |
79 |
> |
80 |
> -- |
81 |
> Thomas Kahle |
82 |
> http://dev.gentoo.org/~tomka/ |
83 |
> |