How to define a new ring class ?

[Eric Gourgoulhon]

Hi,

In order to treat tensor fields on a parallelizable domain N of some smooth manifold as elements of a free module (cf. #15916 and this post), one has first to introduce the commutative ring C^oo(N) of smooth functions N --> R, as a new class, ScalarFieldRing say. Browsing through Sage reference manual, a natural guess would be to make it a subclass of CommutativeRing:

from sage.rings.ring import CommutativeRing
class ScalarFieldRing(CommutativeRing):
    def __init__(self, domain):
        CommutativeRing.__init__(self, base_ring)
        self.domain = domain

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) ?

A second solution could be to declare ScalarFieldRing as a subclass of Ring, in the category of commutative rings:

from sage.rings.ring import Ring
from sage.categories.commutative_rings import CommutativeRings
class ScalarFieldRing(Ring):
    def __init__(self, domain):
        Ring.__init__(self, None, category=CommutativeRings())
        self.domain = domain

Here the argument "base" of Ring.__init__ is set to None, which was not possible for the argument "base_ring" of CommutativeRing.__init__ : this triggered the error message "TypeError: base ring None is no commutative ring".

A third solution is to declare ScalarFieldRing directly as a subclass of Parent, in the category of commutative rings:

from sage.structure.parent import Parent
from sage.categories.commutative_rings import CommutativeRings
class ScalarFieldRing(Parent):
    def __init__(self, domain):
        Parent.__init__(self, category=CommutativeRings())
        self.domain = domain

