Replace int with long long in nct pdf and cdf

[mborland]

See: scipy/scipy#17916

The upper bound for the non-centrality parameter is still lower than 2e16 from the reproducer, but it is much higher than it was. By extension the change also applies to non-central beta distribution.

[jzmaddock]

Thanks Matt!

[NAThompson]

FWIW, it wouldn't hurt to git grep for itrunc everywhere and see where it is sensible to replace with lltrunc; I've hit this issue before as well in a different context.

[jzmaddock]

The failures in this PR should be fixed by boostorg/multiprecision#536. Sorry about that!

[mborland]

@jzmaddock To buy us even more space I think we could conditionally use __int128 instead of long long because k is never streamed. Do you think that would be worthwhile in the event you don't find a better solution in literature?

[jzmaddock]

To buy us even more space I think we could conditionally use __int128 instead of long long because k is never streamed. Do you think that would be worthwhile in the event you don't find a better solution in literature?

A quick bit of Googling isn't turning much up. And yes I did wonder about using __int128, although we would have to check that a) it's available, and b) that the FP type has an explicit conversion to __int128. I also wonder if we might be into a territory where we're calculating garbage given that ultimately we will have many __int128's mapping to single FP values once they get passed back to the incomplete beta?

The other suggestion was to raise a domain_error in this case, and given that we know the limit on the non-centrality parameter this could be done early on in the distribution constructor?

[mborland]

The other suggestion was to raise a domain_error in this case, and given that we know the limit on the non-centrality parameter this could be done early on in the distribution constructor?

For all of these it would be easy to wrap the call to lltrunc in a try block and then throw domain error in the event it fails.

[jzmaddock]

Yup, although it circumvents the policy mechanism and building in exception-free environments, so maybe updating the checks for example here:

math/include/boost/math/distributions/non_central_t.hpp

Line 1095 in 2b9ab5a

!detail::check_finite(

might be better?

[mborland]

Yup, although it circumvents the policy mechanism and building in exception-free environments, so maybe updating the checks for example here:

math/include/boost/math/distributions/non_central_t.hpp

Line 1095 in 2b9ab5a

!detail::check_finite(

might be better?

Do we know the exact values for the nct failures because they are near, but not at the square? The other ones are straight-forward.

[jzmaddock]

Do we know the exact values for the nct failures because they are near, but not at the square? The other ones are straight-forward.

Ah, good point. Yes we need to be able to square the non-centrality, but in all cases we need to leave a bit of headroom as well, because we need to be able to iterate forward from what is only a starting point. So would sqrt(max) - max_series_iteations be reasonable?

[mborland]

Ah, good point. Yes we need to be able to square the non-centrality, but in all cases we need to leave a bit of headroom as well, because we need to be able to iterate forward from what is only a starting point. So would sqrt(max) - max_series_iteations be reasonable?

I think that would work. Do you me to merge this so you can take over the error handling? I am very bad at working with the policies.

[jzmaddock]

That's fine yes: BTW I'm still waiting for CI on multiprecision to cycle to fix those last few failures.

Oh, and there's a boost release incoming.... once we're all green again we should probably do a merge to master and then get back to the bugs.

[mborland]

Ok. Once I see the notification that you merged the multiprecision PR I will cycle the CI on this one to confirm the changes.

[jzmaddock]

Cycling now...

[mborland]

This is back to green so looks like your multiprecision fixes worked. Merging.