On Wednesday, January 20, 2016 at 1:49:12 PM UTC-8, Nathann Cohen wrote: > > If conflicts can come from the choice of a variable name, I'd say that > the problem is not the variable's name but the code that relies on it. >
Conflicts do not arise from variable names (or at least not the conflicts we need to be worried about). It's that the names of generators are part of the identity of a parent in sage: It is expected that for some structure generator S, the result of S(name='a') and of S(name='b') interact differently with other structures in sage. Thus, if we decide the default name is "conway" then GF(p^r) and GF(p^r,'conway') will behave the same (they should be identical objects in fact!), but GF(p^r) and GF(p^r,'x') will behave differently. If we choose dthe default name 'a' then GF(p^r) and GF(p^r,'a') will behave the same but GF(p^r) and GF(p^r,'conway') will behave differently. More insidious is the interaction with names on the other side: if GF were to follow coercion rules properly and 'conway' is a special name, then ZZ['conway'] and GF(p^r) would have a special relation, but ZZ['x'] and GF(p^r) would not. So choosing something like "conway" would indeed be safer. A little further down the line, one would probably want that GF(p^2) coerces into GF(p^4). If we use the same name 'conway' for both generators, then ZZ['conway'] would have a good reason for coercing into both, but obviously in a way that is incompatible with the embedding of GF(p^2) into GF(p^4). So I'd actually suggest to make the order (or at least the degree) part of the default generator name. That'll be more "future proof" wrt coercion improvements. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
