Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add basic location-scale family support #144

Closed
wants to merge 1 commit into from
Closed

Conversation

johnmyleswhite
Copy link
Member

This adds an initial draft of support for location-scale families of univariate distribution. This makes it possible to rescale and relocate univariate distributions using scalar arithmetic, giving things like d1 = Normal(0, 1) + 3 and d2 = 3 * Uniform(0, 1) + 11.

The basic principle is simple: unless there is a clear way in which changing the location or scale of a distribution produces another distribution of the same type, we create an ad hoc UnivariateLocationScaleFamily type, which maintains a separate location and scale parameter. Thus, one has two ways of writing some distributions. for example, the two distributions below are meant to be identical:

  • UnivariateLocationScaleFamily(Normal(0, 1), 2.0, 2.0)
  • Normal(2.0, 2.0)

But special cases are handled as needed, so that 3 * Normal(0, 1) gives Normal(0, 3) rather than the less efficient UnivariateLocationScaleFamily(Normal(0, 1), 0.0, 3.0).

@patrickeganfoley
Copy link

Hello,

Is this doing something similar to this code https://github.com/patrickeganfoley/Distributions.jl/blob/master/src/relationships.jl ?

It doesn't seem like it, or maybe this was never pulled and was decided against, since right now you get:

julia> ef = 3*Normal(0,1)
ERROR: no method *(Int64, Normal)

Do we not want that? Or stuff like exp( Normal(0,1) ) = LogNormal(0,1) ?

@lindahua
Copy link
Contributor

There hasn't been much progress along this line, probably because of there are more important things. No one is against this. It is just a matter of time before this happens.

@patrickeganfoley
Copy link

Cool.

If I were to do it, should I have it all on one file?

@lindahua
Copy link
Contributor

There's no rule governing about what should go in one file.

The general practice is that you start from one file, and if the file gets too long or too complicated, break it into smaller files.

@johnmyleswhite
Copy link
Member Author

Now that I'm thinking about getting the bare minimum in place and worrying about efficiency optimizations later, I'm wondering if we should have the parametric type be LocationScaleFamily and let that vary with variate type.

@matbesancon
Copy link
Member

Closing this for #635
@kleinschmidt same here :)

@matbesancon matbesancon deleted the jmw/lsf branch November 16, 2018 21:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants