On Monday, September 22, 2014 11:37:13 PM UTC-7, Clemens Heuberger wrote: > > the problem is that the labels of a state could be any hashable Sage > object. > Thus preprocessing this single case of Frac(QQ[x]) would be quite ugly > IMHO and > would not address the underlying problem. >
The Frac(QQ[x]) case is really a bug. See http://trac.sagemath.org/ticket/16268. Probably the denominator there should be made monic (that works also for Frac(K[x]) where K is not a field of fractions of a PID). If we want to compute in Frac(R[x]) where R = ZZ[sqrt(-5)] we'd need some more tricks; probably multiply numerator and denominator so that the denominator is a polynomial over ZZ with content 1. The more general problem will not be resolved: sage: GF(3)(1) == GF(5)(1) False sage: GF(3)(1) == ZZ(1) True sage: GF(5)(1) == ZZ(1) True sage: set([ZZ(1),GF(3)(1),GF(5)(1)]) {1} sage: set([GF(3)(1),ZZ(1),GF(5)(1)]) {1, 1} This is a consequence of automatic coercions that have to be in place for many users to feel that sage is not placing undue notational burden on them. As a consequence, you see that you cannot expect to be able to use {ZZ(1), GF(3)(1),GF(5)(1)} as label set. Using other data structures is not going to solve that problem. Just document that people should be choosing their labels from a uniform universe; enforce it if you feel like being pedantic (possibly in a good way). -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
