Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "VIATRA/Query/DeveloperDocumentation/LocalSearch"
(Created page with " == Local Search == This page summarizes the improvement ideas concerning the local search-based pattern matching capabilites of EMF-IncQuery. * Hybrid pattern matching: **...") |
(→Local Search) |
||
| Line 6: | Line 6: | ||
* Hybrid pattern matching: | * Hybrid pattern matching: | ||
** New ISearchOperation to support calling an incremental matcher | ** New ISearchOperation to support calling an incremental matcher | ||
| − | ** Provide input for the flattener: which patterns should NOT be flattened. Implement this by creating an interface with a method that expects a constraint and a pattern. | + | ** <s>Provide input for the flattener: which patterns should NOT be flattened. Implement this by creating an interface with a method that expects a constraint and a pattern.</s> (Interface added) |
* Implement a weight function to estimate the cost of a given search plan over a model | * Implement a weight function to estimate the cost of a given search plan over a model | ||
* Learning algorithm: the planner shall be able to tune its internal parameters regarding the planning process. This could be done by providing (small) example models and measuring pattern matching performance. | * Learning algorithm: the planner shall be able to tune its internal parameters regarding the planning process. This could be done by providing (small) example models and measuring pattern matching performance. | ||
Revision as of 10:46, 28 April 2015
Local Search
This page summarizes the improvement ideas concerning the local search-based pattern matching capabilites of EMF-IncQuery.
- Hybrid pattern matching:
- New ISearchOperation to support calling an incremental matcher
-
Provide input for the flattener: which patterns should NOT be flattened. Implement this by creating an interface with a method that expects a constraint and a pattern.(Interface added)
- Implement a weight function to estimate the cost of a given search plan over a model
- Learning algorithm: the planner shall be able to tune its internal parameters regarding the planning process. This could be done by providing (small) example models and measuring pattern matching performance.
- Provide a low-level code generator: instead of the current execution method, that is based on sequential exectuion of ISearchOperations contained in plans, generate executable code. This might be in a form of several embedded for loops and if conditions.
- Support the POperationCompiler with normalization capability to remove redundant constraints thus decrease the search plan size.
- Investigate if new IQPL elements (e.g. containment) should be added that are only supported by either the local search-based or the RETE algorithm.
- Support parallelism for plan execution. For example, the search graph traversal can be done simultaneously starting from different nodes.