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.
