Add this line after your code: sage: CC.register_coercion(L.embeddings(CC)[0])
(note that L.embeddings(CC) is a list of all 4 embeddings. You may prefer one of the others.) Now we can do sage: CC(s) -1.73205080756888 which is possibly not the sqrt(3) you had in mind. I don't know if it is possible to "forget" that coercion without redefining L: sage: L.<s> = Z.extension(X^2-n) sage: CC.register_coercion(L.embeddings(CC)[2]) sage: CC(s) 1.73205080756888 - 1.11022302462516e-16*I John On 15 April 2013 20:27, GaryMak <[email protected]> wrote: > Hi everyone > > I am doing some calcs involving n-th roots of unity and the square root of > n, all viewed ultimately as complex numbers (where n is any positive > integer). Everything is of course fine if sqrt(n) is in QQ(zeta_n), and > everything is also fine for other n except that if I wish to step out of the > number field situation and evaluate things as complexes, I begin to get > embedding errors which I do not understand. I have tried at least a dozen > completely different approaches based on the manual, but in vain. In short, > here is an example: > > n = 3 > Z.<z> = CyclotomicField(n) > LX.<X> = Z[] > L.<s> = Z.extension(X^2-n) > > Now, if I check that everything is in order inside L, it all seems fine at > this stage - for example > > s in L > z in L > > both return 'True' and moreover both behave as per their defining equations. > The problem arises as soon as I try to manipulate anything involving 's' as > a complex number, for example even the trivial > > CC(s) > > returns > > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > File "_sage_input_59.py", line 10, in <module> > exec compile(u'open("___code___.py","w").write("# -*- coding: utf-8 > -*-\\n" + > _support_.preparse_worksheet_cell(base64.b64decode("Q0Mocyk="),globals())+"\\n"); > execfile(os.path.abspath("___code___.py")) > File "", line 1, in <module> > > File "/tmp/tmpfVbXx5/___code___.py", line 2, in <module> > exec compile(u'CC(s) > File "", line 1, in <module> > > File > "/home/sage/sage-5.7/local/lib/python2.7/site-packages/sage/rings/complex_field.py", > line 277, in __call__ > return Parent.__call__(self, x) > File "parent.pyx", line 834, in sage.structure.parent.Parent.__call__ > (sage/structure/parent.c:7415) > File "coerce_maps.pyx", line 82, in > sage.structure.coerce_maps.DefaultConvertMap_unique._call_ > (sage/structure/coerce_maps.c:3583) > File "coerce_maps.pyx", line 77, in > sage.structure.coerce_maps.DefaultConvertMap_unique._call_ > (sage/structure/coerce_maps.c:3485) > File > "/home/sage/sage-5.7/local/lib/python2.7/site-packages/sage/rings/complex_field.py", > line 308, in _element_constructor_ > return complex_number.ComplexNumber(self, x) > File "complex_number.pyx", line 162, in > sage.rings.complex_number.ComplexNumber.__init__ > (sage/rings/complex_number.c:3647) > File "parent.pyx", line 834, in sage.structure.parent.Parent.__call__ > (sage/structure/parent.c:7415) > File "coerce_maps.pyx", line 156, in > sage.structure.coerce_maps.NamedConvertMap._call_ > (sage/structure/coerce_maps.c:4593) > File "number_field_element.pyx", line 1333, in > sage.rings.number_field.number_field_element.NumberFieldElement._mpfr_ > (sage/rings/number_field/number_field_element.cpp:11441) > File "parent.pyx", line 834, in sage.structure.parent.Parent.__call__ > (sage/structure/parent.c:7415) > File "coerce_maps.pyx", line 82, in > sage.structure.coerce_maps.DefaultConvertMap_unique._call_ > (sage/structure/coerce_maps.c:3583) > File "coerce_maps.pyx", line 77, in > sage.structure.coerce_maps.DefaultConvertMap_unique._call_ > (sage/structure/coerce_maps.c:3485) > File > "/home/sage/sage-5.7/local/lib/python2.7/site-packages/sage/rings/number_field/number_field.py", > line 8058, in _element_constructor_ > return NumberField_absolute._element_constructor_(self, x) > File > "/home/sage/sage-5.7/local/lib/python2.7/site-packages/sage/rings/number_field/number_field.py", > line 1230, in _element_constructor_ > return self._coerce_from_other_number_field(x) > File > "/home/sage/sage-5.7/local/lib/python2.7/site-packages/sage/rings/number_field/number_field.py", > line 5671, in _coerce_from_other_number_field > raise ValueError, "Cannot convert %s to %s (regardless of > embeddings)"%(x,K) > ValueError: Cannot convert s to Cyclotomic Field of order 3 and degree 2 > (regardless of embeddings) > > > Of course I would understand this if I were trying to coerce s naively into > Z, but I cannot understand why this is happening in this situation (since > SAGE seems quite happy with s being a member of L, ergo I would have thought > that it would have some appropriate complex embedding 'in mind' ...). I have > tried to use embeddings and extensions in various guises, but to no avail. > Also I would like to use the machinery SAGE has for handling cyclotomic > numbers, so I would prefer not to have to define this by first looking up > the cyclotomic polynomial and defining the number field using two explicit > equations etc. > > Many thanks for any suggestions ... > > -- > You received this message because you are subscribed to the Google Groups > "sage-support" 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 http://groups.google.com/group/sage-support?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "sage-support" 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 http://groups.google.com/group/sage-support?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
