> I'm running into a coercion problem. I'm trying to define a class
> SteenrodAlgebra (based on the Algebra class); there should be one
> Steenrod algebra for each prime number p, and it is an algebra over
> GF(p). For example, you can do
>
> sage: A5 = SteenrodAlgebra(5)
> sage: A7 = SteenrodAlgebra(7)
I just tried these lines, where do I import SteenrodAlgebra from? (Or
is it not in standard Sage yet?)
Yes, Sage caches some information so it doesn't have to do the logic
anew on each arithmetic operation. One thing to check is if A5 == A7
succeeds. If you could post the traceback I could see if anything
stands out to me.
- Robert
Ah, it looks like your __eq__ method is assuming that self and other
are elements of the steenrod algebra. There are two solutions to this:
1) Use __cmp__ which (in Sage) will ensure that self and other have
the same parent before it's called
2) Fix your __eq__ (and any other comparison methods you might have)
to make sure self-other makes sense (or, as a quick fix, catch the
type error here).
- Robert
I'm not seeing where the gen method is being used--it's probably to
get a "generic" element to see if multiplication is a viable option.
As for elements of SteenrodAlgebra(7) and SteenrodAlgebra(5) getting
compared, that's because it's looking up something in a (global-ish)
lookup table that happens to have SteenrodAlgebra(5) in it as well.
Obviously equality here should return False.
- Robert
Here is what happens. When it's trying to figure out how to do
arithmetic between to sets, say ZZ and A5, it wants to know if ZZ
acts on A5 (or, conversely, if A5 acts on ZZ). To do this it needs to
get elements of A5 and ZZ to see if they have _rmul_ and/or _lmul_
methods, so it calls _an_element_c_impl whose generic code tries
calling gen. (Note, this is in the current model, names have changed
a bit, but the general idea is still there). This only happens once,
from then on the action (or non-existence of the action) is cached
for lookup every time two elements of that kind are encountered.
There is much more documentation and introspection in the new model,
so hopefully things will be a lot less confusing.
- Robert
Yes, though that will mean something like A5.P(2) - A5.P(2) == 0 will
return False. This is why you are better off using _cmp_ instead of
__eq__, __ne__, __le__, __gt__, ... (also, the latter are deprecated
in Python). The _cmp_ method will always be called with two things of
the same parent, invoking coercion if necessary.
- Robert
What does A5 == A7 give you? Can you do A5.P(2) == A7.P(2)? I'm not
sure exactly what's going on here, but as long as the above is
working well enough for now it's probably worth holding off debugging
too much until the new coercion is in place (which is more likely
than not to resolve this).
- Robert