Allow components which are not "leaf" children in the class hierarchy
See original GitHub issueIn working on #1989, @freddyaboulton suggested that we make TargetImputer
a subclass of SimpleImputer
. Unfortunately, when looking for viable components in _get_subclasses
, _get_subclasses
will only collect classes that are at the very bottom of the hierarchy. For example:
ComponentBase --> Transformer --> SimpleImputer # will only grab SimpleImputer
The issue is, if we subclass SimpleImputer, we will have access to TargetImputer, but SimpleImputer
will no longer be found by EvalML as a useable component:
ComponentBase --> Transformer --> SimpleImputer --> TargetImputer
# will only grab TargetImputer, SimpleImputer is no longer a leaf
I believe the original intent is to not grab classes that are not useful (ex: Transformer), but this is a problem if we want to build upon useful components to create new ones.
Original comment here: https://github.com/alteryx/evalml/pull/1989#discussion_r599894996
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (4 by maintainers)
Top Results From Across the Web
CMSC 420: Lecture 5
Every leaf (external node) has exactly 0 children. Each external node corresponds to one Λ in the original tree – let's us distinguish...
Read more >Tree (data structure) - Wikipedia
In computer science, a tree is a widely used abstract data type that represents a hierarchical tree structure with a set of connected...
Read more >Composite Design Pattern - GeeksforGeeks
2) leaf – leaf means it has no objects below it. Tree structure: Tree The above figure shows a typical Composite object structure....
Read more >Everything you need to know about tree data structures
Trees are well-known as a non-linear data structure. They don't store data in a linear way. They organize data hierarchically. Let's dive into ......
Read more >Hierarchical injectors - Angular
Hierarchical dependency injection enables you to share dependencies between different parts of the application only when and if you need to.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Agreed with @freddyaboulton here, also worth noting that we defined
_get_subclasses()
in the first place because keeping track of a static list of components was a bit tedious / frustrating as we were adding more and more components. If we go for 3, it might make more sense to keep_get_subclasses()
but also keep a list of “exceptions” such as the SimpleImputer / TargetImputer case, so that they’re included, but other components such as theTransformer
are still excluded.Also okay with the idea of some composition-esque technique if that gets the job done.
My opinion is that we shouldn’t change anything unless we want to make inheritance of non base classes a more common pattern in our codebase. We currently don’t do that so building a system to allow for that seems low priority to me.
This issue isn’t blocking the target imputer or any short-term work we have ahead of us and the current system for identifying subclasses “works”. If we really want 3 then that’s another story hehe and I’d be down to hear arguments for it but I don’t think there’s a need to do it.
And if we wanted to leverage the SimpleImputer in the TargetImputer in the future we can use composition over inheritance, which I think is what option 1 is referring to.