Hey Johan, The problem is that we want finite enumerated sets to be hashable, picklable, and unique as they get used as keys for CombinatorialFreeModule, among other things, and it is implemented using UniqueRepresentation. The problem is that 1 = 1 with the same hash value whether in ZZ or GF(97), so the enumerated set is the same. However, I would not regard this as a bug, but a "feature" of the unique behavior and the coercion framework.
My guess is that you are treating the finite enumerated set as a tuple, and so I would suggest that you just used tuples (which has far less overhead). Best, Travis On Wednesday, November 2, 2016 at 12:45:21 PM UTC-5, Johan S. H. Rosenkilde wrote: > > Hi all, > > I just tracked down a nasty bug completely messing up my experiments to > this internal caching mechanism. In a clean Sage type: > > sage: E = FiniteEnumeratedSet([ GF(97)(i) for i in [1,2,3,4,5,6]]) > sage: type(E[0]) > <type 'sage.rings.finite_rings.integer_mod.IntegerMod_int'> > > Restart Sage and type instead > > sage: E = FiniteEnumeratedSet([1,2,3,4,5,6]) > sage: type(E[0]) > <type 'sage.rings.integer.Integer'> > sage: E = FiniteEnumeratedSet([ GF(97)(i) for i in [1,2,3,4,5,6]]); > type(E[0]) > <type 'sage.rings.integer.Integer'> > > Many variations of this theme seem possible. > > This was Sage 7.5.beta0. > > Someone knowledgeable can help find the cause and possible other places > the bug could appear? > > Best, > Johan > -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
