Skip to content

Conversation

DeaMariaLeon
Copy link
Contributor

@DeaMariaLeon DeaMariaLeon commented Aug 13, 2025

Reference Issues/PRs

Towards #26595

What does this implement/fix? Explain your changes.

This is part of "Display the (public) fitted attributes".

Any other comments?

Example
Screenshot 2025-08-20 at 18 14 43

Copy link

github-actions bot commented Aug 13, 2025

✔️ Linting Passed

All linting checks passed. Your pull request is in excellent shape! ☀️

Generated for commit: 9c93171. Link to the linter CI: here

@DeaMariaLeon DeaMariaLeon changed the title WIP: Display the shape of outgoing data structures WIP: Display the number of outgoing data structures Aug 18, 2025
@DeaMariaLeon DeaMariaLeon changed the title WIP: Display the number of outgoing data structures WIP: Display the number of output features Aug 18, 2025
@DeaMariaLeon DeaMariaLeon marked this pull request as ready for review August 21, 2025 09:03
@DeaMariaLeon
Copy link
Contributor Author

I wonder if I can have feedback before I add/fix more tests.
@glemaitre

@DeaMariaLeon DeaMariaLeon changed the title WIP: Display the number of output features ENH: Display the number of output features Aug 21, 2025
@glemaitre glemaitre self-requested a review August 22, 2025 09:03
@glemaitre
Copy link
Member

I see that we have to handle one specific case:

image

We have an internal PassThrough transformer that forward the input feature as-is and this it means that we should mention that the output feature are the same as n_features_in_.

@jeremiedbb
Copy link
Member

I find the block a bit big, it takes as much space as the estimator itself. I was also thinking that having the input features would be nice but then it really starts to take a lot of space around the estimator. So I wondered if the features could be intermediate blocks in the diagram, representing both the output features from the previous estimator and the input features for the next estimator. Something like this
output_features

This way the diagram alternates estimator blocks and data blocks
Then the text would be different obviously, like "16 features", or even the full shape ?

In addition, in this PR or in a following one, the data block could be unfold to show the feature names if available.

@glemaitre
Copy link
Member

One feedback of @ogrisel IRL is to directly show the feature names using the same pattern than "Parameters".

I personally agree with @jeremiedbb feedback: I would like something smaller. Also write now, we have to mention "output features" instead of simply "features" because of the ambiguity input/output when attached to the estimator. So the proposal to make the "feature" being blocks leaving on their own is nice I think because there is not ambiguity anymore.

@DeaMariaLeon
Copy link
Contributor Author

I'll work on this, thanks for the feedback. Just:

One feedback of @ogrisel IRL is to directly show the feature names using the same pattern than "Parameters".

Should I add the feature names on this PR? I remember @glemaitre saying that they should be added on a separate PR.

@glemaitre
Copy link
Member

Should I add the feature names on this PR?

I want to dissociate it at first but since we are going to create a new block, it might be better to have directly the feature names as well.

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

Successfully merging this pull request may close these issues.

3 participants