Statistics

PR #22722 introduced a common method for the validation of the parameters of an estimator. We now need to use it in all estimators.

Please open one PR per estimator or family of estimators (if one inherits from another). The title of the PR should mention which estimator it's dealing with and the description of the PR should begin with towards #23462.

Steps

• The estimator must define

Collection of follow-ups to #5827. These can/should be broken out into individual PRs. Many are relatively straightforward and would make a good first PR.

General

• Documentation (none was added in original PR).
• Release notes.
• Example notebook.
• Double-check how sm.tsa.arima.ARIMA works with fix_params (it should fail except when the fit method is statespace

See:
gonum/gonum#845 (comment)

The currently implemented version of the horseshoe distribution is not the parameterization that most ML papers use. This limits the ease of use of this as, for example, a prior in a tfp.layers.KLDivergenceAddLoss or in tfp.layers.DenseReparameterization. The regularized horseshoe would also be useful as an implemented distribution.

The alternative parameterization is shown here:
https://www.

Since the default output is meant to be human-readable, would it make sense to add thousands separators to make the output more easily readable?

If you add multiple projects in GrowthBook, the dropdown list in the left navigation is sorted by creation date. We should instead sort them alphabetically. The dropdown is rendered in packages/front-end/components/Layout/ProjectSelector.tsx

For example, the data is (3.8,4.5,4.6,4.7,4.9)
while I'm using tech.tablesaw.aggregate.AggregateFunctions.percentile function, the 90th percentile is 4.9, however, if the percentile function supports linear interpolation, the 90th percentile should be 4.82, which is adopted by most other programming languages.