A success story!

[John Cremona]

Dear FLINT-dev,

I have just converted my code for computing Bianchi modular forms (https://github.com/JohnCremona/bianchi-progs) to use FLINT 3 for its base integer type.  This is a very minimal use of FLINT.  Bianchi-progs builds on my eclib library, defining its own classes for dealing with imaginary quadratic integers, field elements, ideals -- and modular symbols.  Originally the base type for the quadratic integers was long int, which works fine until they overflow (and the code has a lot of assert statements to catch when that happens. Then I rewrote it so that (via a complile-time switch) it could use NTL's ZZ type -- this made sense as eclib uses these all over the place.  That works well but is very very much slower.

Last week I wrote my own little C++ wrapper around your fmpz_t -- just to provide the function I need, it's only 142 lines of header (mostly inline fcuntions calling a flint function) plus 120 lines for a few longer function implementations.  Now bianchi-progs uses this as its base type by default.  And while that is slower than using long ints, it is *very* much faster than using ZZ.  (I don't exactly know why -- NTL's ZZ is basically a C++ wrapper around gmp integers).

My test suite in bianchi-progs is designed to work even with long ints (it only runs on inputs which do not overflow), and the timings on a laptop are as follows:

long:  4m 24s

ZZ:    78m 25s

fmpz: 15m 47s

Thanks!

You may wonder why I haven't been using FLINT for years.  Well, eclib goes back a long way, longer than FLINT's first release, and I started using NTL very early on.  And I write in C++ rather than C, so I liked the fact that NTL is C++.  I never got around to trying out FLINT2's C++ wrappings -- is that project still alive, and will it be updated to work with FLINT3?  I found it on github (but Google finds https://flintlib.org/doc/flintxx.html which no longer exists).  There's a case to be made for converting all of eclib to use FLINT instead of NTL, but that would be a lot of work. (For the record, the components of NTL used in eclib are: ZZ and polynomials and matrices over ZZ including factoring in ZZ[X];  integers mod p, polynomials and matrices over these; RR (reals) over which I build my own CC; matrices over RR (just for small determinants).

Looking at this the other way round, if I converted all my code for elliptic curves over Q to use FLINT, you could consider that as contributing a library of elliptic curve functions to FLINT.  That would be a nice project for somebody...else!

John

[Edgar Costa]

Hi John,

Nicely done!

> I don't exactly know why -- NTL's ZZ is basically a C++ wrapper around gmp integers

I have not put time into this, but I had the idea that ZZ was more than a thin wrapper of gmp.
If so, I would expect it to be about 4 times slower than long, instead of almost 18 times.

flinxx is not dead!

It got forked out of the main repo and is now available here: https://github.com/flintlib/flintxx
Sadly, it is not really alive, as it is not in a usable state.

I hope to have some time to work on it over the winter, at least to get some minimalistic version of it running, as I use many of its features, in particular for templating in C++.

Cheers,

Edgar

--

---
You received this message because you are subscribed to the Google Groups "flint-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flint-devel...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/flint-devel/CAD0p0K4bWGQYvmT24WKH9Q5OCz9Vv7%2BJ0CR-L%3DLYeZo2761EjA%40mail.gmail.com.

[Oscar Benjamin]

On Tue, 28 Nov 2023 at 14:28, John Cremona <john.c...@gmail.com> wrote:
>
> Last week I wrote my own little C++ wrapper around your fmpz_t -- just to provide the function I need, it's only 142 lines of header (mostly inline fcuntions calling a flint function) plus 120 lines for a few longer function implementations. Now bianchi-progs uses this as its base type by default. And while that is slower than using long ints, it is *very* much faster than using ZZ. (I don't exactly know why -- NTL's ZZ is basically a C++ wrapper around gmp integers).
>
> My test suite in bianchi-progs is designed to work even with long ints (it only runs on inputs which do not overflow), and the timings on a laptop are as follows:
>
> long: 4m 24s
> ZZ: 78m 25s
> fmpz: 15m 47s

Does NTL's ZZ do anything special to handle small integers or does it
just use mpz always?

Flint's fmpz_t represents small integers inline:
https://github.com/flintlib/flint/blob/15d08d2db6b8d9fc13fdc57e960a23e33f9bf20e/src/fmpz.h#L29-L40

--
Oscar

[Fredrik Johansson]

Hi John,

On Tue, Nov 28, 2023 at 3:28 PM John Cremona <john.c...@gmail.com> wrote:

Dear FLINT-dev,

Last week I wrote my own little C++ wrapper around your fmpz_t -- just to provide the function I need, it's only 142 lines of header (mostly inline fcuntions calling a flint function) plus 120 lines for a few longer function implementations.  Now bianchi-progs uses this as its base type by default.  And while that is slower than using long ints, it is *very* much faster than using ZZ.  (I don't exactly know why -- NTL's ZZ is basically a C++ wrapper around gmp integers).

Thanks for sharing these nice results!

We ought to mention eclib on https://flintlib.org/applications.html, and LMFDB too by the way.

Looking at this the other way round, if I converted all my code for elliptic curves over Q to use FLINT, you could consider that as contributing a library of elliptic curve functions to FLINT.  That would be a nice project for somebody...else!

Yes, that would be a welcome contribution from somebody else :-)

Fredrik

[Bill Hart]

I could have sworn there was a mention of eclib on our links page:

https://flintlib.org/links.html

But I don't see it there at present. Maybe it was absent because it
only used a special hmod implementation rather than standard Flint.
But yes, I second that John's project absolutely should be featured on
the new applications page!

LMFDB is less clear to me. Does it use Flint in any Flint specific
way, or just via Sage/eclib. Of course it would be a great thing for
Flint to be able to say it was used in some critical way for LMFDB! I
think there should be a very clear case for including it, otherwise it
looks like trying to take credit for something Flint didn't have much
to do with directly.

Bill.

> --
>
> ---
> You received this message because you are subscribed to the Google Groups "flint-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to flint-devel...@googlegroups.com.

> To view this discussion on the web, visit https://groups.google.com/d/msgid/flint-devel/CAJdUXTLx_qDTQZxAKfT%2BA_UvY4TTe6otJZmpfNqYpHuwf%3DTMbA%40mail.gmail.com.

[Fredrik Johansson]

On Thu, Dec 7, 2023 at 9:56 AM 'Bill Hart' via flint-devel <flint...@googlegroups.com> wrote:

I could have sworn there was a mention of eclib on our links page:

https://flintlib.org/links.html

But I don't see it there at present. Maybe it was absent because it
only used a special hmod implementation rather than standard Flint.
But yes, I second that John's project absolutely should be featured on
the new applications page!

LMFDB is less clear to me. Does it use Flint in any Flint specific
way, or just via Sage/eclib. Of course it would be a great thing for
Flint to be able to say it was used in some critical way for LMFDB! I
think there should be a very clear case for including it, otherwise it
looks like trying to take credit for something Flint didn't have much
to do with directly.

For sure Arb has been used to compute some of the numerical data in the LMFDB, and this is mentioned on https://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/Source.

Fredrik

[Bill Hart]

Excellent!

> --
>
> ---
> You received this message because you are subscribed to the Google Groups "flint-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to flint-devel...@googlegroups.com.

> To view this discussion on the web, visit https://groups.google.com/d/msgid/flint-devel/CAJdUXTJ5h2nkbNpa09P0ZxedNXec66GWPw7EJMPMNDLTJAFsrQ%40mail.gmail.com.

[John Cremona]

I'm very sorry not have replied to any of these nice replies, but (as  noted on another thread) I had my preferences set up to "no email" which -- strangely perhaps -- means "no email, evn for replies to me about posts I have made".  ANyway, I have turned on all emails.

About eclib:  yes it used to use the special version of flint+hmod_mat, but now -- thanks to some help from Fredrik -- it uses a standard flint 3 (but can also still work with flint 2).  My Bianchi code does depend on eclib, buts use of flint for integer and rational types (and some integer matrix stuff) is entirely independent of that.  One day it would be good to move over some or all of eclib to use flint, but that would be quite a bit of work.

My C++ wrapper fmpz and fmpq was not hard to write, but I only did what I needed and it is a lot less clever than the old C++ flint version.  ANyone interested can look at https://github.com/JohnCremona/bianchi-progs, specifically (in the top directory) at int.h/int.cc, rat.h (there's no rat.cc, all was possible inline).

[Cyclopropinion]

Since these messages are already a bit ago... has there been any stuff done in relation to a C++ wrapper?

And what are the plans for it?

Cyclopropinon