Avoid stack overflows with non-standard float types #79
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There are certain combinations of types for which calls to this package fail with stack overflows. For example, this package uses the definition
(where
$f
might becos
, etc.). If there is then no more-specific method for float types other thanFloat64
andFloat32
, this is the only method to call, so we get a stack overflow with any other float type — such asFloat16
orBigFloat
.To avoid overflows generally, we can use the same approach that Julia uses here. Mostly, I believe this should compile away; the only case where it should matter is
lgamma
, where we don't have aBase
version to call back to.To deal with
Float16
, we use the same method that Julia itself uses for basic math functions — e.g., here— by just converting to
Float32
, calling the function, and converting back.For all other types (including
BigFloat
), we can just check for the appropriate domain, as is done inNaNMath.sqrt
. Forpow
, I think it is best to just fall back to theBase
function, but catchDomainError
s and returnNaN
in those cases. This is presumably slow for a lot of cases, but at least does what the package promises — and is probably not the slowest part of usingBigFloat
s at least.Note that I added
DoubleFloats
to the test dependencies to increase coverage ever so slightly, as that is the only way I know how to exercise theisa(e, DomainError)
branch inpow
. There is still one new line that I don't know how to cover, where some other type of Error could be raised; I don't know how to make that happen, so I'm not sure if that branch even needs to be there.Closes #76. See also #63.