Ask Your Question

daniels's profile - activity

2021-05-29 16:22:48 +0100 received badge  Nice Answer (source)
2021-05-29 16:20:15 +0100 received badge  Nice Answer (source)
2013-01-08 10:06:34 +0100 answered a question Rational reconstruction in ring of integers

If you are thinking of representing them as floating point numbers, in general it will not be possible to represent the exact value, but you can represent it to arbitrary precision. For example, when creating your number field you can pick an embedding into CC like so:

sage: K.<a> = NumberField(x^3 - 2, embedding=1.2)                              
sage: CC(a)
1.25992104989487

This gives you 53-bit of floating point precision. For more precision, you can use a a field with more precision:

sage: CC100 = ComplexField(100)
sage: CC100(a)
1.2599210498948731647672106073

Instead of fixing one embedding upon creating your number field, you can also compute all the embeddings into a given field L with K.embeddings(L), and use one of them explicitly.

The field QQbar represents the algebraic closure of the rationals and allows you to do exact arithmetic with arbitrary algebraic numbers. Depending on what you want to do this may also be suitable for you.

2012-08-08 09:08:09 +0100 commented question From number field to interval field

Looks like a bug to me. `CIF.coerce_map_from(K2)` shows that a sane conversion *should* happen, but then something goes wrong when actually coercing an element.

2012-08-07 19:43:18 +0100 commented question Modular Symbols with Character & Manin Symbols

Hi. Please note that specifying an embedding in such a way does not necessarily imply that your computations will be inexact. By default a NumberField in sage is just an abstract quotient of a polynomial ring. By choosing one of the finitely many embeddings you allow sage e.g. to perform coercions between elements of different number fields. This seems to be happening here: The ModularSymbols code wants to convert an element of your number field to an element in a cylotomic field, but to do this in a canonical fashion an embedding into the complex numbers has to be selected. (Cyclotomic fields of order n by default use the embedding mapping their generator zeta to exp(2*pi*i/n) ). All computations in this coercion are exact.

2012-08-07 16:29:55 +0100 commented question Modular Symbols with Character & Manin Symbols

Can't help with the modular symbols, but the TypeError looks like ModularSymbols wants you to fix an embedding of your number field into the complex numbers. Try creating your number field like this: `K. = NumberField(x^4+2*x^3+2*x^2+4*x+4, embedding = CDF(0.3 - 1.3*i))` this will take the embedding that maps the generator `a` to the root of the defining polynomial that lies closest to the value `embedding`.

2012-08-02 09:09:14 +0100 received badge  Supporter (source)
2012-07-28 10:32:20 +0100 received badge  Teacher (source)
2012-07-28 04:50:26 +0100 commented answer adding real literal and real number of high precision

You can see how it drops from a RealLiteral to an element of RDF once you do operations (the parent() decides where the operation takes place - the RealLiteral is actually stored with all the precision that your input string has): sage: x = 0.3 sage: type(x), x.parent() (<type 'sage.rings.real_mpfr.realliteral'="">, Real Field with 53 bits of precision) sage: y = x + 0.7 sage: type(y), y.parent() (<type 'sage.rings.real_mpfr.realnumber'="">, Real Field with 53 bits of precision)

2012-07-28 04:47:12 +0100 commented answer adding real literal and real number of high precision

Sort of! This is handled by the preparser. I'm certainly not the right person to ask about that but digging around a bit in the source gave me the following, which at least explains how it works, if not why: When the preparser sees a floating point literal it calls RealNumber(s) with `s` the string it sees. This will give you a rings.real_mpfr.RealLiteral object with precision good enough to represent the literal. If you pass this to RF it will make the right element object. But if you start adding it, it has to to that in some field, and by default it takes RDF. So inputing floating point literals is ok, but as soon as you do mathematical ops with them you end up with an element in RDF instead of a RealLiteral. OTOH 1+pi is symbolic in Sage and can be coerced to any precision.

2012-07-27 19:31:31 +0100 answered a question adding real literal and real number of high precision

[This is not really a full answer to your original question but the comment size limit prevents me from posting it as such.]

I don't quite see where the problem should be with the last example: The addition is performed in RDF, giving RDF(1.0) and only after that the conversion of RDF(1.0) to RF happens.

I'll try to explain what's happening as I understand it. First as a remark: The conversion of an element from RDF (53-bits of precision) to RF (RealField with 150-bits of precision) is of course non-canonical. In Sage terms: There is no coercion from RDF to RF, Sage will only automatically coerce from higher precision to lower.

By writing RF(RDF(0.7)) we explicitly ask Sage to convert a lower precision element of RDF to RF anyway, filling up the remaining digits in whatever way it sees fit. I guess this might be the confusing part, because this means that it is not (necessarily) true that RF(RDF(0.3) + RDF(0.7)) = RF(RDF(0.3)) + RF(RDF(0.7)).

If we do RF(0.3+0.7) this is the same as RF(RDF(0.3)+RDF(0.7)), thus the two numbers are added in RDF, giving RDF(1.0), and then converted to RF. If we do on the other hand RF(0.3) + RF(0.7) then 0.3 and 0.7 are interpreted as 150-bit numbers and added in RF (note that they are in fact parsed with the higher precision, they are not first stored as double elements and then converted). Finally and still different, RF(RDF(0.3))+RF(RDF(0.7)) will create the elements with 53-bit precision, then convert them to RF and add them there.

The documentation explains quite nicely how such coercion is performed in general. In particular the explain feature could be interesting for you:

