[ANN] FLINT developers Workshop 4-12 May

[Bill Hart]

Hi all,

flint is a library for support of computations in Number Theory, which
includes highly optimised C routines for polynomial arithmetic and
linear algebra over numerous rings (and some integer arithmetic,
primality testing and factorisation). Flint is a component of Sage
(http://sagemath.org/) and is soon to become a component of a number
of other Open Source libraries. Please see http://flintlib.org/ for
details.

We are pleased to announce that there will be a FLINT Workshop at
Warwick University in Coventry, UK from May 4-12 (incl.). We have
funds to support visiting researchers of "established standing", i.e.
have a lectureship or equivalent or work in relevant industry which
has an interest in the research, to visit and collaborate. Other
participants are very welcome.

We will be working on the following topics

* LLL in flint
* polynomial factorisation in flint
* linear algebra in flint
* ball arithmetic in arb (a new library by Fredrik Johansson based on flint) [1]
* finite fields in flint
* C++ wrapper for flint (similar to NTL interface [2])
* algebraic number theory in flint
* integer factorisation in flint
* using flint to compute symmetric Hilbert modular forms
* Sage/flint interface, esp. Sage trac #14304 [3]
* Flint/Singular interface [4]

All of the main flint developers will be present, in addition to a
number of individuals from related Open Source projects who have
already expressed interest.

There will be no talks scheduled, but plenty of time to collaborate and/or code.

Please email me if you want to come, (whether we are able to fund you
or not) or if you wish to suggest additional topics for collaboration.

Best Wishes,

Bill.

[1] http://fredrikj.net/arb/
[2] http://trac.sagemath.org/sage_trac/ticket/14304
[3] http://shoup.net/ntl/
[4] http://www.singular.uni-kl.de/

[kcrisman]

Bill et al.,

Along these lines, I'm just curious about http://trac.sagemath.org/sage_trac/ticket/12173 upgrading FLINT in Sage...  Is enough of zn_poly (in particular, all of it?) to allow us to remove that spkg?  Since that code is more or less unmaintained, things like http://trac.sagemath.org/sage_trac/ticket/14098 (now resolved) or http://trac.sagemath.org/sage_trac/ticket/13947 become somewhat annoying.  David's webpage makes it clear that upstream is now canonical (for which I don't blame him at all, these things could be an albatross otherwise), but if we could connect the few remaining things in Sage that definitely depend on in to FLINT instead, that would be really nice.

- kcrisman

[Fredrik Johansson]

On Mar 20, 5:50 pm, kcrisman <kcris...@gmail.com> wrote:
> Bill et al.,
>
> Along these lines, I'm just curious

> abouthttp://trac.sagemath.org/sage_trac/ticket/12173upgrading FLINT in

> Sage...  Is enough of zn_poly (in particular, all of it?) to allow us to
> remove that spkg?  Since that code is more or less unmaintained, things
> likehttp://trac.sagemath.org/sage_trac/ticket/14098(now resolved)

> orhttp://trac.sagemath.org/sage_trac/ticket/13947become somewhat

> annoying.  David's webpage makes it clear that upstream is now canonical
> (for which I don't blame him at all, these things could be an albatross
> otherwise), but if we could connect the few remaining things in Sage that
> definitely depend on in to FLINT instead, that would be really nice.
>

As far as I know, flint2 covers all functionality of zn_poly (though
it's probably a bit slower in some cases). I don't really have an idea
how much code in Sage uses zn_poly and how difficult it would be to
change it, but it ought to be doable.

Fredrik

[kcrisman]

On Mar 21, 11:16 am, Fredrik Johansson <fredrik.johans...@gmail.com>
wrote:

> On Mar 20, 5:50 pm, kcrisman <kcris...@gmail.com> wrote:
>
> > Bill et al.,
>
> > Along these lines, I'm just curious

> > abouthttp://trac.sagemath.org/sage_trac/ticket/12173upgradingFLINT in

> > Sage...  Is enough of zn_poly (in particular, all of it?) to allow us to
> > remove that spkg?  Since that code is more or less unmaintained, things
> > likehttp://trac.sagemath.org/sage_trac/ticket/14098(nowresolved)
> > orhttp://trac.sagemath.org/sage_trac/ticket/13947becomesomewhat
> > annoying.  David's webpage makes it clear that upstream is now canonical
> > (for which I don't blame him at all, these things could be an albatross
> > otherwise), but if we could connect the few remaining things in Sage that
> > definitely depend on in to FLINT instead, that would be really nice.
>
> As far as I know, flint2 covers all functionality of zn_poly (though
> it's probably a bit slower in some cases). I don't really have an idea
> how much code in Sage uses zn_poly and how difficult it would be to
> change it, but it ought to be doable.
>

Sorry, I should have mentioned that Bill replied to me privately and
made it clear that there probably would be some loss of functionality
at the present time, at least in the sense of the zn_poly library
itself. I do think sage/schemes/hyperelliptic_curves/hypellfrob.pyx
and friends need zn_poly but perhaps those pieces are in flint2?
Since the most important ticket in question is not exactly a blocker
(just build zn_poly with one thread) I didn't pursue it. But
otherwise it might be nice to do, if someone knew how to do it;
zn_poly would always be able to stay a very well-supported optional
spkg.

[leif]

Me neither. It's still unclear (to me at least) whether the bug is just
in zn_poly's test suite (and/or its tuning), or in the zn_poly library.

Even if just tuning was broken, there would IMHO be some assert()s
missing in the library. (The test suite is compiled with assertions
enabled.)


-leif

> But
> otherwise it might be nice to do, if someone knew how to do it;
> zn_poly would always be able to stay a very well-supported optional
> spkg.
>

--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail