You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems that if the integration between the new data structures required to support multicol indexing and the existing acset machinery can be figured out, only 4 methods need to have new versions written. Assume that for each span that is being indexed, some kind of generalized dict is storing the multicol preimage, going from the legs of the span to the apex.
set_subpart!: along with clear_subpart!, these two do not add or remove keys, because elements are not added/subtracted from the object sets. This method will add a value to the set associated with a certain key, if all the subpart values (homs) in the row are assigned to valid parts in the legs. This extra logic is run after the normal set_subpart! is run on the acset.
clear_subpart!: After running normal clear_subpart! we need to remove the row (part) associated to the subpart from the values before running the normal clear_subpart!.
add_part!: along with rem_part!, these two will add or remove keys, if elements are added or subtracted from the object sets in the legs of the indexed span; if the changes occur to the object set of the apex, nothing needs to be done. add_part! needs to add keys associated with empty sets for values for each of the combinations of the other indexed legs, and for the new part id that will be associated to the new part. After that, the normal add_part! can run on the acset.
rem_part!: This needs to remove all keys containing the id of the part in the legs that will be removed. After that the normal rem_part! can be run on the acset.
The main question is what kind of "wrapping structure" to hold the indexed spans should surround the acset, such that we have to do a minimum of work to integrate with the existing code.
The text was updated successfully, but these errors were encountered:
Playing around with ideas related to AlgebraicJulia#17
It seems that if the integration between the new data structures required to support multicol indexing and the existing acset machinery can be figured out, only 4 methods need to have new versions written. Assume that for each span that is being indexed, some kind of generalized dict is storing the multicol preimage, going from the legs of the span to the apex.
set_subpart!
: along withclear_subpart!
, these two do not add or remove keys, because elements are not added/subtracted from the object sets. This method will add a value to the set associated with a certain key, if all the subpart values (homs) in the row are assigned to valid parts in the legs. This extra logic is run after the normalset_subpart!
is run on the acset.clear_subpart!
: After running normalclear_subpart!
we need to remove the row (part) associated to the subpart from the values before running the normalclear_subpart!
.add_part!
: along withrem_part!
, these two will add or remove keys, if elements are added or subtracted from the object sets in the legs of the indexed span; if the changes occur to the object set of the apex, nothing needs to be done.add_part!
needs to add keys associated with empty sets for values for each of the combinations of the other indexed legs, and for the new part id that will be associated to the new part. After that, the normaladd_part!
can run on the acset.rem_part!
: This needs to remove all keys containing the id of the part in the legs that will be removed. After that the normalrem_part!
can be run on the acset.The main question is what kind of "wrapping structure" to hold the indexed spans should surround the acset, such that we have to do a minimum of work to integrate with the existing code.
The text was updated successfully, but these errors were encountered: