Grand unification

[Fredrik Johansson]

Hi all,

With Bill soon stepping down as maintainer, I propose merging Antic into Flint. Antic is not too large, fits quite well with core functionality of Flint, and should be easier to maintain as part of Flint than as a standalone library.

I also want to mention the possibility of merging Arb back into Flint. I don't know if this is actually a good idea, and even if I were to lean in favor, I'd certainly not push for it unless there is a consensus in the community. These are just my thoughts on the matter.

Pros:

+ Arb frequently uses cutting-edge Flint features and makes heavy use of Flint internals. A merge would reduce development friction and avoid issues with versions being out of sync.

+ There is the possibility to use Arb in Flint itself. Various functions in Flint currently have much faster Arb counterparts, or could be sped up using Arb implementations: special functions like Bernoulli numbers and partition numbers, finite field extension construction (Gauss period method), various utility functions like fmpz_flog/fmpz_clog, potentially the LLL.

+ Most downstream projects (Nemo, Sage, Python-Flint, ...) already depend on both Flint and Arb, so this would just simplify downstream dependency management.

+ Miscellaneous helper functionality in Arb (fmpz_extras, dirichlet, dlog, bool_mat) would fit quite well in Flint.

+ Potentially a somewhat smaller maintenance burden for me personally managing one large project instead of two large projects.

+ Brand consolidation. It may be easier to "sell" one well-established large library than a bunch of small libraries.

+ Potentially easier to maintain an active developer community, for the same reason.

Cons:

- Initial downstream breakage.

- So far Arb has been on a much faster release cycle than Flint. If I can manage it, it would be good to have more frequent releases Flint rather than less frequent releases of Arb!

- Loss of brand recognition for Arb. [For the record, I don't think this is a huge deal. In fact, it just annoys me when people occasionally suggest making Arb *less* dependent on Flint (e.g. having Arb not depend on Flint). Arb without Flint would be like pineapple without the pizza!]

- Loss of brand recognition for Flint. [This seems less likely, but just to be clear; I don't want to give the impression that Flint should evolve mainly to serve my own Arb-related interests.]

- Harder for users/developers specifically interested in Arb to navigate the Flint codebase, documentation and issue tracker, and likewise for Flint users/developers disinterested in Arb.

- Flint is already huge. A larger library takes longer to build and test. A case can be made for the opposite move: splitting Flint into smaller pieces (for example, leaving Flint focused on integers/rationals and spinning off p-adics and finite fields). The size problem could be mitigated somewhat with anti-bloat measures that would be a good idea anyway (using more generics; cleaning up header files; speeding up test code). (BTW, Flint's root directory is also a mess; it could be a good idea to move headers to /include/, modules to /src/, putting the C++ wrapper in its own location, and restructuring the utility modules.)

- Potential loss of commit history and issue tracker, depending on how a merge is done.

- If it turns out to be a bad idea, could be hard to undo (considering further downstream breakage and confusion).

The same pros/cons can be discussed for Calcium.

Fredrik

[Jeffrey Sarnoff]

If I were in your position, after so many hours bringing Arb into high regard I would avoid steps that may, over time, erode other's awareness of Arb's desirability.

--

---
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/CAJdUXTKmGGNqW8PNz3LUe9DZc_s4rpCe%3DStAagdPXYsyL-ydSA%40mail.gmail.com.

[dei...@gmail.com]

I have no objections to merging antic, and would lobby for at least fmpz_mpoly_q and utils_flint from calcium to be moved into flint (I'd want these moved regardless of anything else being moved (I don't think that they have any dependence on the rest of calcium or on antic)).  

As far as merging arb, it would make my life slightly easier (one fewer library to compile), but I have no strong feelings.

[Albin Ahlbäck]

I have no objections to this either. I think this is a good idea.

Albin

> --
>
> ---
> 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

> <mailto:flint-devel...@googlegroups.com>.

> To view this discussion on the web, visit

> https://groups.google.com/d/msgid/flint-devel/ec91d8de-eb8f-4f8f-9d11-17b5fd57d4b7n%40googlegroups.com
> <https://groups.google.com/d/msgid/flint-devel/ec91d8de-eb8f-4f8f-9d11-17b5fd57d4b7n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[fieker]

While I think this is a good idea, maybe its also time to look at antic
- the parts we are actively using are arithmetic in number fields
- there is also a large part of quadratic fields and quadratic forms
we haven't used it in ages and maybe that should stay seperate?

Claus

> --
>
> ---
> 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/CAJdUXTKmGGNqW8PNz3LUe9DZc_s4rpCe%3DStAagdPXYsyL-ydSA%40mail.gmail.com.

[Stephen Crowley]

My vote would be for them to stay seperate and just have flint make available whatever' internal' functions that are being used.

arb4j is coming along well, integration now works (except for heap which is being debugged)

// this code calculates the lemnisate constant

 public static void testIntegration2() throws NotDifferentiableException, LackOfConvergenceException
  {
    int             prec     = 256;

    Lemniscate      f        = new Lemniscate();
    ComplexFunction df       =new LemniscateDerivative();

    ComplexFunction absdf    = df.abs();

    Complex         integral = new Complex();
    Magnitude       absErr   = new Magnitude();

    Complex         a        = new Complex();
    Complex         b        = new Complex();
    Real            breal    = b.getReal();
    breal.pi(prec).div(2, prec, breal);

    IntegrationOptions opts = new IntegrationOptions();
    //opts.verbose = true;
    Complex abslprimeonehalf = absdf.evaluate(Constants.COMPLEX_HALF, 1, 128, new Complex());
    System.out.format("|l'(1/2)|=%s\n", abslprimeonehalf);
    opts.useHeap = false;
    absdf.integrate(a, b, 128, absErr, opts, prec, integral);
    integral.printPrecision = true;
    System.out.format("int(|l'(x)|,x=%s..%s) is %s\n", a.toFixedString(), b.toFixedString(), integral);
    assertTrue( integral.getReal().getRad().doubleValue() <= 1e-20 );
    assertEquals(2.62205755429211981046483958989111941368275495,
                 integral.getReal().getMid().doubleValue(),
                 integral.getReal().getRad().doubleValue());
  }