Thanks. I think I have it figured out now. The current construction passes to the face lattice the ID of self as a key. This is why F1 and F2 are not identical.
Basically, I can just do it like this. Now, if I understand it correctly: Face lattice as it is, should not be cached. Instead its probably fine to store the version with indices and convert on each call. Or the DiGraph. Just not the FiniteLatticePoset with labels that point to self. Am Mittwoch, 30. Oktober 2019 21:11:54 UTC+1 schrieb Nils Bruin: > > I haven't dug very deep into this, but the following looks suspicious: > > sage: o1 = lattice_polytope.cross_polytope(3) > sage: o2 = lattice_polytope.cross_polytope(3) > sage: o1==o2 > True > sage: o1 is o2 > False > > This in itself isn't a problem, but o1.face_lattice() is a > UniqueRepresentation object. That means that if you create two > face_lattice() structures with arguments that are *equal* you'll get back > *identical* lattices. That means you get: > > sage: o1 = lattice_polytope.cross_polytope(3) > sage: F1 = o.face_lattice() > sage: G1 = F1.relabel(F1._elements) > sage: o2 = lattice_polytope.cross_polytope(3) > sage: F2 = o2.face_lattice() > sage: G2 = F2.relabel(F2._elements) > sage: G1 is G2 > True > > Interestingly: > > sage: F1 is F2 > False > > so something is sufficiently different between the construction parameters > of F1 and F2 to return different structures. > > Because the unique representation cache will store G1, the construction of > G2 will get you back G1. That's as designed. UniqueRepresentation structure > have (A == B) iff (A is B). > > It's always questionable to derive UniqueRepresentation objects from > non-unique ones, although this particular example for F1 and F2 isn't > exhibiting problematic behaviour right here (yet? perhaps it's just the > order or accidental labelling that happens to introduce sufficient > differences?) > > Additionally, "o2.face_lattice()" is cached. If any of the construction > parameters of F2 reference back to o2 -- which it seems to do via "ambient" > there's a memory leak there of the classic "UniqueRepresentation > weak-caching-but-with-value-keeping-keys-alive" kind. Never cache a > UniqueRepresentation object on one of the objects involved in its > construction. > > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/584b2552-b92a-4b31-b23b-deccc2c3b647%40googlegroups.com.
