[ENH] _pmf_support method for BaseDistribution returning inspectable mass support

[arnavk23]

Reference Issues/PRs

Related to #416 (discrete PMF plotting improvements). This PR provides the foundational infrastructure that enables more robust discrete distribution plotting in follow-up PRs.

What does this implement/fix? Explain your changes.

This PR introduces a new _pmf_support(lower, upper, max_points) method to the BaseDistribution class that provides a standardized, extensible way to obtain support points for discrete distributions within specified bounds.

Key Changes:

• Base Implementation (skpro/distributions/base/_base.py): Added _pmf_support method that returns empty array for continuous distributions and non-negative integers for discrete distributions by default
• Empirical Distribution Override (skpro/distributions/empirical.py): Custom implementation that returns actual empirical support points within bounds
• Delta Distribution Override (skpro/distributions/delta.py): Implementation that returns point mass locations within bounds
• Comprehensive Tests (skpro/distributions/tests/test_proba_basic.py): Added test_pmf_support_method() covering all distribution types

This addresses the need for extensible support point detection across different discrete distribution types, replacing hardcoded assumptions with a clean, overridable API.

Does your contribution introduce a new dependency? If yes, which one?

No, this change introduces no new dependencies.

What should a reviewer concentrate their feedback on?

• API design and method signature consistency
• Extensibility for future distribution types
• Test coverage completeness
• Performance implications for large empirical distributions
• Backward compatibility

Did you add any tests for the change?

Yes, I added comprehensive tests in test_support_method() that cover:

• Continuous distributions (should return empty arrays)
• Discrete distributions with default integer support
• Empirical distributions with custom support points
• Delta distributions with point masses
• Boundary condition handling

Any other comments?

This PR establishes the core infrastructure for proper discrete distribution support handling. It serves as a foundation for improved plotting capabilities (as demonstrated in related PRs) and future enhancements like full support API implementation (issue #244). The design prioritizes extensibility while maintaining backward compatibility.

PR checklist

For all contributions

• I've added myself to the list of contributors with any new badges I've earned :-)
  How to: add yourself to the all-contributors file in the skpro root directory (not the CONTRIBUTORS.md). Common badges: code - fixing a bug, or adding code logic. doc - writing or improving documentation or docstrings. bug - reporting or diagnosing a bug (get this plus code if you also fixed the bug in the PR).maintenance - CI, test framework, release.
  See here for full badge reference
• The PR title starts with either [ENH], [MNT], [DOC], or [BUG]. [BUG] - bugfix, [MNT] - CI, test framework, [ENH] - adding or improving code, [DOC] - writing or improving documentation or docstrings.

For new estimators

• I've added the estimator to the API reference - in docs/source/api_reference/taskname.rst, follow the pattern.
• I've added one or more illustrative usage examples to the docstring, in a pydocstyle compliant Examples section.
• If the estimator relies on a soft dependency, I've set the python_dependencies tag and ensured dependency isolation, see the estimator dependencies guide.

[fkiraly]

Really nice, good idea!

Can we try to avoid the try/except though?

[fkiraly]

Thanks!

I think this is opening a can of worms though... the plotting assumes that the support is at integers, right? Which in general need not be the case, e.g., for Empirical.

To deal with this programmatically, we would need to be able to inspect each discrete - and also, potentially, mixed - distribution for the point masses.

Currently, this is not part of the API - see #244 for the issue to add this.

For now, I do think this PR is an improvement above the status quo, but I wonder whether we can do something quick and intermediate? E.g., a private function _support(lower, upper) that generates all discrete points between lower and upper?

[fkiraly]

Thanks for the additional thoughts about _support, I think this is great.

May I suggest to split this PR into two, one with _support and specific tests for it, and one about plotting, which stacks on it? I anticipate some discussion about _support.

Main questions about this PR as-is:

• how do we handle the issue that each entry can have different support, in a 2D shaped distribution, e.g., for Empirical or Delta? This feels a bit tricky.
• why are you deleting some of the existing tests?

[arnavk23]

Thanks for the additional thoughts about _support, I think this is great.

Here - Q1: 2D Support Handling: The _support method is called on scalar distributions (after [iloc[i,j] extracts each entry), not on the full 2D distribution. This means each entry gets its own support calculation.
For distributions with uniform support across entries (like [Binomial]), the base implementation works fine since all entries share the same support characteristics.
For distributions with entry-specific support (like Empirical or Delta), subclasses override _support to compute the appropriate support points for that specific entry based on its parameters.

In new pr (title - Incorrect pmf plotting) - Q2: Test Changes: The original test only checked that a stem plot was created, but didn't verify it contained actual data points (Added it back). The updated version checked for multiple support points to ensure the plotting worked correctly.

[fkiraly]

The _support method is called on scalar distributions (after [iloc[i,j] extracts each entry), not on the full 2D distribution. This means each entry gets its own support calculation.

Ah, I see! So it can be called only on 0D-array (i.e., scalar) distributions, right?

Although where all entries share the same support, it is a bit unfortunate that it cannot be called from the 2D one. Not sure how to solve this. Perhaps distinguish potential (class level) and actual (instance & entry level)? Anyway, that might be best discussed in a design issue and is not blocking for this PR.

[fkiraly]

Great!

Could you kindly expand in the docstring that the _support (a) applies to pmf only, and (b) scalar distributions only?

[fkiraly]

Great, thanks!

Small change - to make the purpose clearer, could we rename to _pmf_support?

[fkiraly]

Thanks!

I noticed that some implementations still deal with the 2D case - can you explain why this is there, if - according to your previous statements - the _pmf_support method is only for the 0D case.

[fkiraly]

can you explain why the 2D code was there and how you want to resolve it?

[arnavk23]

can you explain why the 2D code was there and how you want to resolve it?

The 2D logic in _pmf_support handled multi-dimensional distributions by aggregating support points across all elements. This contradicted the base class, which defines _pmf_support as 0D-only. I enforced this by raising NotImplementedError for ndim > 0 and removed redundant 2D handling. The code is now aligned with the docs, simpler, and all tests pass.

[fkiraly]

Ok, thanks!