Skip to content

Conversation

@arnavk23
Copy link
Contributor

@arnavk23 arnavk23 commented Dec 13, 2025

Reference Issues/PRs

Fixes #248

What does this implement/fix? Explain your changes.

  • Create estimator_overview.rst with interactive HTML/JavaScript search table
  • Add Sphinx conf.py integration to auto-generate estimator data during build
  • Create build_tools/generate_estimator_data.py for data collection
  • Add tags_reference.rst page explaining tag system
  • Update index.rst to include estimator overview in navigation
  • Update api_reference.rst to organize estimator overview and API docs
  • Include search filters by type, name, and tags
  • Display key estimator properties in searchable table

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

What should a reviewer concentrate their feedback on?

Did you add any tests for the change?

Any other comments?

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.

Add comprehensive documentation of censoring indicator conventions
used across lifelines, scikit-survival, and ngboost adapters.

Clarifies:
- skpro convention: C=0 (uncensored), C=1 (censored)
- lifelines: event_col=1 (uncensored), event_col=0 (censored)
- scikit-survival: delta=True (uncensored), delta=False (censored)
- ngboost: E=1 (uncensored), E=0 (censored)

All existing transformations are confirmed to be correct.
All external packages use the same opposite convention to skpro.
Add detailed comments and docstring updates to clarify the censoring
indicator conventions for issue sktime#313.

Changes:
- Add explicit transformation comments in lifelines adapter
- Add explicit transformation comments in scikit-survival adapter
- Add explicit transformation comments in ngboost adapter
- Update docstrings to document the convention conversions

All adapters correctly translate between:
- skpro: C=0 (uncensored), C=1 (censored)
- lifelines: event_col=1 (uncensored), event_col=0 (censored)
- scikit-survival: delta=True (uncensored), delta=False (censored)
- ngboost: E=1 (uncensored), E=0 (censored)
Add detailed summary documenting:
- Issue investigation and findings
- Verification of all three adapters (lifelines, scikit-survival, ngboost)
- Confirmation that all implementations are correct
- Documentation and code enhancements made
- Verification steps performed

All censoring indicator translations are correct and now well-documented
to prevent future confusion.
…ty for issue sktime#248

- Create estimator_overview.rst with interactive HTML/JavaScript search table
- Add Sphinx conf.py integration to auto-generate estimator data during build
- Create build_tools/generate_estimator_data.py for data collection
- Add tags_reference.rst page explaining tag system
- Update index.rst to include estimator overview in navigation
- Update api_reference.rst to organize estimator overview and API docs
- Include search filters by type, name, and tags
- Display key estimator properties in searchable table
Copy link
Collaborator

@fkiraly fkiraly left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, good start!

  • currently "module" always shows "unknown"
  • tags in skpro are not "present or not present", but they are different by value. The value is also not always a boolean True/False, so I think the key action for a user is to display the tag, and then they can search themselves.
  • It would be great if the user interface with the boxes could also be replicated from sktime - feel free to copy-paste

@arnavk23 arnavk23 requested a review from fkiraly December 15, 2025 06:31
@fkiraly fkiraly changed the title [ENH] Adding sktime estimator overview [DOC] interactive estimator overview page Dec 17, 2025
@fkiraly fkiraly added the documentation Documentation & tutorials label Dec 17, 2025
@fkiraly
Copy link
Collaborator

fkiraly commented Dec 17, 2025

@arnavk23, thanks - but you need to test the overview yourself before you request a review.

Have you looked at it?
This is how it currently looks like:

image

- Change tag data structure from list to object in conf.py
  Tags now stored as {key: boolean} instead of ["key:value"] strings
  This fixes array indices appearing in tag display (0:, 1:)

- Update JavaScript filtering logic in estimator_overview.rst
  Use .every() for proper multi-tag filtering
  Filter display to only show truthy tag values
  Correctly format tag labels and values from object structure

This resolves the tag display issue where tags were shown as
"0: object_type:regressor_proba" instead of "object_type: regressor_proba"
@arnavk23
Copy link
Contributor Author

arnavk23 commented Dec 18, 2025

@fkiraly Can you review this pr again. It looks like this now
Screenshot from 2025-12-18 13-48-51

@fkiraly
Copy link
Collaborator

fkiraly commented Dec 20, 2025

how would I filter by a specific object_type? That is not a boolean.

- Build tag options for string-valued tags as key=value (e.g., object_type=distribution)
- Update filter logic to parse key=value options and match equality
- Keep boolean tag filtering unchanged

This lets reviewers filter by a specific object_type even when tags are not boolean.
…d tags

- Tag filter now supports key=value options for non-boolean tags (e.g., object_type=distribution)
- Builds string tag value pairs in initialization; boolean tags remain unchanged
- Filter logic parses key=value and matches equality; boolean tags require True

Allows filtering by specific object_type values directly in the estimator overview page.
@arnavk23
Copy link
Contributor Author

how would I filter by a specific object_type? That is not a boolean.

Implemented object_type filtering as requested. In the overview, Tags now support non-boolean values via key=value options (e.g., select “object_type=distribution”). The filter treats:

  • boolean tags: included when True
  • string tags: match on equality for key=value
    The existing “Estimator Type” dropdown still works; the new tag option lets you filter directly by specific [object_type] values alongside other tags.

@fkiraly
Copy link
Collaborator

fkiraly commented Dec 21, 2025

quick question: have you looked at the design in sktime? Any reason to do this differently for skpro? It would be great if you could make a quick comparison and explain why you approach this differently, and which parts of your approach you consider improvements, and which part of sktime estimator overview you consider better?

@arnavk23
Copy link
Contributor Author

quick question: have you looked at the design in sktime? Any reason to do this differently for skpro? It would be great if you could make a quick comparison and explain why you approach this differently, and which parts of your approach you consider improvements, and which part of sktime estimator overview you consider better?

Why I took this approach?
Grid layout — Card-based UI is more visually scannable than dense tables
Support for non-boolean tags — We handle key=value filtering (e.g., [object_type=distribution]), not just boolean flags
Real-time search + filtering — Search applies across name and module simultaneously
Clean separation — Type filter (dropdown) separate from tag filters (multi-select)
Tag display — Shows all tag values visually (key: value), not just checkboxes

Why I didn't take sktime approach?
Table-based UI — Can feel dense with many columns/rows
Limited styling — Basic HTML table, less visually appealing
String-only tag values — Mixed with boolean capabilities

…oration

Improvements inspired by sktime design patterns:

1. **URL hash state persistence**: Filter state (type, search, tags) saved to URL hash
   - Users can bookmark/share filter configurations
   - restoreFilterState() restores from URL on page load
   - saveFilterState() updates hash on any filter change

2. **Type-specific tag filtering**: Tags shown depend on selected object_type
   - TAG_CONFIG maps object_type to valid tags
   - initializeTags() rebuilds tag options when type changes
   - Cleaner UI: only relevant tags displayed

3. **Type change handler**: When estimator type changes, tags are regenerated
   - Prevents stale tags when switching types
   - Ensures selected tags stay valid

Both test_overview.html and docs/source/estimator_overview.rst updated with same logic.
@arnavk23
Copy link
Contributor Author

@fkiraly please try this out. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Documentation & tutorials

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[ENH] add an estimator overview like in sktime

2 participants