Re: [sage-devel] Re: Bug in caching mechanism of FiniteEnumeratedSet
#19562 is probably the best fix, but really that makes FiniteEnumeratedSet not really any different than our (finite) Sequence class. I'm thinking we need some sort of unification long-term. > Also, instead of Subsets(L), I would also use subsets(L) (or powerset(L)) > > as you don't need the set of all subsets to be a parent. > > I see now that those functions don't support an argument for which size > subsets you need (which is critical in my application). > > Then use itertools: sage: import itertools sage: list(itertools.combinations(range(3), 2)) [(0, 1), (0, 2), (1, 2)] Best, Travis -- 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.
Re: [sage-devel] Re: Bug in caching mechanism of FiniteEnumeratedSet
> Travis wrote: > Also, instead of Subsets(L), I would also use subsets(L) (or powerset(L)) > as you don't need the set of all subsets to be a parent. I see now that those functions don't support an argument for which size subsets you need (which is critical in my application). 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.
Re: [sage-devel] Re: Bug in caching mechanism of FiniteEnumeratedSet
Hi everyone, OK, we can bicker about the semantic difference of the words "bug" vs "intentional but bad design" all day, but in the end we agree it's not great for the user. It seems the ever-vigilant Vincent discovered the problem already a year ago and proposed a sensible fix for the problem in #19562. Thanks for the tip with subsets() and powersets(). Unfortunately, John's workaround is brittle since it only supports subsets of the full GF(13). My actual code was closer to: ls = carefully_selected_sublist_of(GF(13).list()) for S in Subsets(ls, 5): if sum(S) == 1: print "Monkey" > Travis wrote: > Sage can't tell apart, e.g., 1 in ZZ (or the int) from 1 in GF(13) due > to coercion when doing equality (and they have the same hash). *Should* they have the same hash? I'm aware I'm setting my toe down in the murky waters of coercion, equality and mathematical equivalence, but isn't it surprising and dangerous even in Sage library code that sets, cached_method, FiniteEnumeratedSets (before #19562), and everything else that depends on hashing to tell objects apart, will not tell 1 in GF(2) apart from 1 in ZZ from 1 in MatrixSpace(RR, 3, 3)? Oh no wait: sage: hash(MatrixSpace(RR, 3, 3).one()) == hash(12) True That seems like an accident waiting to happen. Couldn't we just xor the hash of the parent with the object or something (possibly specially adjusting for parent.zero())? Best, Johan Travis Scrimshaw writes: > On Wednesday, November 2, 2016 at 7:59:42 PM UTC-5, Luca De Feo wrote: >> >> > It is not a bug, but a by product of wanted (with documentation) of the >> > UniqueRepresentation and the coercion system in Sage. More below. >> >> This is a bug. >> >> The fact that it is a consequence of wanted and documented behaviour >> just shows that the wanted behaviour was badly designed (regardless of >> how great and useful it is). >> >> I'm getting dangerously close to the realm of bikeshedding, but bad design > or (very) subtle behavior is not a bug. A bug is incorrect or unintended > results. > > That being said, I'm not opposed to removing the UniqueRepresentation, but > I'd like to hear why this was originally put in place. In many ways, what > you're doing involves additional subtleties due to the coercion framework > being involved behind the scenes (i.e., as far as equality is concerned, 1 > in ZZ == 1 in GF(13)). > > Also, instead of Subsets(L), I would also use subsets(L) (or powerset(L)) > as you don't need the set of all subsets to be a parent. > > Best, > Travis -- -- 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.
Re: [sage-devel] Re: Bug in caching mechanism of FiniteEnumeratedSet
https://trac.sagemath.org/ticket/19562 -- 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.
Re: [sage-devel] Re: Bug in caching mechanism of FiniteEnumeratedSet
On Wednesday, November 2, 2016 at 7:59:42 PM UTC-5, Luca De Feo wrote: > > > It is not a bug, but a by product of wanted (with documentation) of the > > UniqueRepresentation and the coercion system in Sage. More below. > > This is a bug. > > The fact that it is a consequence of wanted and documented behaviour > just shows that the wanted behaviour was badly designed (regardless of > how great and useful it is). > > I'm getting dangerously close to the realm of bikeshedding, but bad design or (very) subtle behavior is not a bug. A bug is incorrect or unintended results. That being said, I'm not opposed to removing the UniqueRepresentation, but I'd like to hear why this was originally put in place. In many ways, what you're doing involves additional subtleties due to the coercion framework being involved behind the scenes (i.e., as far as equality is concerned, 1 in ZZ == 1 in GF(13)). Also, instead of Subsets(L), I would also use subsets(L) (or powerset(L)) as you don't need the set of all subsets to be a parent. Best, Travis -- 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.
Re: [sage-devel] Re: Bug in caching mechanism of FiniteEnumeratedSet
On Wed, 2 Nov 2016, Johan S. H. Rosenkilde wrote: for S in Subsets(GF(13).list(), 5): if sum(S) == 1: print "Monkey" 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! To me it seems to be worst than a bug: intentionally broken design. Something like this is almost impossible to teach in classroom. -- Jori Mäntysalo
Re: [sage-devel] Re: Bug in caching mechanism of FiniteEnumeratedSet
> It is not a bug, but a by product of wanted (with documentation) of the > UniqueRepresentation and the coercion system in Sage. More below. This is a bug. The fact that it is a consequence of wanted and documented behaviour just shows that the wanted behaviour was badly designed (regardless of how great and useful it is). Unpredictable behaviour that can only be understood by someone having as deep a knowledge of Sage internals as Travis has cannot possibly be a "feature". Of course, I have no clue what the fix would be. Luca -- 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.
Re: [sage-devel] Re: Bug in caching mechanism of FiniteEnumeratedSet
Hey Johan, > 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. > It is not a bug, but a by product of wanted (with documentation) of the UniqueRepresentation and the coercion system in Sage. More below. > > 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 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! > >The issue here is that it takes the input and converts it to a FiniteEnumeratdSet, which has unique representation behavior. Sage can't tell apart, e.g., 1 in ZZ (or the int) from 1 in GF(13) due to coercion when doing equality (and they have the same hash). So as far as Sage is concerned, it is the same object, and hence, already constructed. I don't see a reason a priori to keep the unique representation behavior, but perhaps Nicolas knows why this was decided? Until we change that design decision, this would be a "feature" and not a bug. John's workaround is probably the better methodology overall too. Best, Travis -- 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.
Re: [sage-devel] Re: Bug in caching mechanism of FiniteEnumeratedSet
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]) > >> > >> > >> Restart Sage and type instead > >> > >> sage: E = FiniteEnumeratedSet([1,2,3,4,5,6]) > >> sage: type(E[0]) > >> > >> sage: E = FiniteEnumeratedSet([ GF(97)(i) for i in [1,2,3,4,5,6]]); > >> type(E[0]) > >> > >> > >> 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.
Re: [sage-devel] Re: Bug in caching mechanism of FiniteEnumeratedSet
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 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]) >> >> >> Restart Sage and type instead >> >> sage: E = FiniteEnumeratedSet([1,2,3,4,5,6]) >> sage: type(E[0]) >> >> sage: E = FiniteEnumeratedSet([ GF(97)(i) for i in [1,2,3,4,5,6]]); >> type(E[0]) >> >> >> 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.
