2021-05-29 16:22:48 +0200 | received badge | ● Nice Answer (source) |

2021-05-29 16:20:15 +0200 | received badge | ● Nice Answer (source) |

2013-01-08 10:06:34 +0200 | 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: This gives you 53-bit of floating point precision. For more precision, you can use a a field with more precision: Instead of fixing one embedding upon creating your number field, you can also compute all the embeddings into a given field L with The field |

2012-08-08 09:08:09 +0200 | 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 +0200 | 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 +0200 | 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 +0200 | received badge | ● Supporter (source) |

2012-07-28 10:32:20 +0200 | received badge | ● Teacher (source) |

2012-07-28 04:50:26 +0200 | 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 +0200 | 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 +0200 | 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 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 If we do The documentation explains quite nicely how such coercion is performed in general. In particular the It may ... (more) |

2012-07-27 16:07:49 +0200 | 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 +0200 | 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 +0200 | received badge | ● Editor (source) |

2012-07-20 09:40:45 +0200 | 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 First, an example in PARI/GP to demonstrate the basic computation (some output omitted, $\mathfrak m = (3)$ and $K$ has no real archimedean places): The following provides a quick and dirty hack to do basically the same from SAGE, using its PARI/GP Interface: 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: If you have real places, the infinite part is specified using 0's and 1's, e.g. gives trivial ray class group, while gives $C_2$. The order of ... (more) |

Copyright Sage, 2010. Some rights reserved under creative commons license. Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.