-
Notifications
You must be signed in to change notification settings - Fork 74
[DOC] interactive estimator overview page #683
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
[DOC] interactive estimator overview page #683
Conversation
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
Updated comments to clarify conversion from skpro to ngboost event conventions.
fkiraly
left a comment
There was a problem hiding this 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
skproare 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, thanks - but you need to test the overview yourself before you request a review. Have you looked at it?
|
- 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"
|
@fkiraly Can you review this pr again. It looks like this now |
|
how would I filter by a specific |
- 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.
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:
|
|
quick question: have you looked at the design in |
Why I took this approach? Why I didn't take sktime approach? |
…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.
|
@fkiraly please try this out. Thanks! |


Reference Issues/PRs
Fixes #248
What does this implement/fix? Explain your changes.
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
How to: add yourself to the all-contributors file in the
skproroot directory (not theCONTRIBUTORS.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 pluscodeif you also fixed the bug in the PR).maintenance- CI, test framework, release.See here for full badge reference
For new estimators
docs/source/api_reference/taskname.rst, follow the pattern.Examplessection.python_dependenciestag and ensureddependency isolation, see the estimator dependencies guide.