> > and whether it's okay to restrict S to be tree-like during the > > intermediate steps. It is probably simpler to just drop the cycle > > version and think only of trees, but I want to make sure I understand > > how the primitive patch theory's commuting rules turn into tree > > transformations. > > Why are you so hung up on this tree / cycle thing? What is wrong about > your original context addresses and patch (sequence) adresses? If > efficiency is the concern, we are talking about a factor of two here. > This is irrelevant. For the theory you need to get the asymptotics > right, the rest are implementation details. > > Cheers > Ben
Sorry for the long silence; I was distracted by other things. I'm hoping to take some time soon to review the thread and respond to parts of it. To respond to your quoted question above: I was concerned my "canonical context address" representation of patches might not make enough things equivalent, i.e. distinguish things that shouldn't be distinguished. This came up when we talked about inverses: we need to add some rule in order to guarantee that the starting context of A^ equals the ending context of A. When I raised the concern, you suggested* "with inversion added, every context address has two minimal forms: forward and backward, and these denote the same extended context." I was concerned that adding just that one new kind of equivalence might not be enough. But I didn't think it through carefully. Honestly I thought the cycle representation seemed kind of neat, but I guess I don't really have a justification for it right now. *https://lists.osuosl.org/pipermail/darcs-users/2020-July/027434.html James _______________________________________________ darcs-users mailing list darcs-users@osuosl.org https://lists.osuosl.org/mailman/listinfo/darcs-users