Support type of Discrete distributions

[GordStephen]

Right now Discrete distributions are assumed to have supports limited to Int values. This makes sense if the discrete distribution's support is assumed to serve as a proxy for some other set of non-numeric values, but the reworking of EmpiricalUnivariateDistribution (#661) and the proposed new Generic distribution (#634) both provide good examples of discrete distributions with numeric but potentially non-integer supports.

As far as I can tell this assumption is primarily relevant for preallocating arrays for random draws from samplers. Could we just have sampler implementations provide their own eltype method instead of inferring the support type from whether the distribution is continuous or discrete?

[GordStephen]

Any thoughts on this, one way or the other? If people are receptive to the idea I'm happy to submit a PR.

[kmsquire]

Not very familiar with that code, but instead of having each sampler provide its own eltype, I would instead consider having a method, supporttype(...), which defaults to Int for Discrete distributions, Float64 (or whatever is appropriate) for Continuous distributions, and override that method for individual distributions whenever that is not true. Samplers could then use this method to determine the support type for the given distribution.

[GordStephen]

I agree, a default implementation with the ability to add a specialized method on concrete distributions makes the most sense. The new supporttype method shouldn't be required though, since it's essentially what eltype already does.

The existing code is actually very close to this, the only change required would be to remove the explicit coupling between continuous/discrete distributions and Float64/Int support since while those mappings are the defaults, a particular distribution is free to define their own eltype method. I'll submit a PR.

[matbesancon]

@GordStephen I understand this one could be closed?

[GordStephen]

Maybe, although there are still assumptions about discrete supports being integer and representable by a UnitRange floating around in the codebase. This probably won't be fully addressed until the type hierarchy is reworked.

[matbesancon]

oh ok I thought #634 fixed it but I understand catching it all can be tricky. We'll close it and re-open if needed