There's quite a bit of work required to add files to MPIR on the *nix side. We also need some tests, which are not trivial here.
Anyway, as I say, I'm only merging patches for MPIR nowadays. I have hundreds of other things I need to do. I can't spend a month a year working on MPIR any more. On 23 January 2018 at 23:50, Brian Gladman <b...@gladman.plus.com> wrote: > On 23/01/2018 21:20, 'Bill Hart' via mpir-devel wrote: > > > > > > On 23 January 2018 at 22:13, Brian Gladman <b...@gladman.plus.com > > <mailto:b...@gladman.plus.com>> wrote: > > > > On 23/01/2018 20:00, 'Bill Hart' via mpir-devel wrote: > > > Hi Brian, > > > > > > I believe the problem is that our LLL code actually relies on a 64 > bit > > > exponent on Windows 64 (in practice, not just in theory), but GMP > (or > > > the compatibility function) only returns a 32 bit one. > > > > Ah, OK. So basically FLINT won't work on Windows x64 because longs > are > > 32-bits and FLINT expects longs to be 64-bits. > > > > So FLINT on Windows x64 won't work at all with current versions of > GMP > > since longs are 32-bits. And it won't work with MPIR 3 because we > have a > > function that uses 32 bit longs in its interface. > > > > But could we not have a 'compatibility define' in MPIR that makes the > > function work for 64-bit longs when needed? > > > > > > I guess that's an option. It won't fix the GMP issue for us either way. > > > > The problem of course is that an mpz (and hence an fmpz) can be 2^31 > > words, not bits. Therefore the number of bits in such an exponent can be > > larger than 2^32. > > > > Any solution requires non-trivial work, anyway. And unfortunately I have > > no time for such things these days. I can only merge patches into MPIR. > > That's all I have time for. The community is suppose to be taking over > > the job of handling releases, etc. But so far there haven't been any > > volunteers. > > At a code level the changes needed to fix this are not large if we do it > by adding two functions in MPIR in parallel with the existing ones - say > mpz_get_d_2exp_si() and mpf_get_d_2exp_si(). This would need changes in > at most four lines in FLINT and the work in MPIR is not large (I would > be happy to do it). > > But I do understand the wider cost in doing releases etc. Nevertheless > it seems a pity to give up on FLINT on Windows 64 when an MPIR based fix > looks to be feasible. > > Brian > > -- > You received this message because you are subscribed to the Google Groups > "mpir-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to mpir-devel+unsubscr...@googlegroups.com. > To post to this group, send email to mpir-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/mpir-devel. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at https://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
