David Widmann

Maybe the cleanest and safest way would be to just fix and implement `cholesky` similar to ChainRules (which was also was ForwardDiff returned in previous versions), and only turn to...

> How do you implement extract_gradient_chunk!(::Type{T}, result::AbstractArray, y::Real, index, chunksize) so thats its inferred and allocation free for Arrays? With `fill!` as done in the definition of `extract_gradient!` for `y::Real`,...

> Thanks, fill! doesn't have a variant with an offset / chunk size though unless I'm mistaken? No, not that I know of. But couldn't you `fill!` a `view`? I...

> the map! interface, which are definitely very orthodox. Oh, with unorthodox I was referring rather to the fact that currently the PR removes a simple `copyto!` statement and adds...

> No, thats allocating for multidimensional Arrays, which is the entire issue that led to the solution currently in this PR. We could use `fill!` + `Base.ReshapedArray` :smile: That seems...

Well, I still think that 1) replacing the `copyto!` and dispatching to the chunk size-based implementation and 2) the `map!`+`ReshapedArray` are both very unnatural workarounds for a very specific package...

So it seems the PR actually introduces a regression in its current form?

I think this issue should be filed with StatsFuns. The missing part is support of ForwardDiff for `StatsFuns.gammalogccdf` and/or `StatsFuns.poislogcdf`. These functions do not support `ForwardDiff.Dual` yet. The problem is...

I can't comment on official API and design questions here, at least not in an official way. However, a quick note on > However, (1) it introduces the DiffResults dependency...

Small caveat is that SimpleNonLinearSolve was extracted and to a large extent copied from NonLinearSolve just some days ago, so the links are basically a single example of the second...