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

min/max or infimum/supremum #150

Closed
lindahua opened this issue Sep 18, 2013 · 6 comments
Closed

min/max or infimum/supremum #150

lindahua opened this issue Sep 18, 2013 · 6 comments

Comments

@lindahua
Copy link
Contributor

@ingmarschuster mentioned in #126 that min(d) and max(d) is not appropriate for distributions whose support is an open interval.

This is true in theory.

Here, we have to make a decision, between the following options:

  1. Continue to use min and max, and documents that these functions return infimum and supremum when the domain is open.
  2. Change the function names to infi and supr (or infimum and supremum). When the domain is closed, this still makes sense (in such cases, infimum equals the minimum and supremum equals maximum).

cc @johnmyleswhite @dmbates

@johnmyleswhite
Copy link
Member

My preference is to use min and max, noting in the docs that these may be used in lieu of infimum and supremum when necessary. This is slightly sloppy, but it seems to offer the same simplifying virtue that using pdf everywhere instead of pmf offers.

@dmbates
Copy link
Contributor

dmbates commented Sep 18, 2013

I agree with @johnmyleswhite. Using min and max also avoids introducing more names of generics. Mentioning in the documentation that these are actually the infimum and supremum for distributions whose support is an open interval should be enough to satisfy pedants like me. :-)

@StefanKarpinski
Copy link

I'm cool with that too, despite the mathematical incorrectness.

@ingmarschuster
Copy link
Contributor

ok, I wouldn't care for correctness if it wasn't screwing up semantics too much. As mentioned in #126, I think it would be elegant to be able to implement insupport using min,max and possibly infimum and supremum. So if we cut out infimum and supremum, it would make sense to be able to distinguish whether min and max are included in the support (at this point you might reference me back to insupport - oh well).

@simonbyrne
Copy link
Member

I'm curious as to the rationale for needing to distinguish between an open interval and its closure: mathematically, the uniform distribution on [0,1] and the uniform distribution on (0,1) are identical. In what case would the need for this distinction arise?

The whole concept of support isn't really a natural fit for probability anyway, it's really an analysis/topological concept in terms of functions, and trying to define it in terms of probability/measures is rather convoluted (interestingly, that article defines it as a closure anyway, which would make this whole minimum vs infimum argument redundant).

@ingmarschuster
Copy link
Contributor

Bah, [the linked Wikipedia article](https://en.wikipedia.org/wiki/Support_(measure_theory%29) says @simonbyrne is right. So actually the code in beta.jl insupport(::Beta, x::Real) = zero(x) < x < one(x) was wrong and it should be insupport(::Beta, x::Real) = zero(x) <= x <= one(x) (or rather insupport(d::Beta, x::Real) = min(d) <= x <= max(d)). If everybody agrees, I'll change the code in my pull request to just use min and max (without any infimum/supremum).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants