#12407 closed Bugs (fixed)
typos/bugs in arcsine CDF and support?
Reported by: | Owned by: | John Maddock | |
---|---|---|---|
Milestone: | To Be Determined | Component: | math |
Version: | Boost 1.61.0 | Severity: | Cosmetic |
Keywords: | arcsine distribution | Cc: | maciej.swat@…, pbristow@… |
Description
Hi, I have two questions/corrections regarding the arcsine distribution.
- On the website
http://www.boost.org/doc/libs/1_61_0/libs/math/doc/html/math_toolkit/dist_ref/dists/arcine_dist.html in the main text, the formula for CDF contains a bug. Instead of F(x) = 2⋅arcsin(√((x-x_min)/(x_max - x))) / π it should be F(x) = 2⋅arcsin(√((x-x_min)/(x_max - x_min))) / π
Note that the CDF is is correctly displayed in the 'Implementation' box F(x) = 2/π⋅sin-1(√(x - a) / (b - a) )
- Should the support be (0,1) instead of [0,1], see e.g.
http://www.math.uah.edu/stat/special/Arcsine.html
Best Regards, Maciej
Change History (5)
comment:1 by , 6 years ago
Component: | Documentation → math |
---|---|
Owner: | changed from | to
comment:2 by , 6 years ago
Cc: | added |
---|---|
Resolution: | → fixed |
Status: | new → closed |
comment:3 by , 6 years ago
Sorry to come late to this (been away). I think we can probably provide support for [0,1]. I'll check this out and say when I've done that (or decided why not). Won't be in the upcoming release, but will be committed to develop as soon as the release is out in case you wanted to pick up earlier.
comment:4 by , 6 years ago
Paul, I think you have this the wrong way around: we *do* support the end points of the range already, the argument was that these should actually be undefined... but different sources seem to have different views on that.
John.
comment:5 by , 6 years ago
OK - I said I'd do some homework, and I have, starting with reading the original post and grabbing hold of the right end of the stick ;-)
https://reference.wolfram.com/language/ref/ArcSinDistribution.html warns of "PDF ... potential singularities (where it asymptotically approaches infinity) at points near both xmin and xmax" but is quiet about what happens at the max and min.
So I agree with John on this issue, and supporting [0, 1] is consistent with other Boost math implementations.
I think it provides the most convenient match of the infinite precision math to the digital floating-point implementation. We signal the singularity by returning infinity rather than throwing an exception (or whatever) to the input. We think this is commonly convenient for users.
Users can very easily intercept values that are at the min or max before the PDF or CDF call if they wish to catch and handle this in some different way.
Thanks I've fixed the typo in Git.
WRT to the second question, Wikipedia has support over [0,1], and indeed PDF and CDF are perfectly calculable there, albeit the PDF is infinite at the limits. So I guess this comes down to taste?