-
Notifications
You must be signed in to change notification settings - Fork 87
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
Unify Graph class hierarchy #750
Conversation
NodePostprocessCallable = Callable[[Graph, Sequence[GraphNode]], Any] | ||
|
||
|
||
class GraphOperator(Graph, Copyable): |
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.
Тут стоит надо пояснить, зачем GraphOperator нужен.
И его название точно актуально? Просто ниже у тебя есть
GraphImpl = GraphOperator
что усложняет понимание разницы между GraphOperator/Graph.
Мб их надо назвать Graph/AbstactGraph?
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.
Да, переименую перед мержем. Или маленьким отдельным PR — чтобы этот не засорять кучей мелких изменений.
GraphOperator не очень актуален, но опять же — это чтобы пока поменьше несущественных изменений видеть.
fedot/core/dag/graph.py
Outdated
def __eq__(self, other) -> bool: | ||
return self.operator.is_graph_equal(other) | ||
# return self.operator.is_graph_equal(other) |
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.
вероятно забывашка
ea3ccce
to
56c785a
Compare
Codecov Report
@@ Coverage Diff @@
## master #750 +/- ##
==========================================
- Coverage 87.40% 87.39% -0.02%
==========================================
Files 192 193 +1
Lines 13299 13230 -69
==========================================
- Hits 11624 11562 -62
+ Misses 1675 1668 -7
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
bd48e74
to
c03ddd2
Compare
That's an important PR that starts big changes in the core of the core: Graph hierarchy design.
My analysis of the current situation with Graphs:
There is a lot of explicit functionality that tries to achieve the following points:
Yet this approach is not without its problems:
Same points can be achieved with a cleaner design: What previously was done manually (sharing of graph implementation between OptGraph & Graph through the GraphOperator) could be actually encoded in class hierarchy. So now instead of runtime transformations and delegation to GraphOperator everything is encoded in class hierarchy, while implementation details are hidden behind opaque Graph interface.
Additional benefits:
The continuation of this work will be #742 . Place of Adapters will be preserved and we still will be able to optimise completely foreign structures -- as far as they can be translated to Graph. But now framework users will have additional choice: if their optimised structure conforms to the Graph interface, no adaptation is required, as Optimiser will work through the Graph interface.
Specific notes on my proposed changes:
self.operator
self.log
to Graph -- could remove it after Logger as Singleton #622, and just make it an alias of GraphDelegateCopyable
mixin-class. GraphDelegate & GraphOperator inherit from it. (that's instead of direct impl of copy & deepcopy in OptGraph)DEFAULT_PARAMS_STUB
in OptNode and slightly refactor handling of itFixes #741