ENH: stats: add dunnett_from_stats

[JohnAbe]

Dunnett's test can be performed even if only the means, standard deviations and sample counts are known. In this respect dunnett_from_stats() is to dunnett() as ttest_ind_from_stats() is to ttest_ind(). dunnett_from_stats will be especially useful when dealing with large volume experiments (eg: in online advertising) where the measurements for each observation are not available but the summary statistics are available.

Added tests to test_multicomp. Most of these replicate existing tests for dunnett function. For test_dunnett_from_stats_raises, there are new tests logically different from those for dunnett function.

Moved test_warnings() to the end because logically it is different from other tests. This one tests that the DunnettTests object's method behave in expected manner given specific input

Reference issue

What does this implement/fix?

Additional information

[mdhaber]

Thanks. Can you open an issue and make a post at https://discuss.scientific-python.org/c/contributor/scipy/32 to discuss such functions more broadly? Almost every function in stats could conceivably have a separate _from_stats version, but I'd prefer to pursue an alternative design that would require less duplication.

For example, I have noticed that some separation of functions that compute statistics from those that compute p-values would be beneficial. Objects returned by some tests contain a method that computes confidence intervals because CIs are not always needed. From that perspective, why is the p-value an attribute? Sometimes - like when you want to do a Monte Carlo or resampling version of a test - you only need the statistic and not the p-value. As this PR indicates, sometimes you don't need a function to go through the entire statistic calculation when summary statistics are available. In the long run, I'd like to move toward an interface that satisfies these different needs in a unified way.

What I've had in mind would involve objects with separate methods for the different outputs one might need. Perhaps there would be multiple ways of instantiating these objects - not just from raw data, but also from summary statistics.

The two halves can be decoupled, of course; that is, existing hypothesis test functions could begin to accept summary statistics as input. For example, instead of an array for each sample, one could provide a tuple of essential summary statistics or Sample objects (instantiated from these summary statistics).

What do you think of discussing these needs more broadly before adding this function?

[JohnAbe]

Thank you, @mdhaber! I see the good sense in that.

Admittedly, this is* my first rodeo - contributing to an open source project. And I want to help lay out a generic refactoring template (as you outline) so even other tests can subsequently be modified to work solely using summary stats where applicable. But I am worried that I will not be able to commit enough time to finish this refactor in a reasonable timeframe. With this perspective, could you please give me a sense of how this broader discussion may go? Is it for me to get guidance on specifics of how best to refactor? Or is it to break this refactoring initiative into smaller tasks so different individuals can contribute? Or something else?

[mdhaber]

Is it for me to get guidance on specifics of how best to refactor? Or is it to break this refactoring initiative into smaller tasks so different individuals can contribute?

Both of these. Let's ignore what I said about breaking up the tests into parts that calculate the statistic / p-value / CI - consider it to be background context that's been on my mind for a while. Here's what I'd suggest if you're interested:

• Collect a list of a few different stats functions that would benefit from having a "from stats" option. That is, look for others like dunnett that end up calculating summary statistics inside and don't need all the data itself. For example, skewtest really only needs the sample skewness and number of observations, I think. (You don't need to be the one to work on all these functions; I'm just asking you to investigate where this is leading before we go down this path.)
• Consider whether and how this data could be passed into the existing function. For instance, look at how either a tuple or LinearConstraint object can be passed to the constraints parameter of [milp](https://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.milp.html]. Maybe also look at the [ResamplingMethods](https://docs.scipy.org/doc/scipy/reference/stats.html#resampling-and-monte-carlo-methods] accepted as the method parameter of some stats functions (e.g. pearsonr, anderson_ksamp).
• Then think about whether this would meet users' needs as well as separate _from_stats functions and be easier to develop and maintain on our side. My guess is that that it will be slightly less discoverable and seem unfamiliar to users in the short term, but will make much more sense to users and seem natural in the long run if many functions offer this support. I would also guess that it will be far easier to maintain because we don't need to provide duplicate functions for essentially the same functionality. Even if they were to share implementation code, we would still be duplicating documentation. But your opinion may differ.
• Once you've formed thoughts along these lines, post them here, and then we can consider what to post on the discussion forum.

Does that sound manageable? Sorry it's not as simple as just merging this PR, but I think it's important to look ahead a bit!

[JohnAbe]

Understood. Thank you very much for these thoughtful responses!

Potentially all parametric tests can benefit from such an option where either raw data or summary stats can be fed in (like function overloading - but handled within the same function definition). I use Scipy a fair amount and feel obliged to help make this transition - especially since this kind of an interface will be more friendly for use in high volume experiments to test for small effects.

Unfortunately, I cannot spare a predictable amount of time regularly for the next 3 months or so. I could perhaps take this up starting in August or September 2024 as my pet project.