Discrete distributions with continuous value support

[mauricelanghinrichs]

I noticed the following behaviour of push_p methods. push_p will round discrete distributions (i.e., referring to Distributions.jl type system) to integer values, to allow inference of discrete-valued distributions in ABCdeZ.jl. However, some special discrete distributions (Dirac, DiscreteNonParametric) may have continuous value supports where rounding is then inappropriate. Distributions.jl categorises distributions as countable (=discrete) vs. uncountably infinite (=continuous). While implementation in ABCdeZ makes use of this type system, assuming discrete value support for discrete distributions and continuous value support for continuous distribution. For all practically relevant distributions this is fine, with the two potential exceptions above.

Example: One obtains

prior = Factored(Uniform(0.0, 1.0), Uniform(0.0, 1.0), Dirac(7.5))
s = rand(prior) # (0.35588142501118525, 0.9892502251562425, 7.5)
ABCdeZ.push_p(prior, s) # (0.35588142501118525, 0.9892502251562425, 8)
logpdf(prior, ABCdeZ.push_p(prior, s)) # -Inf

while

prior = Factored(Uniform(0.0, 1.0), Uniform(0.0, 1.0), Dirac(8.0))
s = rand(prior) # (0.35588142501118525, 0.9892502251562425, 8.0)
ABCdeZ.push_p(prior, s) # (0.35588142501118525, 0.9892502251562425, 8)
logpdf(prior, ABCdeZ.push_p(prior, s)) # 0.0

This is due to

supertype(Dirac) # Distribution{Univariate, Discrete}

Possible solutions:

1. special case discrete distributions with continuous value support; e.g. via push_p(d::Dirac, s) = "I'm a special case". EDIT: this may actually be no solution, as one will almost surely not hit the support values again. Rounding made sure of that exactly for integer support distributions.
2. dispatch push_p not on their distribution type but based on their value support / value type. This may however dispatch during runtime which should be prevented. EDIT: this would probably not help at all, see point 1). Problem is that one has to project back the continuous search space to (non-integer) countable value support. I.e. we would need to "round" 7.42 and 7.98 back to 7.5....
3. don't change code, but document the two special cases. They are somewhat degenerate (Dirac) or easily fixable on the user level (for DiscreteNonParametric one may sample discrete indices first, and then on the model function level extract real values).

So current preference may be the option 3.