Support many more MPFR functions

[projekter]

I recently saw that MutableArithmetics does not support most of the functions that MPFR offers, only the basic arithmetic and assignment stuff. Actually, I needed it for assignment of (bit) integer values, but when I looked at it, I thought that just implementing the whole bunch of functions is not much more effort once you have a nice macro to automate it.
So in this PR:

• I implement a macro that creates the function wrappers, replacing the manual repetitive wrappers
• I rewrite all existing MPFR functions to use this macro
• I implement most or perhaps even all of the standard functions (i.e., functions that Julia's BigFloat implementation already knows without mutation), where I follow the order of the MPFR documentation

However:

• There are no tests for this yet (but the existing ones are not broken) - first I would like to know whether you are interested in this functionality at all or whether you think it is too much? After all, the package is called "arithmetics," which you could in a strict sense say is a bit narrower than what this PR does.
• It would make sense to extend this approach to BigInt, which also has a couple more functions that could be implemented, and also some functions that are at the intersection of GMP and MPFR (setting MPFR Floats from GMP Ints).
• It would also make sense to include a package extension for SpecialFunctions.jl and implement the functions from there that are part of MPFR.

If you want this to proceed, I think tests should be part of this PR, but the other two points could also be separate...

[codecov]

Codecov Report

❌ Patch coverage is 27.00000% with 73 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.86%. Comparing base (e00703e) to head (fb41752).
⚠️ Report is 8 commits behind head on master.

Files with missing lines	Patch %	Lines
src/implementations/BigFloat.jl	27.00%	73 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #342      +/-   ##
==========================================
- Coverage   89.86%   86.86%   -3.00%     
==========================================
  Files          22       22              
  Lines        2141     2208      +67     
==========================================
- Hits         1924     1918       -6     
- Misses        217      290      +73     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[blegat]

Yes, I would welcome the addition, the macro makes implementing them quite compact! I would deal with BigInt in a separate PR

[nsajko]

@projekter FYI this PR fails CI:

• the diff lacks full code coverage

• format-check fails, I suppose just run a code formatter to fix this

[odow]

I'm very hesitant to accept this. I have almost always come to regret using macros for code generation within a package. This is a large increase in code for what is already a very complicated package.

@make_mpfr copy(::BigFloat) -> mpfr_set

# instead of

promote_operation(::typeof(copy), ::Type{BigFloat}) = BigFloat

function operate_to!(out::BigFloat, ::typeof(copy), x::BigFloat)
    @ccall libmpfr.mpfr_set(
        out::Ref{BigFloat},
        x::Ref{BigFloat},
        Base.MPFR.ROUNDING_MODE[]::Base.MPFR.MPFRRoundingMode,
    )::Int32
    return out
end

I tend to like the more verbose code. It's much easier to reason about, and it shows the true cost of maintenance.

It's also slightly tangential to our original motivation, which was a package to make JuMP's macros faster.

@blegat and I need to discuss.