As raised in #44, boost::math functions throw an exception under certain edge cases (e.g., domain error, pole error). In this scenario, bignum catches the exception and inserts NA in the result vector:
|
try { |
|
output.data[i] = UnaryOperation(x.data[i]); |
|
} catch (...) { |
|
output.is_na[i] = true; // # nocov |
|
} |
In contrast, the base R version of the math function might not return NA. For example, it might return NaN or infinity. We should align the bignum outputs with base R and add these edge cases to the unit tests. I think the correct approach is to pass an error handling policy as an argument to the boost::math function.
Here's a list of known edge cases that cause disagreement between bignum and R:
As raised in #44,
boost::mathfunctions throw an exception under certain edge cases (e.g., domain error, pole error). In this scenario, bignum catches the exception and inserts NA in the result vector:bignum/src/operations.h
Lines 16 to 20 in aeb311c
In contrast, the base R version of the math function might not return NA. For example, it might return NaN or infinity. We should align the bignum outputs with base R and add these edge cases to the unit tests. I think the correct approach is to pass an error handling policy as an argument to the
boost::mathfunction.Here's a list of known edge cases that cause disagreement between bignum and R:
digamma(-1)