Vector args for loglike?

[ParadaCarleton]

NestedModel(loglike, prior_transform)
  NestedModel(loglike, priors::AbstractVector{<:Distribution})

  loglike must be callable with a signature loglike(::AbstractVector)
  where the length of the vector must match the number of parameters
  in your model.

Should we be working with vectors here rather than tuples? The main concern I have is if the parameters are of different types (e.g. if one of the parameters is discrete), which could lead to a Vector{Real}, for instance.

[ParadaCarleton]

(Also, the docstring should probably specify whether loglike is the log-likelihood function before or after transforming the variables with the prior to fall on the unit cube.)

[cpfiffer]

That's kind of a bigger issue -- ignore it for now and assume vectors are satisfactory. For the most part we tend to work with moderately tightly-typed floats or integers, so it's not as big an issue. I'd be interested in seeing a tuple approach here but that comes with a bajillion headaches that it's not worth digging into at the moment.

[mileslucas]

In addition, the code that calls the functions (i.e., the proposal algorithms) is using Vectors, since the pool of live points is a Matrix. We could allow users the option of container type, but there's no pressing need right now.

[mileslucas]

Also, the docstring should probably specify whether loglike is the log-likelihood function before or after transforming the variables with the prior to fall on the unit cube.

This is a good point. I think this is something that could be built into a more "intelligent" NestedModel. For example, if I had a way for nested models to know whether to apply the prior transform explicitly or not, I can just create a generic method like "loglike_withtransform" for use in the proposal algorithms. I don't know if this is 100% feasible with the algorithms currently implemented but I can check!

[ParadaCarleton]

In addition, the code that calls the functions (i.e., the proposal algorithms) is using Vectors, since the pool of live points is a Matrix. We could allow users the option of container type, but there's no pressing need right now.

From what I can tell, using named tuples or structs instead of vectors would provide a very big benefit for linking with Turing.jl -- loglike(model, Vector) is not defined, while loglike(model, NamedTuple) is, so working with named tuples would make things much easier.