Implement pFq cancellations

[TSGut]

Fixes #99

Tests against mpmath results included too. Happy for you to redesign the fix if you have a different design preference @MikaelSlevinsky.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.30%. Comparing base (f7904bc) to head (cf935b0).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #100      +/-   ##
==========================================
+ Coverage   87.19%   87.30%   +0.10%     
==========================================
  Files           8        8              
  Lines        1781     1796      +15     
==========================================
+ Hits         1553     1568      +15     
  Misses        228      228              

☔ View full report in Codecov by Harness.
📢 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.

[MikaelSlevinsky]

Thanks! Evaluating on the branch cut will remain difficult until pFqconformalrational can be called. (Even then, that method won't handle certain other difficulties, such as if the pFq is terminating (a poly)).

[MikaelSlevinsky]

The next design decision is: what if parameters are normwise close to equal?

[TSGut]

If they're close to equal my tests indicate BigFloat can overcome it. Exact cancellation failed even under BigFloat escalation which is why I think it should be fixed.

Longer term a genuine F64 variant would be better of course.

[TSGut]

Actually I just realised the new stuff I have for MeijerG functions fits this problem perfectly (unreleased atm). The exact cancellation should still work as this PR suggests but the near normwise thing you can leave to me if you have a few weeks since I just need to extract the Meijer G machinery and make it a separate thin package.

[MikaelSlevinsky]

If you can just fix the type instability, this PR should be ready to go!

[TSGut]

Isn't the type stability an intrinsic consequence of the Tuple inputs which carry their element number in the type? I guess what I can do is run a check if a cancellation occurs directly, then only route to the removal if needed, keeping the main non cancelling path stable.

To make the removal stable I think it can't use tuple inputs?

[MikaelSlevinsky]

Canceling common parameters is tricky when a num/den pair are both negative integers: it's arguable that the series is terminating, such as in https://dlmf.nist.gov/16.4#E2_5. This is a distinct issue, so happy to merge now

[MikaelSlevinsky]

Oh this is more complicated than I thought: the function cancelcommonparameters itself is also not type stable because it could return tuples of any length between empty and original.

[MikaelSlevinsky]

This in turn breaks type stability of pFq.

[TSGut]

I did try, I just think it's a limitation of the tuple framework. But one could always make pFq a function that has cancelcommonparameters and then a _pFq_unsafe, and the unsafe one doesn't cancel parameters and is type stable, thus isolating the type instability to cancelcommonparameters. But I don't think one can make cancelcommonparameters itself type stable because tuple shortening is involved.

[MikaelSlevinsky]

There might be: if you only cancel one pair of common parameters at a time? This is happens with Gauss:

HypergeometricFunctions.jl/src/gauss.jl

Lines 10 to 13 in 958bae6

	elseif isequal(a, c) # 1. 15.4.6
	return pFq((b, ), (), z)
	elseif isequal(b, c) # 1. 15.4.6
	return pFq((a, ), (), z)

[MikaelSlevinsky]

Yeah, canceling one pair at a time fixes this. I'll push my changes tomorrow