The problem is that you cannot know if a certain expression involving pi, e and cos(3/4) is zero or not (well, you can determine that it is not zero, if a numerical approximation is not, but a zero numerical aproximation doesn't imply the expression to be zero). That means that, for instance, you don't know if you can take its inverse.
If you assume that they are transcendental (that is, that such expressions are not zero), you are working on AA(t1,t2.t3) with t1=pi, t2=e, t3=cos(3/4). So maybe the right approach would be to implement arbitrary extensions of QQ (that is, QQ(t1,t2...tn)[a], with a algebraic over QQ(t1,t2,...,tn)) providing methods to compute numerical aproximations for t1,t2...tn And also make it dynamically, so that new symbols can be added on the fly. That way we have best of both worlds: algebraic exactness plus the ability to get numerical aproximations. That is, a real would be "something that lives in an extension of QQ, with a method to get numerical aproximations, and such that all those numerical aproximations have no imaginary part" Would that make sense? El jueves, 13 de marzo de 2014 09:17:34 UTC+1, vdelecroix escribió: > > I do not agree with Miguel: it makes sense to have a Parent modeling > the set of all real numbers (even if it has no element). And the > natural name for it would be RR. > > Now, concerning concrete computation, what you can do is either : > - use floating points (ie approximate operations +, x, -, / and exact > equality) > - use computable numbers (ie exact operations but approximate equality) > - deal with a nice subsets of RR (such as algebraic numbers, finite > transcendantal extensions, ...) where you can deal with exact > operations and exact equality. > - mix of the one above > It is bad that only QQ, QQbar and SR can handle arbitrary precision > real number. It would make more sense to have pi, e, cos(3/4), ... in > a ring of "exact reals". > > It deviates from the initial subject but it is always good to say that > real numbers should not be in SR and that RR is misnamed ! > > Vincent > > 2014-03-12 21:29 UTC+01:00, mmarco <mma...@unizar.es <javascript:>>: > > Since the ring you want will be an algebra over the reals, the best fit > for > > > > base ring would be the reals. > > > > Now, since it is impossible to represent the real field in practice, > there > > are different possible solutions in sage: > > > > RR if you don't care about the lack of exactness > > QQ or some extension (like AA) if you want exactness but don't mind the > > lack of transcendentals > > SR if you want to allow arbitrary expressions, with the problem of speed > > and maybe the lack of a unique form for each element. > > > > I don't think that you can do much better than that to work with the > reals. > > > > In practice, since in every computation there will only be a finite > number > > of symbols involved, it can be done in something like AA(t1,t2,...,tn) > (a > > trascendental extension of the algebraic reals) or QQ[a](t1,t2,...,tn) > with > > > > a in AA. But working in those rings can be extremely slow, and you would > > need in advance which numbers would appear, which are algebraic and > which > > trascendental and so on. So i wouldn't advise it. > > > > > > El miércoles, 12 de marzo de 2014 20:37:00 UTC+1, Eric Gourgoulhon > > escribió: > >> > >> Thanks for your answer and suggestions. > >> > >> Best wishes, > >> > >> Eric. > >> > >> Le mercredi 12 mars 2014 17:55:46 UTC+1, Nils Bruin a écrit : > >>> > >>> On Wednesday, March 12, 2014 6:41:07 AM UTC-7, Eric Gourgoulhon wrote: > >>>> > >>>> The issue here is that CommutativeRing.__init__ requires the argument > >>>> "base_ring" and in the present context, I don't know what to put > here: > >>>> the > >>>> ring C^oo(N) does not depend upon any other ring. Shall I put self, > i.e. > >>>> > >>>> write CommutativeRing.__init__(self, self) ? > >>>> > >>> > >>> Every ring ultimately has ZZ as a base, by virtue of being an additive > >>> group. You could use that. On the other hand, if you expect the thing > to > >>> be > >>> finitely generated over its base then perhaps the ring should be its > own > >>> > >>> base (I don't think that's a formal requirement, given that > >>> `ZZ[['x']].base_ring()==ZZ`). This does happen in Sage elsewhere: > >>> > >>> sage: ZZ.base_ring() > >>> Integer Ring > >>> sage: QQ.base_ring() > >>> Rational Field > >>> sage: GF(3).base_ring() > >>> Finite Field of size 3 > >>> > >>> On the other hand, if you find it's doable to avoid specifying a base, > >>> perhaps that's the better way to go. > >>> > >> > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "sage-devel" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to sage-devel+...@googlegroups.com <javascript:>. > > To post to this group, send email to > > sage-...@googlegroups.com<javascript:>. > > > Visit this group at http://groups.google.com/group/sage-devel. > > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
