Replies: 2 comments
-
I recall pointing out container type during development here, but there was no opinion against the ndarray. Personally, I would have preferred a list, but I did not want to block the PR from being merged. (The PR was opened in July 2020 and merged in Aug 2021.) Moving forward, I can see being less restrictive, i.e. return a "Sequence of strings", but we would need to be careful to maintain backward compatibility. |
Beta Was this translation helpful? Give feedback.
-
Thanks @thomasjpfan -- Undoubtedly getting it in was the right choice since this is a much needed feature. I was curious about this since I'm one of the developers of a scikit-learn compatible package (InterpretML) that has been using feature names for several years since it's critical for interpretability. We've snapped the rest of our interface to the SLEP007 spec, except for this one aspect. I think for now I'll choose the lazy route and leave our interface slightly incompatible and see if anyone raises an issue. Thanks for the insight into how this evolved. |
Beta Was this translation helpful? Give feedback.
-
I'm wondering why the spec for feature_names_in_ and get_feature_names_out() in SLEP007 requires using a 1D numpy array of objects instead of a list? It seems to me the numpy array would be slightly more verbose to create & use, require slightly more memory, and be slightly slower than the built in datatype. Admittedly, these are all minor points, but I couldn't think of any benefits.
https://scikit-learn-enhancement-proposals.readthedocs.io/en/latest/slep007/proposal.html
Beta Was this translation helpful? Give feedback.
All reactions