sage: RF = RealField(150)
sage: cm = sage.structure.element.get_coercion_model()
sage: RF(0.3+0.7)
1.0000000000000000000000000000000000000000000
sage: cm.explain(0.3,0.7,add)
Identical parents, arithmetic performed immediately.
Result lives in Real Field with 53 bits of precision
Real Field with 53 bits of precision
sage: RF(RDF(0.3)+RDF(0.7))
1.0000000000000000000000000000000000000000000
sage: cm.explain(RDF(0.3),RDF(0.7),add)
Identical parents, arithmetic performed immediately.
Result lives in Real Double Field
Real Double Field
sage: RF(RDF(0.3)) + RF(RDF(0.3))
0.59999999999999997779553950749686919152736664
sage: cm.explain(RF(RDF(0.3)), RF(RDF(0.7)), add)
Identical parents, arithmetic performed immediately.
Result lives in Real Field with 150 bits of precision
Real Field with 150 bits of precision
sage: RF(0.3) + RDF(0.7)            
1.0
sage: cm.explain(RF(0.3), RDF(0.7), add)
Coercion on left operand via
    Native morphism:
      From: Real Field with 150 bits of precision
      To:   Real Double Field
Arithmetic performed after coercions.
Result lives in Real Double Field
Real Double Field

It may ... (more)

2012-07-27 16:07:49 +0100 commented question adding real literal and real number of high precision

EDIT: my previous comment missed the point of your question. The computation is actually done in double precision both times, but RF(RDF(1.0)) = 1.0000000000000000000000000000000000000000000 while RF(RDF(0.9)) = 0.90000000000000002220446049250313080847263336. Which makes the second addition look like it was done in RF all along.

2012-07-25 09:04:25 +0100 commented question algebraic integer - PARI/GP

You can use that an algebraic number is integral iff its minimal polynomial has integer coefficients. I believe that PARI's minpoly should give you the minimal polynomial starting from a polmod object.

2012-07-20 10:53:47 +0100 received badge  Editor (source)
2012-07-20 09:40:45 +0100 answered a question Computing the order of an ideal in a ray class group

Hi, for many computations in algebraic number theory SAGE uses PARI in the background. It seems to me that the relevant functionality for computing ray class groups (that is present in PARI) is not yet wrapped conveniently in SAGE.

There are two ways to proceed: You could use PARI/GP directly from the command line (the functions you're looking for are basically bnrinit to compute a representation of a ray class group as a product of cyclic groups and bnrisprincipal to compute the image of an ideal in this representation, from which you can get the order). Alternatively, you can use SAGE's GP-Interface to do the same from within SAGE, I'll demonstrate both ways.

First, an example in PARI/GP to demonstrate the basic computation (some output omitted, $\mathfrak m = (3)$ and $K$ has no real archimedean places):

? K = bnfinit(x^6 + 76*x^4 + 2*x^3 + 2029*x^2 - 158*x + 18955)
? bnfcertify(K)
%2 = 1
? Kr = bnrinit(K, [3, []], 1)
? Kr.clgp.cyc
%4 = [6, 6]     # => ray class group is C_6 x C_6
? J = idealhnf(Kr, 5, x^2 + 2*x + 23)
? bnrisprincipal(Kr,J)
%6 = [[4, 4]~, ...]  # image of J in ray class group

The following provides a quick and dirty hack to do basically the same from SAGE, using its PARI/GP Interface:

class RayClassGroup(AbelianGroup_class):
    def __init__(self, number_field, mod_ideal = 1, mod_archimedean = None):
        if mod_archimedean == None:
            mod_archimedean = [0] * len(number_field.real_places())

        bnf = gp(number_field.pari_bnf())
        # Use PARI to compute ray class group
        bnr = bnf.bnrinit([mod_ideal, mod_archimedean],1)
        invariants = bnr[5][2]         # bnr.clgp.cyc
        invariants = [ ZZ(x) for x in invariants ] 

        AbelianGroup_class.__init__(self, len(invariants), invariants)
        self.__number_field = number_field
        self.__bnr = bnr

    def __call__(self, *args, **kwargs):
        return group.Group.__call__(self, *args, **kwargs)

    def _element_constructor_(self, *args, **kwargs):
        if isinstance(args[0], AbelianGroupElement):
            return AbelianGroupElement(self, args[0])
        else:
            I = self.__number_field.ideal(*args, **kwargs)

            # Use PARI to compute class of given ideal
            g = self.__bnr.bnrisprincipal(I)[1]
            g = [ ZZ(x) for x in g ]
            return AbelianGroupElement(self, g)

After running the above code (either in a notebook cell or the sage command-line, be careful to preserve the whitespace exactly as is), you can use the class like this:

K.<a> = NumberField(x^6 + 76*x^4 + 2*x^3 + 2029*x^2 - 158*x + 18955)
G = RayClassGroup(K, K.ideal(3), [])
J = K.ideal([5, a^2 + 2*a + 23])
G(J).order()

If you have real places, the infinite part is specified using 0's and 1's, e.g.

K.<a> = NumberField(x^6 - 3*x^5 - 3*x^4 + 10*x^3 + 3*x^2 - 6*x + 1)
G = RayClassGroup(K, K.ideal(1), [0,1,1,1,1,1])

gives trivial ray class group, while

K.<a> = NumberField(x^6 - 3*x^5 - 3*x^4 + 10*x^3 + 3*x^2 - 6*x + 1)
G = RayClassGroup(K, K.ideal(1), [1,1,1,1,1,1])

gives $C_2$. The order of ... (more)