Which solution is preferable (and why) ? (the three of them seem to work, at least in the few tests I've performed). Thank you for your help.

Eric. 

[Vincent Delecroix]

Hi Eric,

My first guess would be to modify the initialization of
CommutativeRing to authorize None as a valid input for base_ring.

Now, the base_ring should be the ring with which you will describe
your functions. As functions are defined through coordinates in
charts, a natural candidate for the base ring would be the common ring
of the coordinate charts.

I guess that right now, most examples are built upon the symbolic
ring. If you want a coordinate free definition, then you might hope
that somebody implements the field of real numbers and C^infinity(RR).

Best
Vincent

2014-03-12 14:41 UTC+01:00, Eric Gourgoulhon <egourg...@gmail.com>:

> Hi,
>
> In order to treat tensor fields on a parallelizable domain N of some smooth
>
> manifold as elements of a free module (cf.

> #15916<http://trac.sagemath.org/ticket/15916>and this
> post <https://groups.google.com/forum/#!topic/sage-devel/1QzUpHLUw_E>), one

>
> has first to introduce the commutative ring C^oo(N) of smooth functions N

> --> *R*, as a new class, ScalarFieldRing say. Browsing through Sage

> --
> 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.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

[Nicolas M. Thiery]

On Wed, Mar 12, 2014 at 06:41:07AM -0700, Eric Gourgoulhon wrote:
> In order to treat tensor fields on a parallelizable domain N of some
> smooth manifold as elements of a free module (cf. #15916 and this post),
> one has first to introduce the commutative ring C^oo(N) of smooth
> functions N --> R, as a new class, ScalarFieldRing say. Browsing through
> Sage reference manual, a natural guess would be to make it a subclass of
> CommutativeRing:

You don't necessarily need too. You could also just inherit from
Parent; the important thing is to set the category to
CommutativeRings().

CommutativeRing is a bit of a legacy stuff: it's still there because
some features have not yet been moved to categories, and also because
some parents where pure arithmetic speed on elements is vital
(e.g. small finite fields), need it to by Cython.

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nth...@users.sf.net>
http://Nicolas.Thiery.name/

[Eric Gourgoulhon]

Le mercredi 12 mars 2014 15:57:00 UTC+1, Nicolas M. Thiéry a écrit :

On Wed, Mar 12, 2014 at 06:41:07AM -0700, Eric Gourgoulhon wrote:
>    In order to treat tensor fields on a parallelizable domain N of some
>    smooth manifold as elements of a free module (cf. #15916 and this post),
>    one has first to introduce the commutative ring C^oo(N) of smooth
>    functions N --> R, as a new class, ScalarFieldRing say. Browsing through
>    Sage reference manual, a natural guess would be to make it a subclass of
>    CommutativeRing:

You don't necessarily need too. You could also just inherit from
Parent; the important thing is to set the category to
CommutativeRings().

You mean the third solution is the one to use ?
 

CommutativeRing is a bit of a legacy stuff: it's still there because
some features have not yet been moved to categories, and also because
some parents where pure arithmetic speed on elements is vital
(e.g. small finite fields), need it to by Cython.

Thanks for these explanations.

Regards,

Eric.

[Eric Gourgoulhon]

Thanks for your answer Vincent.
I fully agree that having the field of real numbers in Sage would be nice !

Regards,

Eric.

[Nils Bruin]

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.

[Eric Gourgoulhon]

Thanks for your answer and suggestions.

Best wishes,

Eric.

[mmarco]

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.

[Thierry]

Hi,

On Wed, Mar 12, 2014 at 01:29:47PM -0700, mmarco wrote:
> 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.

One could imagine the following improvement (which i would love, at
least to make things easier to learn and teach):

- rename RR as RFF (for "real floating field"), so that this
representation is not preferred than the others (especially RDF which
is faster and allows using more libraries, with the same 53 bits of
precision). The current name RR suggests it is the right default choice.

- create RSF (for "real symbolic field") to isolate pi and sqrt(2) from
cos(x) in the symbolic ring.

- re-create RR as an "overlay field" over the different representations
(numeric (RFF, RDF, RIF), algebraic, symbolic) of the genuine real
field in Sage. Perhaps could the experience of the community with the
category framework help in the design of such a meta-representation.

Idem with CFF, CSF, CC for complex numbers.

Ciao,
Thierry

[Vincent Delecroix]

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>:

[Marc Mezzarobba]

Thierry wrote:
> - rename RR as RFF (for "real floating field"), so that this
> representation is not preferred than the others (especially RDF which
> is faster and allows using more libraries, with the same 53 bits of
> precision). The current name RR suggests it is the right default
> choice.

Yes, there seems to be a lot of confusion due to the set of 53-bit
floating-point numbers being called "real field". See #11506 for a few
examples.

--
Marc

[Vincent Delecroix]

Salut Thierry,

I did not see your post before posting mine ! I mostly agreed but I
would love to have something better. There are two kinds of
approximation that one can have when dealing with computations :
- approximate operations +, -, x, / (that allows for example to deal
with a finite subset)
- approximate equality
The term exact in Sage (as in "RR.is_exact()") currently refers to the
first kind. Now if you deal with computable numbers, or large enough
subset of the reals, then you can not guarantee equality (and this is
the case for example with SR that can answer False to A == B even if
it is True). I know that there are other issue with SR, but it was
just to claim that the set of reals that it handle is somewhat too
large to ensure exact equality.

A first step in having sane reals would be to refined this notion of
exactness. This implies to declare convention about the answer of A ==
B. I think that this should be the mathematical answer (True, False)
or an exception that can be either of the kind "raise
NotAbleToSolveTheProblem" or "return Unkown" (from sage.misc.unknown).

Now, concerning implementation, I see at least there levels of fields
- subrings with exact computations and identity problem solvable, ie
algebraic numbers, algebraic reals with exponentials, ...
- subrings with approximate computations (and identity problem
solvable), ie floating points
- subrings with exact computations and identity problem unsolvable,
like the RSF and CSF that you propose.

And it defintely makes sense to have a parent RR with no dedicated
class of element.

Best
Vincent

[Vincent Delecroix]

2014-03-13 9:28 UTC+01:00, Marc Mezzarobba <ma...@mezzarobba.net>:

These examples are great ! It would be more natural to have
sage: Infinity in RFF and NaN in RFF # real floating field
True
sage: Infinity in RR and NaN in RR # real numbers
False

But the answer to "x in P" when x is an element and P a Parent is not
quite clear to me.

Vincent

[mmarco]

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?

[Thierry]

On Thu, Mar 13, 2014 at 10:07:23AM +0100, Vincent Delecroix wrote:
> 2014-03-13 9:28 UTC+01:00, Marc Mezzarobba <ma...@mezzarobba.net>:
> > Thierry wrote:
> >> - rename RR as RFF (for "real floating field"), so that this
> >> representation is not preferred than the others (especially RDF which
> >> is faster and allows using more libraries, with the same 53 bits of
> >> precision). The current name RR suggests it is the right default
> >> choice.
> >
> > Yes, there seems to be a lot of confusion due to the set of 53-bit
> > floating-point numbers being called "real field". See #11506 for a few
> > examples.
> >
>
> These examples are great ! It would be more natural to have
> sage: Infinity in RFF and NaN in RFF # real floating field
> True
> sage: Infinity in RR and NaN in RR # real numbers
> False

Wile we are at it, create RRbar (in the sense of the natural
two-ends compactification):

sage: Infinity in RRbar
True
sage: NaN in RRbar
False

Ciao,
Thierry

> But the answer to "x in P" when x is an element and P a Parent is not
> quite clear to me.
>
> Vincent
>

[Vincent Delecroix]

2014-03-13 12:59 UTC+01:00, Thierry <sage-goo...@lma.metelu.net>:

> On Thu, Mar 13, 2014 at 10:07:23AM +0100, Vincent Delecroix wrote:
>> 2014-03-13 9:28 UTC+01:00, Marc Mezzarobba <ma...@mezzarobba.net>:
>> > Thierry wrote:
>> >> - rename RR as RFF (for "real floating field"), so that this
>> >> representation is not preferred than the others (especially RDF which
>> >> is faster and allows using more libraries, with the same 53 bits of
>> >> precision). The current name RR suggests it is the right default
>> >> choice.
>> >
>> > Yes, there seems to be a lot of confusion due to the set of 53-bit
>> > floating-point numbers being called "real field". See #11506 for a few
>> > examples.
>> >
>>
>> These examples are great ! It would be more natural to have
>> sage: Infinity in RFF and NaN in RFF # real floating field
>> True
>> sage: Infinity in RR and NaN in RR # real numbers
>> False
>
>
> Wile we are at it, create RRbar (in the sense of the natural
> two-ends compactification):
>
> sage: Infinity in RRbar
> True
> sage: NaN in RRbar
> False

Nope, too confusing... the bars in QQbar and RRbar have two different meanings.

[Felix Salfelder]

On Thu, Mar 13, 2014 at 12:59:28PM +0100, Thierry wrote:
> > These examples are great ! It would be more natural to have
> > sage: Infinity in RFF and NaN in RFF # real floating field
> > True
> > sage: Infinity in RR and NaN in RR # real numbers
> > False

i've been waching discussions about real number problems for some time
and i have a question. excuse me if this is stupid.

there is no such thing as a field of floating point numbers, but the
real numbers form a field. i am surprised that this doesnt look like

"""
sage: Infinity in FPN and NaN in FPN # floating point numbers
True
sage: Infinity in RR or NaN in RR # real number field
False
"""

from the beginning. doesnt it make (much) more sense to preserve the
word "field" for things that are fields in a mathematical sense?

and while i'm at it...

> sage: Infinity in RRbar
> True
> sage: NaN in RRbar
> False

wouldn't it make sense to have both, RR_inf and RR_pminf? one for each
compactification... otherwise, why choose one over the other?

"""
sage: RR_inf(Infinity) == RR_inf(-Infinity)
True
sage: RR_pminf(Infinity) == RR_pminf(-Infinity)
False
"""

cheers
felix

[Thierry]

On Thu, Mar 13, 2014 at 01:02:09PM +0100, Vincent Delecroix wrote:
> Nope, too confusing... the bars in QQbar and RRbar have two different meanings.

Well, i agree that QQ.bar() and RR.bar() will be confusing, because they
do not correspond to the same operations (algebraic_closure, vs 2-point
compactification). But QQbar and RRbar (as a single string) both come
from very standard mathematical notations. I am not sure someone ever
confused QQbar as a compactification of QQ or RRbar as the algebraic
closure of RR (and if this happens, perhaps could Sage be helping such
people to learn some mathematics in using those notations). Such a
parent could help in dealing with InfinityRing coercions issues.

sage: PolynomialRing(QQ, 1, 'x').quotient(x^2).an_element()
xbar

To summarize, i would
- use a homogeneous notation for genuine mathematical objects,
e.g. NN, ZZ, QQ, AA, RR, RRbar, QQbar, CC.
- use a homogeneous notation for the various computer approximations,
e.g. RDF, RIF, RFF, RLF, RSF, CDF, CIF, CFF, CLF, CSF.

I think such naming scheme could help a lot in making Sage easier to
grasp for newcommers, and is the one that requires the less changes in
Sage existing notations.

Ciao,
Thierry

[Volker Braun]

On Wednesday, March 12, 2014 8:45:57 PM UTC-4, Thierry (sage-googlesucks@xxx) wrote:

- create RSF (for "real symbolic field") to isolate pi and sqrt(2) from
  cos(x) in the symbolic ring.

Thats essentially what RLF does.

 

- re-create RR as an "overlay field" over the different representations

Its a basic fact that you can't represent a "generic" real number on a computer. You can argue that one should default to a lazy evaluation and not pick a favorite, but that also means that it'll be useless in practice. You can't safely & effectively do floating-point computations without picking a particular representation first. Trying to pretend otherwise is just kidding yourself.

[Vincent Delecroix]

2014-03-13 21:32 UTC+01:00, Volker Braun <vbrau...@gmail.com>:

> On Wednesday, March 12, 2014 8:45:57 PM UTC-4, Thierry
> (sage-googlesucks@xxx) wrote:
>>
>> - create RSF (for "real symbolic field") to isolate pi and sqrt(2) from
>> cos(x) in the symbolic ring.
>>
>
> Thats essentially what RLF does.
>

Nope, pi belongs to SR and not to RLF and there is a huge difference:

sage: RLF(pi) * 1.2 # fine, coercion into RR
3.76991118430775
sage: pi * 1.2 # what the f*** ?
1.20000000000000*pi

The claim was to put all symbolic constants into RLF or CLF or a
better ring in order to avoid many problems like this one

sage: pi_approx = RR(pi)
sage: bool(pi == SR(pi_approx))
True

and many, many, many others.

>> - re-create RR as an "overlay field" over the different representations
>>
>
> Its a basic fact that you can't represent a "generic" real number on a
> computer. You can argue that one should default to a lazy evaluation and
> not pick a favorite, but that also means that it'll be useless in practice.
>
> You can't safely & effectively do floating-point computations without
> picking a particular representation first. Trying to pretend otherwise is
> just kidding yourself.

Of course, and it was not the argument advanced to redefine RR. Let
say that RR is the set of real numbers. Even if there is no way to
define general operations or comparisons on its elements, we can still
ask
* if some element belongs to it (in particular NaN and Infinity do not)
* what is its structure as a topological space
* what is its cardinality
* a random element
I would advocate that RLF is a very good approximation of what should
be RR. Perhaps one good direction to take is to try to make RLF
smarter and contains all constants from pi to cos(42^e).

Vincent

[Thierry]

On Thu, Mar 13, 2014 at 01:32:10PM -0700, Volker Braun wrote:
> On Wednesday, March 12, 2014 8:45:57 PM UTC-4, Thierry
> (sage-googlesucks@xxx) wrote:
> >
> > - create RSF (for "real symbolic field") to isolate pi and sqrt(2) from
> > cos(x) in the symbolic ring.
>
> Thats essentially what RLF does.

RLF loses some symbolic (resp. algebraic) information compared to SR:

sage: a = sqrt(2)
sage: a^2
2
sage: b = RLF(a)
sage: b^2
2.000000000000000?
sage: b^2 == 2
False

> > - re-create RR as an "overlay field" over the different representations
>
> Its a basic fact that you can't represent a "generic" real number on a
> computer. You can argue that one should default to a lazy evaluation and
> not pick a favorite, but that also means that it'll be useless in practice.
> You can't safely & effectively do floating-point computations without
> picking a particular representation first. Trying to pretend otherwise is
> just kidding yourself.

This is not about floating-point arithmetic nor evaluation, but about a
common parent with some semantics in it.

Not all binary infinite words can be represented by a computer (with the
same countability argument), still Sage proposes a
Words('01', finite=False) parent.

Ciao,
Thierry

[Thierry]

On Thu, Mar 13, 2014 at 10:08:05PM +0100, Vincent Delecroix wrote:
[...]

> I would advocate that RLF is a very good approximation of what should
> be RR. Perhaps one good direction to take is to try to make RLF
> smarter and contains all constants from pi to cos(42^e).

A generalisation of RLF could be "real computable numbers" (the set of
numbers whose digits can be enumerated by a Turing machine). It seems
that some usable implementations do exist already.

I am not sure one representation should be selected above another. Even
if this representation is the most expressive (contains a lot of
elements), it is not able to decide equality, while e.g. AA is.

Ciao,
Thierry

[Volker Braun]

On Thursday, March 13, 2014 5:10:53 PM UTC-4, Thierry (sage-googlesucks@xxx) wrote:

This is not about floating-point arithmetic nor evaluation, but about a
common parent with some semantics in it. 

Its fine to strive for generality, but I don't think its a good idea to have something particularly prominent in the namespace for which you can't / don't want to create elements. Also, we can't replace RR without breaking lots of existing code or slowing it down to a crawl, so that possibility is pretty much out.

  

[mmarco]

I would advocate that RLF is a very good approximation of what should
be RR. Perhaps one good direction to take is to try to make RLF
smarter and contains all constants from pi to cos(42^e).

Somehow, it already does (i.e. internally it keeps track of their symbollic nature):

{{{

 sage: b=RLF(cos(42^e))

sage: b

0.9578837974?

sage: b.eval(SR)

cos(42^e)

}}}

Maybe the issue is that there is no coercion between SR and RLF (there is conversion from SR to RLF, and the .eval() method that can take elements from RLF to SR, though).  

[Vincent Delecroix]

2014-03-14 10:45 UTC+01:00, mmarco <mma...@unizar.es>:

This is half good, I am happy that RLF wraps symbolic constants. But,
first of all there can not be any reasonable coercion from SR to RLF
as SR is much bigger. Secondly, SR is not consistent with evaluation

sage: cos(1.).parent()
Real Field with 53 bits of precision
sage: cos(1).parent()
Symbolic Ring

I would prefer the second parent to be something like
RealSymbolicField or RealNumbers or whatever but not symbolic ring.

Thirdly, I would like to be able to compare real numbers built from
different sources :
- algebraic numbers (built from QQbar and NumberField)
- symbolic constants
- continued fractions
- binary expansions
- ...

But currently:

sage: R.<X> = QQ[]
sage: K.<a> = NumberField(X^4 - 5*X^2 + 5, embedding=1.17)
sage: RLF(a)
1.75570504584947?
sage: expr = 2 * cos(3*pi/10)
sage: RLF(expr)
1.17557050458946?
sage: RLF(a) == RLF(expr) # does not work in RLF
False
sage: bool(SR(a) == SR(expr)) # does not work in SR
False

Even if they are equal as real numbers. So what is broken : comparison
in SR? comparison in RLF?

Vincent

[mmarco]

This is half good, I am happy that RLF wraps symbolic constants. But,
first of all there can not be any reasonable coercion from SR to RLF
as SR is much bigger. Secondly, SR is not consistent with evaluation

sage: cos(1.).parent()
Real Field with 53 bits of precision
sage: cos(1).parent()
Symbolic Ring

I don't see much problem: 1. is a floating point number, and hence an inexact element. So it makes sense to compute is cosine as an inexact number too.

On the other hand, 1 is an exact element, so it makes sense to keep its cosine as an exact number.

 

I would prefer the second parent to be something like
RealSymbolicField or RealNumbers or whatever but not symbolic ring.

Thirdly, I would like to be able to compare real numbers built from
different sources :
 - algebraic numbers (built from QQbar and NumberField)
 - symbolic constants
 - continued fractions
 - binary expansions
 - ...

But currently:

sage: R.<X> = QQ[]
sage: K.<a> = NumberField(X^4 - 5*X^2 + 5, embedding=1.17)
sage: RLF(a)
1.75570504584947?
sage: expr = 2 * cos(3*pi/10)
sage: RLF(expr)
1.17557050458946?
sage: RLF(a) == RLF(expr)      # does not work in RLF
False
sage: bool(SR(a) == SR(expr)) # does not work in SR
False

Even if they are equal as real numbers. So what is broken : comparison
in SR? comparison in RLF?

IIRC  it is not known if that problem is decidable or not. That is, in practice, comparison in SR or RLF will always be "broken". It could be improved, but there will always be cases where the computer can not determine if two expressions are equal or not.

[Vincent Delecroix]

2014-03-14 14:24 UTC+01:00, mmarco <mma...@unizar.es>:

>
>
>>
>>
>> This is half good, I am happy that RLF wraps symbolic constants. But,
>> first of all there can not be any reasonable coercion from SR to RLF
>> as SR is much bigger. Secondly, SR is not consistent with evaluation
>>
>> sage: cos(1.).parent()
>> Real Field with 53 bits of precision
>> sage: cos(1).parent()
>> Symbolic Ring
>>
>>
> I don't see much problem: 1. is a floating point number, and hence an
> inexact element. So it makes sense to compute is cosine as an inexact
> number too.
> On the other hand, 1 is an exact element, so it makes sense to keep its
> cosine as an exact number.

I agree with you but it is a real number not any symbolic expression.
If you read my previous post "1.2 * pi" behaves badly because it
should be coerced into RR and not kept into SR (coercion should be
from more precision to less precision). This is the reason why I do
not want to keep symbolic constants into the symbolic ring. Am I wrong
?

Any number cos(rational x pi) is algebraic and equality of algebraic
numbers is decidable. Moreover, it is not because something is
undecidable that Sage should return a wrong answer. In that case, it
would be good to have a third party in comparison (either returning
Unknown or raising exception).

[mmarco]

Any number cos(rational x pi) is algebraic and equality of algebraic
numbers is decidable. Moreover, it is not because something is
undecidable that Sage should return a wrong answer. In that case, it
would be good to have a third party in comparison (either returning
Unknown or raising exception).

Yes, in this particular case, you are right (and in fact, you can check for equality of those two elements if you convert them to AA), but in general,  determining if a real number given by a symbollic expression involving e,pi, rationals, roots, logarithms... is zero or not is not doable. So, no matter how you implement this new field of real numbers, it will have "broken" comparison.

But maybe you are right about the "Unknown" answer. Although it might cause some other problems: you cannot know if you can take the inverse, or the logarithm of a real numbers. We could have then something like the NaN problem: an "unknown" thing that contaminates everything it touches. I don't really think we can find a good solution.