Avoiding automatic type promotion from F32 to F64 in NUTS

[SamuelBrand1]

I have a project for extending Distributions.jl to a new system of distribution types which use float32 float types throughout parameters and return type.

In some experiments on running toy inference problems (a log-Random walk with Poisson link) I realised that with a small number of changes DynamicHMC can be fully parametric on its float type e.g. the step size etc.

The overall goal is to have the ability to try out lifting some/all of the inference problem to compute on a GPU device. From numpyro we know that this can be advantageous in some situations and IMV having a parametric float system, as opposed to enbedded f64 assumptions in some places, is a good first step on this.

EDIT: The project is here https://github.com/SamuelBrand1/DistributionsF32 Pretty nascent still!

[tpapp]

I am open to this, PRs welcome, happy to answer questions if anything crops up.

[SamuelBrand1]

Thanks @tpapp .

I've had a go in #199 : obviously changing the API is unacceptable! I've mainly just converted some of the key structs to parametric on the float type of various scalars (e.g. stepsize). The onus should be on a user who wants a different float type to give starting position in the correct float eltype (i.e. Float32) other wise I think everything should just stay the same.