Open Sleort opened 5 months ago
lxvm
commented
5 months ago Hi,
To me it looks like your integrand is behaving as expected because QuadGK.jl gives your integrand a scalar, u, and so your broadcasting function f will also return a scalar because there is nothing to give it a shape, unlike f! which gets its shape from y. Does this help?
Sleort
commented
5 months ago Hmm...Yeah... I guess I just misunderstood the documentation saying that
If
integrand_prototypeis present for either in-place or out-of-place integrands it is used to infer the return type of the integrand.
In other words, I imagined integrand_prototype would provide the shape...
Maybe cases like this one, i.e. when typeof(solution(...).u) != typeof(integrand_prototype), should error instead?
lxvm
commented
5 months ago Yes, we use integrand_prototype to determine the type and shape of the integrand in some cases, in particular for C libraries or to pre-allocate workspaces with correct types for algorithms. Also, we currently assume the output of the user's function is consistent with the prototype, but we don't assert it because the type of the solution may depend on the library used. Any pr to check for correctness would be welcome as long as the type assertions don't incur runtime overhead for type-stable use-cases.
Describe the bug 🐞
A 1D integral of a vector valued out-of-place function returns a scalar, even when a vector valued integrand prototype is provided. The equivalent in-place problem works as expected.
Expected behavior
When a vector valued integrand prototype is provided, the solution should be the same for out-of-place and in-place integrands.
Minimal Reproducible Example 👇
This works as expected:
while this doesn't:
Environment
using Pkg; Pkg.status()using Pkg; Pkg.status(; mode = PKGMODE_MANIFEST)versioninfo()