Loosen the HCubature element type bound for SVectors to allow Dual numbers #28
Conversation
…mbers Interestingly, all of the other definitions were `<:Real`, so the current behavior doesn't error right away but instead it falls into a StackOverflow trying to keep changing types until it can finally call this dispatch, which it's never able to do because it has a tighter signature. Loosening this should fix this SO and allow for Dual numbers to be used with SVector inputs.
|
Note that passing through dual numbers is a pretty inefficient way to compute the derivative with respect to an endpoint — it should really just do a lower-dimensional integral over a surface of the hypercube. |
|
Yeah, we're not using it for the endpoint derivatives. This just came up when trying to verify derivative calculations in https://github.com/SciML/Quadrature.jl and it was low hanging fruit so I thought it might as well work. We're more interested in the derivative w.r.t. parameters of the integrand which works nicely with the dual numbers, and this just showed up when testing. |
|
Actually, I guess it did show up because one of the parameters is related to the support of the distribution we're integrating. Good point that it's just another integral. |
Interestingly, all of the other definitions were
<:Real, so the current behavior doesn't error right away but instead it falls into a StackOverflow trying to keep changing types until it can finally call this dispatch, which it's never able to do because it has a tighter signature. Loosening this should fix this SO and allow for Dual numbers to be used with SVector inputs.Xref SciML/SciMLExpectations.jl#17