Use FLINT ball arithmetic for special functions

[d-torrance]

We add support for FLINT's real and complex ball types to the interpreter. (Prior to FLINT 3, they were available in the Arb library, so we'll need to link against it in older systems.) Eventually, it would be great if these were available at top level, maybe even as coefficients of polynomials. But for right now, we just use them to bolster our support of special functions.

For example, many of our special functions now only take real arguments. But with FLINT, we can support complex and real interval arguments, as well. For example:

Before

i1 : zeta(1/2 + ii * 14.134725141734695)
stdio:1:1:(3): error: expected a real number

After

i1 : zeta(1/2 + ii * 14.134725141734695)

o1 = -1.04800845464933e-16+6.5803236815108e-16*ii

o1 : CC (of precision 53)

We also move several special functions that were previously handled by Boost Math over to FLINT. There are two (inverseRegularizedBeta and inverseRegularizedGamma -- both useful for computing quantiles of important probability distributions) that don't appear to be available in FLINT, however, so we aren't able to get rid of Boost Math entirely.

This is a draft for now until I get the cmake build working and update the tests and documentation.

[d-torrance]

I'm going to backport FLINT 3 for the PPA so we don't need to build it for all the Ubuntu GitHub builds. Hopefully, this fixes the weird "element not invertible" errors we're getting again (see also #2973 (comment)).

[mahrud]

That may be useful for some people, though alternatively once #3288 is working we don't need to use 22.04 for github builds.

[d-torrance]

The "element not invertible" errors are still happening with the PPA FLINT 3 package...

[mahrud]

The problem here was that ubuntu's flint was too old, and putting the newer version was incompatible with factory, right? Did you try putting newer flint together with a newer factory (and possibly normaliz) on PPA? Those are the only libraries that we use and depend on flint.

[d-torrance]

Yes, that was the problem. I haven't tried backporting the others to Ubuntu 22.04 since I figured it would be easier to just wait for #3288.

[mahrud]

I don't know when that might happen -- I don't have a macos and I don't think Mike or anyone else has looked at it.

[d-torrance]

I suppose I could cherry-pick the Ubuntu-only changes from that PR for this one. Would that be ok?

[mahrud]

You could do that, but I'm confused, why is M2 working on Ubuntu 22.04 not important?

[d-torrance]

It's definitely important! I was specifically thinking about not having to spend the time building FLINT 3 during the GitHub builds. Otherwise, in Ubuntu 22.04, we can either build FLINT 3 (cmake) or build against FLINT 2 + Arb (autotools).

[mahrud]

But that's not why this PR is failing, right? The cmake-ubuntu builds compile flint, but they still fail, and the autotools-ubuntu build also failed last time.

[d-torrance]

The autotools-ubuntu build failed last time because it was still using the FLINT 3 PPA package that caused the weird BeginningMacaulay2 example error. And it looks like that's what's causing the cmake builds to fail, too -- they built FLINT 3 but are using the packaged factory.

I just pushed a new version requiring Factory 4.4.0 (the first version with FLINT 3 support) in the cmake build, so hopefully that will fix those builds.

[mahrud]

Why not just resign to using the ppa package for flint and factory?

[d-torrance]

Mostly laziness. :)

I deleted the FLINT package from the PPA because of the BeginningMacaulay2 example bug. It would likely be fixed by packaging factory for the PPA, but I haven't done that. I figure that we'll likely be switching to Ubuntu 24.04 soon enough that I'm not sure if it's worth the effort.