Salut Nicolas,
thanks for your detailed answer!
I implemented, as you suggested, a universal cyclotomic field. The
problem is that this causes dependencies between basis elements. These
are as follows:
- if p divides n: [ ( p*n, p*k ) for (n,k) in ZumbroichBasis( n, 1 ) ]
is contained in ZumbroichBasis( p*n, 1 ).
- if p does not divide n: ZumbroichBasis( p*n, 1 ) == [ ( p*n, n*i
+p*k ) for i in range(1,p) for (n,k) in ZumbroichBasis( n, 1 ) ]
The first case would not be too hard to handle by deleting redundant
basis elements, but the second gives us dependencies which I don't
know how to handle smoothly.
Maybe it is the best to keep the redundencies in the basis but not
using the redundent elements when describing linear combinations of
roots of unity (i.e., always returning some linear combinations in the
smallest cyclotomic field QQ(\zeta_n) containing the element ).
An example of the problem is n=3, p=2: at the moment E(6) returns the
element { (6,1) : 1 } where (6,1) is the basis element and 1 is the
multiplicity; but E(6) == -E(3)^2, so we should want that E(6) returns
the element { (3,2), -1 } (as it is living in a smaller cyclotomic
field).
Working with different cyclotomic fields CF(n) together with coersion
from CF(m) to CF(n) if m divides n would not cause this problem:
E(k)*E(l) would live in E( lcm( k, l ) ) (analogously for linear
combinations) and then a simple base check could "push the element
down" to the smallest subfield E( ? ) contained in E( lcm( k, l ) ) in
which E(k)*E(l) lives. If we don't work with different field, I could
try to mimic this behavior.
There are still some things which do not work or which I don't
understand:
1. if I want to use the category Fields as well, I get the following
TypeError:
TypeError: metaclass conflict: the metaclass of a derived class
must be a (non-strict) subclass of the metaclasses of all its bases
2. In this context: how do I define the inverse of a basis element?
3. the __div__ method in the Element class seem to explain how
division by coefficients should work, not how basis elements interact,
right?
4. the embedding into CC does not yet work: in the constructor, I
define the following module_morphism:
def on_basis( x ):
return (2 * CLF.pi() * CLF.gen() * x[1] /x[0]).exp()
g = self.module_morphism( on_basis=on_basis, codomain=CLF )
self.register_embedding( g )
but this morphism returns an error:
sage: F = UniversalCyclotomicField()
sage: CC( E(6) )
TypeError: unsupported operand parent(s) for '+': 'Complex Lazy
Field' and '<type 'NoneType'>'
5. I was not able to define a containment test for the basis of
UniversalCyclotomicField(): I don't know which method is called when
running "x in UniversalCyclotomicField().basis()". It seems not to be
__contains__ or _is_a.
Thanks again - Christian
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To post to this group, send email to sage-combinat-de...@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
