Oliver Schulz

> @oschulz , is there any reason to "depend on" LinearMaps.jl for compatibility? Why not just be generic and leave argument types unspecified But that's basically saying "don't use multiple...

> By scalar I assume you mean, scalar times the identity matrix? For example, but also more general let's say you have something like ``` mcmc_sample(target, metric::Real} =... mcmc_sample(target, metric::AbstractMatrix{

> it is just that it seems that whatever methods you have in mind, may also work with other types that behave as linear maps. True, there's several "linear operator/map"...

CC @dpo, @abelsiqueira and @geoffroyleconte (LinearOperators.jl).

From a viewpoint of dispatch/ambiguity, e.g. with functions that deal with operators and functions (since function already have no clear supertype), I think an abstract supertype would be helpful. We...

> That is, we would not be able to unambiguously concatenate LinearMaps and matrices Oh, right, that would be a problem. Ok, no making it an array. :-)

> a problem if we have a product with different "origin depths" Well, if it's a tuple-based product, the transport for each marginal should generate separate code and everything should...

Is there any way to work around this for now - by passing Enzyme.jl some manual hints on aliasing or so?

@wsmoses I tried using UnsafeArrays to work around the Enzyme/Julia double-pointered-arrays problem (so Enzyme should be able to infer aliasing correctly?): ```julia using UnsafeArrays UnsafeArrays.uview(A::Duplicated) = Duplicated(uview(A.val), uview(A.dval)) function f!(dA,...

Hi @atasattari, BAT.jl has trouble running with only one chain, could you run with two chains at least? It's on the to-do list, we just haven't gotten around to fixing...