Distributions.jl icon indicating copy to clipboard operation
Distributions.jl copied to clipboard

Add Unicode alias `\ast` for `convolve`

Open devmotion opened this issue 3 years ago • 8 comments

Since there is no consensus yet on the Unicode alias for convolve yet in https://github.com/JuliaStats/Distributions.jl/pull/1445, I put together this PR with an alternative suggestion.

This PR contains the same changes as https://github.com/JuliaStats/Distributions.jl/pull/1445 but uses the alias (\ast) instead of (\oplus). This alternative was suggested in https://github.com/JuliaStats/Distributions.jl/issues/142#issuecomment-505948261. An advantage is that it matches more closely the ASCII alternative convolve as is a common notation for convolutions. However, disadvantages are that it is arguably less intuitive and looks similar to * (multiplication).

devmotion avatar Dec 09 '21 15:12 devmotion

The similarity to * is definitely a big problem if we keep the current notation for linear transformations of variables -- x∗y and x*y would mean two very different things.

ParadaCarleton avatar Dec 09 '21 20:12 ParadaCarleton

x∗y and x * y would mean two very different things.

I agree and therefore mentioned that this might be a problem. However, one should keep in mind that x * y (multiplication) is not defined if x and y are distributions but only if one of them is a scalar, array, etc. So mainly it would be a problem when reading the code - when the code is executed, standard multiplication will just throw a MethodError.

devmotion avatar Dec 09 '21 21:12 devmotion

A few more comments:

  1. If we don't want \oplus but want to keep something that looks like addition, we also have \boxplus.
  2. x \ast y is appropriate if we're thinking of x and y as being "equal to" their distributions, but in other situations, we've been following the convention of thinking of both x and y as being "equal to" the random variables. I'd prefer if we stuck to one or the other consistently.
  3. If we end up going with \oplus or something similar, I think it would make sense to deprecate the old + and * for affine transformations and use \oplus and \otimes for this, both for consistency and to avoid confusion with mixtures of distributions (since a * X + b * Y can look a lot like a mixture). If we have \oplus for sums, it's very likely that someone will notice + and assume it means something different from \oplus, so it must be taking a mixture.

ParadaCarleton avatar Dec 11 '21 21:12 ParadaCarleton

I disagree with 3., I don't think the choice here should affect the notation for affine transformations. They are separate things, and as discussed in the old issues related to this topic + and * make sense and are unambiguous for scalars and distributions in the context of Distributions.jl (see e.g. https://github.com/JuliaStats/Distributions.jl/issues/1438 for a discussion about it and references to prior discussions on this topic). We don't support any notation for mixture distributions and currently there are no plans to change this. Interpreting a * dist1 + b * dist2 as a mixture distribution would only make sense if a == 1 - b and not for general expressions of this form. It seems much more generally applicable to view a * dist1 as an affine transformation (and as mentioned dist1 + dist2 is not allowed since it is unclear if the two distributions would be independent or not).

devmotion avatar Dec 11 '21 21:12 devmotion

a * dist1 + b * dist2 per se is a good notation to produce an unnormalised mixture of distributions. We should not mix operators for "distributions as distributions" and for "distributions as random variables"

mschauer avatar Dec 12 '21 11:12 mschauer

I have a proposal; how about a macro that lets users clarify whether they want to treat a distribution as its pdf or random variable? @iid_rv x + y would return the convolution of pdf(x) with pdf(y), while something like @pdf could let the user clarify they want to add the pdfs together to get an unnormalized mixture.

ParadaCarleton avatar Dec 26 '21 23:12 ParadaCarleton

I don't think one should add a custom DSL to Distributions, so I think such macros should not be added (in general, I think one should limit the use of metaprogramming). It's also more verbose than convolve and the names seem not completely intutive (e.g., why would @iid_rv change the meaning of the distributions instead of returning eg a set of iid random variables? Similarly, why does @pdf not return or evaluate a probability density function?).

devmotion avatar Dec 26 '21 23:12 devmotion

I don't think one should add a custom DSL to Distributions, so I think such macros should not be added (in general, I think one should limit the use of metaprogramming). It's also more verbose than convolve and the names seem not completely intutive (e.g., why would @iid_rv change the meaning of the distributions instead of returning eg a set of iid random variables? Similarly, why does @pdf not return or evaluate a probability density function?).

I agree we should limit the use of metaprogramming, but this seems like a sufficiently limited addition that it shouldn’t cause major problems.

We could alternatively use wrappers around distributions, so that RV(x) + RV(y) returns the convolution.

(If the names are counterintuitive, maybe as_rv and as_pdf?

ParadaCarleton avatar Dec 27 '21 00:12 ParadaCarleton