Possible orders computing efficiency #34
Comments
stephanzwicknagl
changed the title
stephanzwicknagl
added a commit
that referenced
this issue
Feb 21, 2024
This commit adds minimization support to the viASP cli and the python API. The available options are equivalent to clingo. They are passed on to the clingo control object to be tasked with optimization. The graph creation has been optimized to be more efficient. Programs with many rules and correspondingly many possible sorts are now created on demand. This is done by generating only the graph from the primary sort in the beginning. All possible sorts are calculated and stored in the database. When the frontend requests a graph for one of the possible sorts, it is created while the frontend shows a loading animation. All data is stored in the sqlite database. It is created and destroyed when the server is started and stopped. Resolves: #34
stephanzwicknagl
added a commit
that referenced
this issue
Apr 13, 2024
This commit adds the first elements for an efficient (lazy) generation of possible orders for transformations. Contributes: #34
stephanzwicknagl
added a commit
that referenced
this issue
Apr 16, 2024
This approach prevents a huge computational load at the beginning of the rendering process. Possible orders are calculated 'lazily', i.e. when needed. Upon the initial rendering of the graph, each component (transformation) is analyzed in the current (primary) sort order. If the component can be placed at a different index with all other transformations in the same order, this new order is called "adjacent" to the current order. This index is stored in a component's adjacent_sort_indices attribute. Additionally the hash of this new order is generated and stored in a the graphs database table. A database table "graph_relations" stores this adjacency relation between the (current) graph's hash and the adjacent graph's hash. The frontend doesn't fetch possible orders directly, instead it follows the possible orders defined in the component's attributes. When the user drags a component to a new index, the new index is compared to the list of possible indices in the component's adjacent_sort_indices attribute. If the new index is in the list of possible indices, the component is repositioned and the information about the moved component is sent to the backend. The backend then calculates the adjacent_sort_indices for the new order. Contributes: #34
stephanzwicknagl
added a commit
that referenced
this issue
Apr 22, 2024
The rule container can be stored in the database, so that the input program does never need to be parsed again. The Container has both the AST representation as well as the string representation of the rules. When the dependency graph is generated, the RuleContainer is created from the input AST. A rule container can then be merged with another to remove cycles/loops in the graph. A component of the viasp graph then contains a RuleContainer. This commit contains changes to the whole codebase to reflect the new Container. Tests are updated. Contributes: #34
stephanzwicknagl
added a commit
that referenced
this issue
Apr 22, 2024
More efficient way to store the possible indices of a transformation. Contributes: #34
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
All possible orders of the components of the program as well as the corresponding viasp graphs are calculated in preparation for the dragging of rules.
Efficiency issue: in a program with
nindependent rules, there aren!possible orders of the rules, thusn!graphs. But a reordering does not always mean that the nodes attached to the component change.The calculation of possible orders can be simplified by an analysis of the heads of the rules.
E.g.
and
The text was updated successfully, but these errors were encountered: