On Wednesday, November 2, 2016 at 2:02:18 PM UTC-7, Johan S. H. Rosenkilde
wrote:
>
> Hi Travis,
>
> From my point of view, this can only be considered a bug: extremely
> surprising behaviour leading to subtle problems in user code (my code).
> Possibly, the bug is higher up than FiniteEnumeratedSets, though.
>
> I'll explain: This came about when using Subsets. Basically, I'm doing
> something like:
>
> for S in Subsets(GF(13).list(), 5):
> if sum(S) == 1:
> print "Monkey"
>
This may or may not be a bug; I'll let others answer that. For a
workaround, use
for S in Subsets(GF(13), 5): ... -- don't use GF(13).list(), just use
GF(13)
I don't know exactly how FiniteEnumerateSet enters into things:
sage: FiniteEnumeratedSet(GF(13)) == FiniteEnumeratedSet(range(13))
True
sage: Subsets(GF(13)) == Subsets(range(13))
False
sage: Subsets(GF(13).list()) == Subsets(range(13))
True
--
John
>
> This code works as expected and prints monkeys galore when evaluating it
> in a Sage shell. Now restart Sage and call the following line before
> calling the above snippet:
>
> a = list(Subsets(range(13), 5))
>
> And suddenly the first code snippet will never print anything.
>
> Tell me that's not a bug!
>
> Best,
> Johan
>
> Travis Scrimshaw writes:
>
> > 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.
