139 views

Skip to first unread message

Mar 12, 2014, 9:41:07 AM3/12/14

to sage-...@googlegroups.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 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:

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:

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:

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.

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

`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.

Mar 12, 2014, 10:41:40 AM3/12/14

to sage-...@googlegroups.com

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

> post <https://groups.google.com/forum/#!topic/sage-devel/1QzUpHLUw_E>), one

> --

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

>

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
>

> In order to treat tensor fields on a parallelizable domain N of some smooth

>

> manifold as elements of a free module (cf.

> 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
> has first to introduce the commutative ring C^oo(N) of smooth functions N

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

>

Mar 12, 2014, 10:57:00 AM3/12/14

to sage-...@googlegroups.com

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

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/

Mar 12, 2014, 11:22:43 AM3/12/14

to sage-...@googlegroups.com, Nicolas M. Thiery

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.

Mar 12, 2014, 11:25:10 AM3/12/14

to sage-...@googlegroups.com

Thanks for your answer Vincent.

I fully agree that having the field of real numbers in Sage would be nice !

Regards,

Eric.

I fully agree that having the field of real numbers in Sage would be nice !

Regards,

Eric.

Mar 12, 2014, 12:55:46 PM3/12/14

to sage-...@googlegroups.com

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.

Mar 12, 2014, 3:37:00 PM3/12/14

to sage-...@googlegroups.com

Thanks for your answer and suggestions.

Best wishes,

Eric.

Best wishes,

Eric.

Mar 12, 2014, 4:29:47 PM3/12/14

to sage-...@googlegroups.com

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.

Mar 12, 2014, 8:45:57 PM3/12/14

to sage-...@googlegroups.com

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

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.

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

Mar 13, 2014, 4:17:34 AM3/13/14

to sage-...@googlegroups.com

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

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

Mar 13, 2014, 4:28:27 AM3/13/14

to sage-...@googlegroups.com

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

floating-point numbers being called "real field". See #11506 for a few

examples.

--

Marc

Mar 13, 2014, 5:04:07 AM3/13/14

to sage-...@googlegroups.com

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

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

Mar 13, 2014, 5:07:23 AM3/13/14

to sage-...@googlegroups.com

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

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

Mar 13, 2014, 5:43:32 AM3/13/14

to sage-...@googlegroups.com

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?

Mar 13, 2014, 7:59:28 AM3/13/14

to sage-...@googlegroups.com

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

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

>

Mar 13, 2014, 8:02:09 AM3/13/14

to sage-...@googlegroups.com

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

Mar 13, 2014, 8:28:57 AM3/13/14

to sage-...@googlegroups.com

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

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

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

Mar 13, 2014, 8:57:55 AM3/13/14

to sage-...@googlegroups.com

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
> Nope, too confusing... the bars in QQbar and RRbar have two different meanings.

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

Mar 13, 2014, 4:32:10 PM3/13/14

to sage-...@googlegroups.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.

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

Mar 13, 2014, 5:08:05 PM3/13/14

to sage-...@googlegroups.com

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

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

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

>

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.

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

Mar 13, 2014, 5:10:53 PM3/13/14

to sage-...@googlegroups.com

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

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.

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

Mar 13, 2014, 7:22:19 PM3/13/14

to sage-...@googlegroups.com

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

[...]

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

[...]

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

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

Mar 13, 2014, 9:44:40 PM3/13/14

to sage-...@googlegroups.com

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.

Mar 14, 2014, 5:45:03 AM3/14/14

to sage-...@googlegroups.com

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

Mar 14, 2014, 6:43:38 AM3/14/14

to sage-...@googlegroups.com

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

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

Mar 14, 2014, 9:24:15 AM3/14/14

to sage-...@googlegroups.com

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.

Mar 14, 2014, 9:45:28 AM3/14/14

to sage-...@googlegroups.com

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

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

>

>

>>

>>

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

>>

>>

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

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

?

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

Mar 14, 2014, 10:23:11 AM3/14/14

to sage-...@googlegroups.com

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.

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu