@mohamed82008 I reverted some functions about pre-allocating memory so that only intermediate variables are pre-allocated and all functions remains immutable. This is to avoid un-expected behaviour due to mutability. We probably want to implement mutable version of functions to pre-allocate memory for return variables explicitly later. Does it sound good to you?
Sorry, I missed this question. I think it would be nice to support mutable and immutable array types, e.g. StaticArrays.SArray and StaticArrays.MArray or Vector. I saw Chris mention somewhere that DiffEq does this by defining 2 versions of the function, one for mutable arrays and one for immutable. We might want to explore something like this in a future PR. The mutating version takes a first argument the pre-allocated output vector whereas the non-mutating version doesn't. Supporting StaticArrays would be an interesting direction to pursue to gain some speedup for parameter vectors of size <1000 or so. Small arrays is the sweet spot of StaticArrays putting ordinary arrays to shame in many cases.
Discussions in https://github.com/TuringLang/AdvancedHMC.jl/pull/5#issuecomment-470335981
Sorry, I missed this question. I think it would be nice to support mutable and immutable array types, e.g. StaticArrays.SArray and StaticArrays.MArray or Vector. I saw Chris mention somewhere that DiffEq does this by defining 2 versions of the function, one for mutable arrays and one for immutable. We might want to explore something like this in a future PR. The mutating version takes a first argument the pre-allocated output vector whereas the non-mutating version doesn't. Supporting StaticArrays would be an interesting direction to pursue to gain some speedup for parameter vectors of size <1000 or so. Small arrays is the sweet spot of StaticArrays putting ordinary arrays to shame in many cases.