445 views

Skip to first unread message

Oct 14, 2020, 2:28:08 AM10/14/20

to sage-devel

Dear all,

I would like to discuss the patchbomb at

https://trac.sagemath.org/ticket/24523

The ticket hopes to change the string representation from

"Real Field with XX bits of precision" to "Real Floating-point

field with XX bits of precision".

Rationale: it was quite unfortunate from the beginning that

RealField and ComplexField mean "floating-point arithmetic".

On the one hand, one would like to be able to work with the

(abstract) Parent modeling the real numbers (eg for coercions).

On the other hand, in the setting of computer algebra it is

very often much better to work with interval arithmetic or

balls rather than floating-point. The ticket is a small

step towards getting the genuine "RealField" standing for

the set of real numbers. See

https://trac.sagemath.org/ticket/17713

I think this deserves an agreement from other developers! Any

comment very welcome.

Best

Vincent

I would like to discuss the patchbomb at

https://trac.sagemath.org/ticket/24523

The ticket hopes to change the string representation from

"Real Field with XX bits of precision" to "Real Floating-point

field with XX bits of precision".

Rationale: it was quite unfortunate from the beginning that

RealField and ComplexField mean "floating-point arithmetic".

On the one hand, one would like to be able to work with the

(abstract) Parent modeling the real numbers (eg for coercions).

On the other hand, in the setting of computer algebra it is

very often much better to work with interval arithmetic or

balls rather than floating-point. The ticket is a small

step towards getting the genuine "RealField" standing for

the set of real numbers. See

https://trac.sagemath.org/ticket/17713

I think this deserves an agreement from other developers! Any

comment very welcome.

Best

Vincent

Oct 14, 2020, 3:15:59 AM10/14/20

to sage-devel

Seconded. I can see a role for some Sage representation of the (mathematical) set of reals (or complexes, BTW), well distinct from the set of finite binary approximations. Some of the Sympy operations on Sympy sets may be an inspiration....

HTH,

Oct 14, 2020, 3:17:55 AM10/14/20

to sage-devel

A big +1 from my side.

Eric.

Le mercredi 14 octobre 2020 à 08:28:08 UTC+2, vdelecroix a écrit :

Oct 14, 2020, 4:38:04 AM10/14/20

to sage-devel

good idea, +1

--

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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/e2d5c7e3-a311-4ec7-b612-c698f27e10ddn%40googlegroups.com.

Oct 14, 2020, 5:13:04 AM10/14/20

to sage-devel

+1

Oct 14, 2020, 5:13:29 AM10/14/20

to sage-devel

+1 from my side, too.

Oct 14, 2020, 6:32:34 AM10/14/20

to sage-...@googlegroups.com

Hi,

+1 as well of course. A harder question is whether we are ready to

replace the Python names RealField and RR with RealFloatingField and

RFF, so that the names RealField and RR could be used for the genuine

real field.

Ciao,

Thierry

+1 as well of course. A harder question is whether we are ready to

replace the Python names RealField and RR with RealFloatingField and

RFF, so that the names RealField and RR could be used for the genuine

real field.

Ciao,

Thierry

> --

> 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/1478b51e-671d-4fce-902a-bc00bd0f567bn%40googlegroups.com.
> 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.

Oct 14, 2020, 2:48:21 PM10/14/20

to sage-devel

On Tuesday, October 13, 2020 at 11:28:08 PM UTC-7, vdelecroix wrote:

I would like to discuss the patchbomb at

https://trac.sagemath.org/ticket/24523

The ticket hopes to change the string representation from

"Real Field with XX bits of precision" to "Real Floating-point

field with XX bits of precision".

+1

Oct 14, 2020, 8:46:25 PM10/14/20

to sage-devel

I would like to discuss the patchbomb at

https://trac.sagemath.org/ticket/24523

The ticket hopes to change the string representation from

"Real Field with XX bits of precision" to "Real Floating-point

field with XX bits of precision".

+1

Oct 15, 2020, 4:04:55 AM10/15/20

to sage-devel

+1 as well of course. A harder question is whether we are ready to

replace the Python names RealField and RR with RealFloatingField and

RFF, so that the names RealField and RR could be used for the genuine

real field.

I wonder if there is a real prospect that the genuine real field is ever implemented. If not, then we lose the name RealField for good...

Oct 15, 2020, 4:21:06 AM10/15/20

to sage-devel

I was expecting someone more pedantic than me to point out that this set is not a field in the mathematical sense. Since this is a big change anyway (at least to a lot of doctest outputs) should we think more carefully about what we want to call RR? Instead of "Real floating-point field with x bits of precision" we could have "Real floating-point numbers with x bits of precision" perhaps. (With an implied "The set of" in front).

John

Oct 15, 2020, 5:24:17 AM10/15/20

to sage-devel

2020-10-15 08:21:06 UTC, John Cremona:

>

> I was expecting someone more pedantic than me to point out that this set

> is not a field in the mathematical sense. Since this is a big change anyway

> (at least to a lot of doctest outputs) should we think more carefully about

> what we want to call RR? Instead of "Real floating-point field with x bits

> of precision" we could have "Real floating-point numbers with x bits of

> precision" perhaps. (With an implied "The set of" in front).

Good point!

I like "Real floating-point numbers with x bits of precision"

with short name RFN for real floating-point numbers.

Or shorter: "RealFloats" -> "Real floats with x bits of precision",

short name RF for the standard one with 53 bits of precision.

Consistency would dictate to rename and change the string representation

for all of the following:

- ComplexField -> ComplexFloats

- RealField -> RealFloats

- ComplexDoubleField -> ComplexDoubleFloats

- RealDoubleField -> RealDoubleFloats

- ComplexBallField -> ComplexFloatBalls

- ComplexBallField -> RealFloatBalls

- ComplexIntervalField -> ComplexFloatIntervals

- RealIntervalField -> RealFloatIntervals

and maybe more sort-of-fields that can be listed using:

```

sage: [g for g in globals() if 'ield' in g]

```

- ComplexLazyField -> ComplexLazyFloats?

- RealLazyField -> RealLazyFloats?

- MPComplexField -> MPComplexFloats?

What about pAdicField?

Of course we can do things one at a time, but it's good to plan ahead

and maybe have a meta-ticket to keep track of what is done and what

needs to be done.

Side remark: should ComplexIntervalFieldElement, FieldElement

and NumberFieldElement be removed from the global namespace?

Oct 15, 2020, 6:43:32 AM10/15/20

to SAGE devel

I like RealFloats (RF) and ComplexFloats (CF). Since float is a type

in both Python and C, they seem reasonable as names for a type/class

in Sage too. I can imagine many people wanting to predefine RR=RF and

CC=CF to make their own code backward-compatible, but it seems to be

to be a good thing to have the short names RF and CF to remind one

that we are *not* using some idealised implementation of genuine real

or complex numbers.

This is a big change, so we should make sure that many people have a

chance to give their opinion.

John

> --

> You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.

> To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/ba9u_As3T4s/unsubscribe.

> To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/cd24bb8e-ab14-43be-ada6-7da6a720ae4fo%40googlegroups.com.

in both Python and C, they seem reasonable as names for a type/class

in Sage too. I can imagine many people wanting to predefine RR=RF and

CC=CF to make their own code backward-compatible, but it seems to be

to be a good thing to have the short names RF and CF to remind one

that we are *not* using some idealised implementation of genuine real

or complex numbers.

This is a big change, so we should make sure that many people have a

chance to give their opinion.

John

> You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.

> To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/ba9u_As3T4s/unsubscribe.

> To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/cd24bb8e-ab14-43be-ada6-7da6a720ae4fo%40googlegroups.com.

Oct 15, 2020, 6:45:10 AM10/15/20

to sage-...@googlegroups.com

Hi,

On Thu, Oct 15, 2020 at 01:21:06AM -0700, John Cremona wrote:

> I was expecting someone more pedantic than me to point out that this set is

> not a field in the mathematical sense. Since this is a big change anyway

> (at least to a lot of doctest outputs) should we think more carefully about

> what we want to call RR? Instead of "Real floating-point field with x

> bits of precision" we could have "Real floating-point numbers with x bits

> of precision" perhaps. (With an implied "The set of" in front).

I hope i am not that pedantic, but this has been discussed 6 years ago

when i was asked to provide more details on the proposal of having a

genuine real field in Sage:

https://trac.sagemath.org/ticket/17713#comment:3

However, i am currently not that shocked with the word "field", as there

are some notions of "pseudo fields" (perhaps even "quasi field"), where

axioms are satisfied for most tuples, though i would like Sage to know

which objects are genuine fields, and which objects are pseudo-fields.

Note also that in some algoritms, there are choices that depends on

whether the parent is a (pseudo-)field or not, now i am not sure that

considering such parents ony as a bunch of numbers is enough, even for

the user.

Perhaps "Real floating-point pseudofield with x bits of precision" ?

Ciao,

Thierry

>

> John

>

> On Thursday, October 15, 2020 at 9:04:55 AM UTC+1 Kwankyu Lee wrote:

>

> > +1 as well of course. A harder question is whether we are ready to

> >> replace the Python names RealField and RR with RealFloatingField and

> >> RFF, so that the names RealField and RR could be used for the genuine

> >> real field.

> >>

> >

> > I wonder if there is a real prospect that the genuine real field is ever

> > implemented. If not, then we lose the name RealField for good...

> >

> >

> >

>

On Thu, Oct 15, 2020 at 01:21:06AM -0700, John Cremona wrote:

> I was expecting someone more pedantic than me to point out that this set is

> not a field in the mathematical sense. Since this is a big change anyway

> (at least to a lot of doctest outputs) should we think more carefully about

> what we want to call RR? Instead of "Real floating-point field with x

> bits of precision" we could have "Real floating-point numbers with x bits

> of precision" perhaps. (With an implied "The set of" in front).

when i was asked to provide more details on the proposal of having a

genuine real field in Sage:

https://trac.sagemath.org/ticket/17713#comment:3

However, i am currently not that shocked with the word "field", as there

are some notions of "pseudo fields" (perhaps even "quasi field"), where

axioms are satisfied for most tuples, though i would like Sage to know

which objects are genuine fields, and which objects are pseudo-fields.

Note also that in some algoritms, there are choices that depends on

whether the parent is a (pseudo-)field or not, now i am not sure that

considering such parents ony as a bunch of numbers is enough, even for

the user.

Perhaps "Real floating-point pseudofield with x bits of precision" ?

Ciao,

Thierry

>

> John

>

> On Thursday, October 15, 2020 at 9:04:55 AM UTC+1 Kwankyu Lee wrote:

>

> > +1 as well of course. A harder question is whether we are ready to

> >> replace the Python names RealField and RR with RealFloatingField and

> >> RFF, so that the names RealField and RR could be used for the genuine

> >> real field.

> >>

> >

> > I wonder if there is a real prospect that the genuine real field is ever

> > implemented. If not, then we lose the name RealField for good...

> >

> >

> >

>

> --

> 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/2fd10f7c-4e65-4800-b32f-e7b208ad63cbn%40googlegroups.com.
> 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.

Oct 15, 2020, 6:55:55 AM10/15/20

to sage-...@googlegroups.com

On Thu, Oct 15, 2020 at 11:43:01AM +0100, John Cremona wrote:

> I like RealFloats (RF) and ComplexFloats (CF). Since float is a type

> in both Python and C, they seem reasonable as names for a type/class

> in Sage too. I can imagine many people wanting to predefine RR=RF and

> CC=CF to make their own code backward-compatible, but it seems to be

> to be a good thing to have the short names RF and CF to remind one

> that we are *not* using some idealised implementation of genuine real

> or complex numbers.

But then, how would you call the real double field (RD ?), the real ball
> I like RealFloats (RF) and ComplexFloats (CF). Since float is a type

> in both Python and C, they seem reasonable as names for a type/class

> in Sage too. I can imagine many people wanting to predefine RR=RF and

> CC=CF to make their own code backward-compatible, but it seems to be

> to be a good thing to have the short names RF and CF to remind one

> that we are *not* using some idealised implementation of genuine real

> or complex numbers.

field (RB ?), the real interval field (RI ?), and so on ?

I like the idea that the genuine fields/rings have 2 letters as many people

use in their LaTeX newcommands : ZZ, QQ, AA, RR, CC

and their approximations use 3 letters RFF, RBF, RIF, ... (could be RFN,

RBN, RIN, or similar).

In any case, i am not sure we should promote the current implementation

of RR so much (MPRF), as RDF is much faster and allows tu use more

external libraries, and RBF is more reliable and as fast.

Ciao,

Thierry

> 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAD0p0K5%2BSB9%2BNR8j%3DuQdTkrQC2tp5WXurS7aQQtqiuL9vv%2B_Gg%40mail.gmail.com.

Oct 15, 2020, 8:14:03 AM10/15/20

to sage-devel

Hi everyone,

Thierry:

replace the Python names RealField and RR with RealFloatingField and

RFF, so that the names RealField and RR could be used for the genuine

real field.

It seems, this is then a good motivation to push this idea forward. :)

John:

Good point. However, I thought that the attribute `is_exact` allows exactly this: representing an object which is mathematically a field (for example) but approximately implemented. Perhaps, I just got it wrong?

Thierry:

are some notions of "pseudo fields" (perhaps even "quasi field"), where

axioms are satisfied for most tuples, though i would like Sage to know

which objects are genuine fields, and which objects are pseudo-fields.

I am not shocked either. The symbolic ring for example isn't a field either but treated as one for convenience. If we want to go this way, we have to be very strict all over.

Note also that in some algoritms, there are choices that depends on

whether the parent is a (pseudo-)field or not, now i am not sure that

considering such parents ony as a bunch of numbers is enough, even for

the user.

If we want to separate pseudo-fields from fields: what about introducing a new category "Pseudo-Fields"? Then you can check for these algorithms whether the corresponding "bunch of numbers" is a pseudo-ring or not.

use in their LaTeX newcommands : ZZ, QQ, AA, RR, CC

and their approximations use 3 letters RFF, RBF, RIF, ... (could be RFN,

RBN, RIN, or similar).

Big +1!

Best,

Michael

Michael

Oct 15, 2020, 1:19:25 PM10/15/20

to sage-devel

I like RealFloats and ComplexFloats as well; however, I think it's too early to relinquish RR and CC. There's no "exact real field" presently and if it is ever realized, it should probably be called ExactRealField or something similar to stress that it is NOT what people generally expect it to be for the coming 25 years at least (because programming and calculators will continue to deal primarily with floats). Any implementation of ExactRealField will need to prove itself over an extended time period and in a variety of applications before we can propose it as a default choice.

Leave the default values of RR and CC to what they are until it's clear that there's a uniformly better default for them.

Oct 15, 2020, 3:53:58 PM10/15/20

to sage-...@googlegroups.com

Hi,

On Thu, Oct 15, 2020 at 10:19:25AM -0700, Nils Bruin wrote:

> I like RealFloats and ComplexFloats as well; however, I think it's too

> early to relinquish RR and CC. There's no "exact real field" presently and

> if it is ever realized, it should probably be called ExactRealField or

> something similar to stress that it is NOT what people generally expect it

> to be for the coming 25 years at least (because programming and calculators

> will continue to deal primarily with floats). Any implementation of

> ExactRealField will need to prove itself over an extended time period and

> in a variety of applications before we can propose it as a default choice.

The question is not about exact or inexact, not even about the

implementation of its elements (we can even imagine that RR is not a

parent anymore), it is about having a home for the abstraction of the

real field, in the mathematical sense. Its elements can not have an

exact representation anyway (if only for a cardinality reason). So, it

is not to replace an implementation with another, but to have something

that covers all existing representations.

Currently, we have the following behaviours:

sage: oo in RR

True

sage: NaN in RR

True

sage: RIF(0,1) in RR

False

and while i have no problem to see such behaviour for, say, RDF, i would

like RR to be, among other features to be discussed, a generic container

that will tell whether some Sage object represents a real number or not.

I have a pretty long list of doctests (and implementation) that an

abstraction of the genuine real field, as a container, should satisfy,

and the previous examples will not hold. However,

sage: RDF(1.1) in RR

True

will still hold, no worry about that !

Ciao,

Thierry

> Leave the default values of RR and CC to what they are until it's clear

> that there's a uniformly better default for them.

>

On Thu, Oct 15, 2020 at 10:19:25AM -0700, Nils Bruin wrote:

> I like RealFloats and ComplexFloats as well; however, I think it's too

> early to relinquish RR and CC. There's no "exact real field" presently and

> if it is ever realized, it should probably be called ExactRealField or

> something similar to stress that it is NOT what people generally expect it

> to be for the coming 25 years at least (because programming and calculators

> will continue to deal primarily with floats). Any implementation of

> ExactRealField will need to prove itself over an extended time period and

> in a variety of applications before we can propose it as a default choice.

implementation of its elements (we can even imagine that RR is not a

parent anymore), it is about having a home for the abstraction of the

real field, in the mathematical sense. Its elements can not have an

exact representation anyway (if only for a cardinality reason). So, it

is not to replace an implementation with another, but to have something

that covers all existing representations.

Currently, we have the following behaviours:

sage: oo in RR

True

sage: NaN in RR

True

sage: RIF(0,1) in RR

False

and while i have no problem to see such behaviour for, say, RDF, i would

like RR to be, among other features to be discussed, a generic container

that will tell whether some Sage object represents a real number or not.

I have a pretty long list of doctests (and implementation) that an

abstraction of the genuine real field, as a container, should satisfy,

and the previous examples will not hold. However,

sage: RDF(1.1) in RR

True

will still hold, no worry about that !

Ciao,

Thierry

> Leave the default values of RR and CC to what they are until it's clear

> that there's a uniformly better default for them.

>

> --

> 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/6fc17ac7-284c-4041-8e99-ea36cd15134do%40googlegroups.com.
> 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.

Oct 15, 2020, 5:11:46 PM10/15/20

to sage-devel

On Thursday, October 15, 2020 at 12:53:58 PM UTC-7, Thierry (sage-googlesucks@xxx) wrote:

The question is not about exact or inexact, not even about the

implementation of its elements (we can even imagine that RR is not a

parent anymore), it is about having a home for the abstraction of the

real field, in the mathematical sense. Its elements can not have an

exact representation anyway (if only for a cardinality reason). So, it

is not to replace an implementation with another, but to have something

that covers all existing representations.

I think any change of RR in such a way would have to be accompanied with a fairly comprehensive survey of how much code out there will break, due to RR(pi) and similar statements no longer working. It might be limited if people are frequently caring about the number of digits this happens with, but if RR gets used a lot as an alternative to RDF then the breakage could be considerable, to a point where it's not really feasible to change the meaning.

Oct 15, 2020, 8:26:01 PM10/15/20

to sage-devel

I have a pretty long list of doctests (and implementation) that an

abstraction of the genuine real field, as a container, should satisfy,

and the previous examples will not hold.

Then it should be called "AbstractRealField", and we set RR = AbstractRealField, CC = AbstractComplexField.

Oct 16, 2020, 1:50:46 AM10/16/20

to sage-...@googlegroups.com

I agree that these are not fields in the mathematical sense. And Sage

knows about it

sage: RR.is_exact()

False

sage: QQ.is_exact()

True

However, they are much more than sets as they come with approximations

of the field operations (+, x, ^-1). Maybe a reasonable terminology

would be "numerical field"? And in this regard, RealFloatingPointField

perfectly make sense. I am against RealFloats.

knows about it

sage: RR.is_exact()

False

sage: QQ.is_exact()

True

However, they are much more than sets as they come with approximations

of the field operations (+, x, ^-1). Maybe a reasonable terminology

would be "numerical field"? And in this regard, RealFloatingPointField

perfectly make sense. I am against RealFloats.

Oct 19, 2020, 10:40:01 AM10/19/20

to sage-devel

Dear all,

vdelecroix schrieb am Freitag, 16. Oktober 2020 um 07:50:46 UTC+2:

I agree that these are not fields in the mathematical sense. And Sage

knows about it

sage: RR.is_exact()

False

sage: QQ.is_exact()

True

That's actually what I meant. We also have:

sage: RR in Fields()

True

We could say that RR is a non-exact realization of an exact mathematical object which is a field, so that both outputs make somehow sense. But if we want it as rigorously as requested, we must as well require

sage: RR in Fields()

False

If that is what we want, we perhaps need another category, e.g. "PseudoFields" in order to maintain most algorithms, e.g. for matrices.

I'd suggest a workaround: so what about "Real Field realized by Floating-point arithmetics of precision xx" and keep the above behavior? And then similarly for interval arithmetics and ball arithmetics.

Best,

Michael

Oct 20, 2020, 12:12:39 AM10/20/20

to sage-devel

-1: I don't really care what RealField.__repr__ returns, but cast a token no vote to object to the logical next move of breaking backwards compatibility by changing the meaning of RealField and/or RR. I see the need for a "genuine real field", but it seems a lot simpler just to call it something other than "RealField" and so not break a lot of existing users' Sage code.

Best,

Nathan

Nathan

Oct 20, 2020, 3:07:05 AM10/20/20

to sage-devel

-1, agreed with Nathan Dunfield

Oct 20, 2020, 4:15:49 AM10/20/20

to sage-devel

On Tue, Oct 20, 2020 at 8:07 AM Frédéric Chapoton <fchap...@gmail.com> wrote:

>

> -1, agreed with Nathan Dunfield

>

> Le mardi 20 octobre 2020 à 06:12:39 UTC+2, Nathan Dunfield a écrit :

>>

>> -1: I don't really care what RealField.__repr__ returns, but cast a token no vote to object to the logical next move of breaking backwards compatibility by changing the meaning of RealField and/or RR. I see the need for a "genuine real field", but it seems a lot simpler just to call it something other than "RealField" and so not break a lot of existing users' Sage code.

one cannot stop the progress by voting :-)
>

> -1, agreed with Nathan Dunfield

>

> Le mardi 20 octobre 2020 à 06:12:39 UTC+2, Nathan Dunfield a écrit :

>>

>> -1: I don't really care what RealField.__repr__ returns, but cast a token no vote to object to the logical next move of breaking backwards compatibility by changing the meaning of RealField and/or RR. I see the need for a "genuine real field", but it seems a lot simpler just to call it something other than "RealField" and so not break a lot of existing users' Sage code.

Well, seriously speaking, such drastic changes are needed sometimes,

and they demand a bump in the major version number, e.g. they can

happen in Sage 10.0.

It takes a lot of effort for a newcomer to get that RR and CC are

basically RDF and CDF on steroids, to get the mysteries of AA, etc

etc.

>>

>> Best,

>>

>> Nathan

>>

>> On Wednesday, October 14, 2020 at 1:28:08 AM UTC-5 vdelecroix wrote:

>>>

>>> Dear all,

>>>

>>> I would like to discuss the patchbomb at

>>>

>>> https://trac.sagemath.org/ticket/24523

>>>

>>> The ticket hopes to change the string representation from

>>> "Real Field with XX bits of precision" to "Real Floating-point

>>> field with XX bits of precision".

>>>

>>> Rationale: it was quite unfortunate from the beginning that

>>> RealField and ComplexField mean "floating-point arithmetic".

>>> On the one hand, one would like to be able to work with the

>>> (abstract) Parent modeling the real numbers (eg for coercions).

>>> On the other hand, in the setting of computer algebra it is

>>> very often much better to work with interval arithmetic or

>>> balls rather than floating-point. The ticket is a small

>>> step towards getting the genuine "RealField" standing for

>>> the set of real numbers. See

>>>

>>> https://trac.sagemath.org/ticket/17713

>>>

>>> I think this deserves an agreement from other developers! Any

>>> comment very welcome.

>>>

>>> Best

>>> Vincent

>>>

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

Oct 20, 2020, 4:31:21 AM10/20/20

to Sage-devel

Le ven. 16 oct. 2020 à 07:50, Vincent Delecroix:

but I'm not strongly attached to it.

>

> I agree that these are not fields in the mathematical sense. And Sage

> knows about it

>

> sage: RR.is_exact()

> False

> sage: QQ.is_exact()

> True

>

> However, they are much more than sets as they come with approximations

> of the field operations (+, x, ^-1). Maybe a reasonable terminology

> would be "numerical field"? And in this regard, RealFloatingPointField

> perfectly make sense. I am against RealFloats.

I like your suggestions. I liked the shortness of RealFloats,
> I agree that these are not fields in the mathematical sense. And Sage

> knows about it

>

> sage: RR.is_exact()

> False

> sage: QQ.is_exact()

> True

>

> However, they are much more than sets as they come with approximations

> of the field operations (+, x, ^-1). Maybe a reasonable terminology

> would be "numerical field"? And in this regard, RealFloatingPointField

> perfectly make sense. I am against RealFloats.

but I'm not strongly attached to it.

Oct 20, 2020, 10:07:00 AM10/20/20

to sage-...@googlegroups.com

On 10/20/20 12:12 AM, Nathan Dunfield wrote:

> -1: I don't really care what RealField.__repr__ returns, but cast a

> token no vote to object to the logical next move of breaking backwards

> compatibility by changing the meaning of RealField and/or RR. I see the

> need for a "genuine real field", but it seems a lot simpler just to call

> it something other than "RealField" and so not break a lot of existing

> users' Sage code.

>

Breaking user code is annoying, but in this case the fix is pretty
> -1: I don't really care what RealField.__repr__ returns, but cast a

> token no vote to object to the logical next move of breaking backwards

> compatibility by changing the meaning of RealField and/or RR. I see the

> need for a "genuine real field", but it seems a lot simpler just to call

> it something other than "RealField" and so not break a lot of existing

> users' Sage code.

>

trivial. You wouldn't have to read through the API documentation or

anything -- just run find & replace on a few text files.

Having both a Real Field and a RealField and having them be two

completely different things (one of which is not even a field!) would be

far worse IMO.

Oct 20, 2020, 10:11:57 AM10/20/20

to sage-devel

Well, seriously speaking, such drastic changes are needed sometimes,

and they demand a bump in the major version number, e.g. they can

happen in Sage 10.0.

It takes a lot of effort for a newcomer to get that RR and CC are

basically RDF and CDF on steroids, to get the mysteries of AA, etc

etc.

My perspective is partly coming as someone who has several papers that rely heavily on Sage computations. I've archived the code and data in a permanent fashion, but every backwards incompatible change Sage makes decreases the odds that anyone will be able to easily verify or extend my work five years from now. Certainly, changing the meaning of RealField will break all of it. As you say, such changes are sometimes necessary. However, if Sage can solve the same technical problem by calling the new real number overclass GenuineRealField (or whatever) rather than stealing the name of the current RealField, I am arguing that it is not.

With regards to newcomers, I don't think having "RealField" be some abstract base class which is rarely what they need is going to help them, and any scheme for working with reals on a computer is going to be a bit complicated. I will also point out that intermediate users hate-hate-hate having their old notebooks and code no longer work. To any of us, fixing something like this is a simple search and replace after glancing at the traceback to realize what the issue is, but things like this are incredibly frustrating to more occasional users who view tracebacks as incomprehensible.

Best,

Best,

Nathan

Oct 20, 2020, 10:12:40 AM10/20/20

to sage-...@googlegroups.com

On 10/16/20 5:25 AM, Samuel Lelièvre wrote:

> Le ven. 16 oct. 2020 à 07:50, Vincent Delecroix:

>>

>>

> Le ven. 16 oct. 2020 à 07:50, Vincent Delecroix:

>>

>>

>> However, they are much more than sets as they come with approximations

>> of the field operations (+, x, ^-1)....
>

> I like your suggestions. I liked the shortness of RealFloats,

> but I'm not strongly attached to it.

>

RealApprox? Pretty much any of the options are better than RealField though.
> I like your suggestions. I liked the shortness of RealFloats,

> but I'm not strongly attached to it.

>

Oct 20, 2020, 10:28:19 AM10/20/20

to sage-devel

On Tue, 20 Oct 2020, 15:12 Nathan Dunfield, <nat...@dunfield.info> wrote:

Well, seriously speaking, such drastic changes are needed sometimes,

and they demand a bump in the major version number, e.g. they can

happen in Sage 10.0.It takes a lot of effort for a newcomer to get that RR and CC are

basically RDF and CDF on steroids, to get the mysteries of AA, etc

etc.My perspective is partly coming as someone who has several papers that rely heavily on Sage computations. I've archived the code and data in a permanent fashion, but every backwards incompatible change Sage makes decreases the odds that anyone will be able to easily verify or extend my work five years from now.

one needs to maintain the code, one can't just hope it will all magically keep working in newer versions (it won't be true even if it was in plain Python).

And in this case a fix is trivial.

(and you have a chance to check along the way that it is still working)

Certainly, changing the versions of RealField will break all of it. As you say, such changes are sometimes necessary. However, if Sage can solve the same technical problem by calling the new real number overclass GenuineRealField (or whatever) rather than stealing the name of the current RealField, I am arguing that it is not.

With regards to newcomers, I don't think having "RealField" be some abstract base class which is rarely what they need is going to help them, and any scheme for working with reals on a computer is going to be a bit complicated. I will also point out that intermediate users hate-hate-hate having their old notebooks and code no longer work. To any of us, fixing something like this is a simple search and replace after glancing at the traceback to realize what the issue is, but things like this are incredibly frustrating to more occasional users who view tracebacks as incomprehensible.

Best,Nathan

--

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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/128f0019-1979-4c17-a902-33528232f060n%40googlegroups.com.

Oct 20, 2020, 10:58:42 AM10/20/20

to sage-devel

Dear all,

Perhaps I am just too naive as a newbie here, but I think the details of backwards compatibility can be discussed when it comes to the actual implementation of the "genuine" real field. We are barely there, and I think there are many compromises and gray zones possible than just "destroy the current behavior", right?

By the way, has anyone considered my proposal?

Whether we call it "realized", "represented" or "approximately represented", I think this is a good compromise, keeps the description rigorous and makes the step to a "genuine" real field much more comprehensible. I don't mind if you don't agree, but I'm curious about your opinions.

Best,

Michael

Oct 20, 2020, 11:32:00 AM10/20/20

to sage-devel

My perspective is partly coming as someone who has several papers that rely heavily on Sage computations. I've archived the code and data in a permanent fashion, but every backwards incompatible change Sage makes decreases the odds that anyone will be able to easily verify or extend my work five years from now.one needs to maintain the code, one can't just hope it will all magically keep working in newer versions (it won't be true even if it was in plain Python).And in this case a fix is trivial. (and you have a chance to check along the way that it is still working)

Yes, I am all too well-aware that all code requires some level of maintenance. The question is how often and how much, and I don't think the fact that maintenance is inevitable is a good argument for increasing the amount required unnecessarily. Especially in the context of software used by mathematical researchers. Enough trivial changes add up to something nontrivial, and my main point is that for a lot of Sage users, something like this is not trivial and has the potential to turn mathematicians away from Sage to one of the "M" tools that are likely more stable (I'm not sure about that, I of course avoid the M's when at all possible ;-).

Nathan

Oct 20, 2020, 11:39:54 AM10/20/20

to sage-devel

I agree with Nathan and Frédéric about backward compatibility. The original question was about whether to proceed with creating a GenuineRealField object. I'm in favor of progress in that direction! But I'd also like to see what that object looks like before making a decision about changing the behavior of RR and RealField.

David

--

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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/d714fefb-8925-4350-9422-0ebe1fb6ceccn%40googlegroups.com.

Oct 20, 2020, 12:14:32 PM10/20/20

to sage-devel

On Tuesday, October 20, 2020 at 8:39:54 AM UTC-7, David Roe wrote:

I agree with Nathan and Frédéric about backward compatibility. The original question was about whether to proceed with creating a GenuineRealField object. I'm in favor of progress in that direction! But I'd also like to see what that object looks like before making a decision about changing the behavior of RR and RealField.David

I agree as well: it's already possible to start writing AbstractRealField or GenuineRealField: just put them somewhere in their own module. Once the code has been worked out and it's clear in what way they are being used we can look at how inconvenienced people are by having to import the functionality. If that is significant, we can look at where to place the routines in the global scopeand if there is existing functionality that needs to be deprecated in order to make room for it. Don't start breaking compatibility until you have something concrete that allows an assessment of the costs and benefits (in fact, there is an assessment now: there would presently be no benefit because we'd simply be breaking compatibility without having anything to put in its place).

Note that an important application mentioned -- cleaner category tests -- would not really benefit from having AbstractRealField in the global scope, since such stuff mainly happens in library code anyway.

Oct 20, 2020, 2:57:40 PM10/20/20

to sage-devel

On Tuesday, October 20, 2020 at 9:14:32 AM UTC-7, Nils Bruin wrote:

On Tuesday, October 20, 2020 at 8:39:54 AM UTC-7, David Roe wrote:I agree with Nathan and Frédéric about backward compatibility. The original question was about whether to proceed with creating a GenuineRealField object. I'm in favor of progress in that direction! But I'd also like to see what that object looks like before making a decision about changing the behavior of RR and RealField.

I agree as well: it's already possible to start writing AbstractRealField or GenuineRealField: just put them somewhere in their own module. Once the code has been worked out and it's clear in what way they are being used we can look at how inconvenienced people are by having to import the functionality. If that is significant, we can look at where to place the routines in the global scope and if there is existing functionality that needs to be deprecated in order to make room for it. Don't start breaking compatibility until you have something concrete that allows an assessment of the costs and benefits [...]

I agree.

Oct 21, 2020, 4:10:40 AM10/21/20

to sage-devel

+1 for changing printing of RR to something like John Cremona or others have suggested

-1 for changing RR or RealField at this stage. (It is not "progress" to change a name, so does not vouch for breaking backwards compatibility; I may change when and if another serious candidate for RR it is here, but probably not even then.)

Chris

Oct 21, 2020, 5:36:50 AM10/21/20

to sage-devel

We have a *new* problem here :

Sage’s

`NN`

,`ZZ`

and`QQ`

are :- mathematically corect representations of , and respectively,
**and** - provide acceptable implementations of their arithmetics.

- mathematically corect representations of , and respectively,
The algebraic sets

`AA`

and`QQbar`

provide both an acceptable (one could say miraculous) representation of the (real or not) algebraics and an implementation of their respective arithmetics modulo some conventions on representations.

We know that neither nor can have an acceptable representation in machine. So we created *approximate* representation(s) (`RR`

, `RDF`

und so weiter…) of (parts of) these sets, and, until now, refrained to create objects representing the general (abstract) properties of the (mathematical) reals (resp. complexes).

Unfortunately, we used the “easy” names `RR`

and `CC`

for our approximate representations. So, our alternative is:

- keep the “easy” names for the implementations, create new names for the “abstracts” sets (if and when implemented) ; to be consistent, we should also create new names for the “abstract sets representing the naturals, integerts, fractions and algebraics, even if simple synonyms of the implementations.
- keep the “easy” names for the abstract sets and create names for the implementations ; this would introduce a big (?) backward compatibility problem,

Since Sage’s target is mathematicians, I *think* that they may think first in terms of mathematical properties, the implementation being only a secondary concern. Is that “mathematical ease of use” worth the backward-compatibility problem ?

Until I hear more about this tradeoff, I’ll abstain from voting.

One more question : how easy (or difficult) would it be to “trap” operations on reals (resp complexes) needing an implementation to raise a warning (or an exception) (or potentially a silent substitution) if called inadvertently on a member of an “abstract” set ?

Oct 21, 2020, 6:00:03 AM10/21/20

to sage-devel

I think we digressed. The original purpose of this thread was to

discuss https://trac.sagemath.org/ticket/24523 - which

does not change SageMath "language" (i.e. RR, CC etc remain as they

are, for all programming purposes) at all.

In the course of discussion it was pointed out that "Floating-Point

Field" is not quite correct terminology.

Can we finish off with this, so that #24523 can proceed?

On Wed, Oct 21, 2020 at 10:36 AM Emmanuel Charpentier

<emanuel.c...@gmail.com> wrote:

>

> We have a new problem here :

>

> Sage’s NN, ZZ and QQ are :

>

> mathematically corect representations of , and respectively, and

> --

> 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/07d4573e-cce6-4110-abf0-aa7b2800306an%40googlegroups.com.

discuss https://trac.sagemath.org/ticket/24523 - which

does not change SageMath "language" (i.e. RR, CC etc remain as they

are, for all programming purposes) at all.

In the course of discussion it was pointed out that "Floating-Point

Field" is not quite correct terminology.

Can we finish off with this, so that #24523 can proceed?

On Wed, Oct 21, 2020 at 10:36 AM Emmanuel Charpentier

<emanuel.c...@gmail.com> wrote:

>

> We have a new problem here :

>

> Sage’s NN, ZZ and QQ are :

>

> provide acceptable implementations of their arithmetics.

>

> The algebraic sets AA and QQbar provide both an acceptable (one could say miraculous) representation of the (real or not) algebraics and an implementation of their respective arithmetics modulo some conventions on representations.

>

> We know that neither nor can have an acceptable representation in machine. So we created approximate representation(s) (RR, RDF und so weiter…) of (parts of) these sets, and, until now, refrained to create objects representing the general (abstract) properties of the (mathematical) reals (resp. complexes).
>

> The algebraic sets AA and QQbar provide both an acceptable (one could say miraculous) representation of the (real or not) algebraics and an implementation of their respective arithmetics modulo some conventions on representations.

>

>

> Unfortunately, we used the “easy” names RR and CC for our approximate representations. So, our alternative is:

>

> keep the “easy” names for the implementations, create new names for the “abstracts” sets (if and when implemented) ; to be consistent, we should also create new names for the “abstract sets representing the naturals, integerts, fractions and algebraics, even if simple synonyms of the implementations.

> keep the “easy” names for the abstract sets and create names for the implementations ; this would introduce a big (?) backward compatibility problem,

>

> Since Sage’s target is mathematicians, I think that they may think first in terms of mathematical properties, the implementation being only a secondary concern. Is that “mathematical ease of use” worth the backward-compatibility problem ?

>

> Until I hear more about this tradeoff, I’ll abstain from voting.

>

> One more question : how easy (or difficult) would it be to “trap” operations on reals (resp complexes) needing an implementation to raise a warning (or an exception) (or potentially a silent substitution) if called inadvertently on a member of an “abstract” set ?

>

> Le mercredi 21 octobre 2020 à 10:10:40 UTC+2, chris wuthrich a écrit :

>>

>>

>> +1 for changing printing of RR to something like John Cremona or others have suggested

>> -1 for changing RR or RealField at this stage. (It is not "progress" to change a name, so does not vouch for breaking backwards compatibility; I may change when and if another serious candidate for RR it is here, but probably not even then.)

>>

>> Chris

>

> Unfortunately, we used the “easy” names RR and CC for our approximate representations. So, our alternative is:

>

> keep the “easy” names for the implementations, create new names for the “abstracts” sets (if and when implemented) ; to be consistent, we should also create new names for the “abstract sets representing the naturals, integerts, fractions and algebraics, even if simple synonyms of the implementations.

> keep the “easy” names for the abstract sets and create names for the implementations ; this would introduce a big (?) backward compatibility problem,

>

> Since Sage’s target is mathematicians, I think that they may think first in terms of mathematical properties, the implementation being only a secondary concern. Is that “mathematical ease of use” worth the backward-compatibility problem ?

>

> Until I hear more about this tradeoff, I’ll abstain from voting.

>

> One more question : how easy (or difficult) would it be to “trap” operations on reals (resp complexes) needing an implementation to raise a warning (or an exception) (or potentially a silent substitution) if called inadvertently on a member of an “abstract” set ?

>

> Le mercredi 21 octobre 2020 à 10:10:40 UTC+2, chris wuthrich a écrit :

>>

>>

>> +1 for changing printing of RR to something like John Cremona or others have suggested

>> -1 for changing RR or RealField at this stage. (It is not "progress" to change a name, so does not vouch for breaking backwards compatibility; I may change when and if another serious candidate for RR it is here, but probably not even then.)

>>

>> Chris

>

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

Oct 21, 2020, 6:56:40 AM10/21/20

to sage-...@googlegroups.com

Thanks Dima. To my mind, the thread has shown that some

questions have to be settled first. I am trying to gather

the relevant comments, ignoring completely the genuine

real field (which is one motivation but not the purpose

of the ticket). This is a personal interpretation of what

happened. Feel free to correct me.

One proposal consisted to discard the "field" terminology

(J. Cremona, S. Lelievre)

"Real Floating-Point Numbers with x bits of precision"

or

"Real Floats with x bits of precision"

These proposals describe somehow accurately the set but

completely discard the importance of the underlying algebraic

structure. Here was proposed "pseudo-field" and "quasi-field"

(M. Jung). I think that both of these names are bad because

"pseudo" and "quasi" are used in many mathematical concepts

but here would refer to non standard terminology. I proposed

"numerical field" which is also an invented concept

but has the advantage to fit well with the "is_exact()"

method already present on some parents.

So question number 1:

1. Should we drop any reference to the algebraic structure

for numerical approximations?

(J. Cremona, S. Lelievre)

2. Should we have a common adjective for all approximations?

Which one "pseudo", "quasi", "numerical", "nonexact", ...?

Should we differentiate various kind of approximations (eg

floating-point vs balls/intervals, various flavors of p-adics)?

Parallel to this question is the "categorical" version

1'. Should RealField simply be a member of the Sets() category?

2'. Should we develop some categorical machinery to differentiate

exact fields from approximate fields? Which one?

Best

Vincent

questions have to be settled first. I am trying to gather

the relevant comments, ignoring completely the genuine

real field (which is one motivation but not the purpose

of the ticket). This is a personal interpretation of what

happened. Feel free to correct me.

One proposal consisted to discard the "field" terminology

(J. Cremona, S. Lelievre)

"Real Floating-Point Numbers with x bits of precision"

or

"Real Floats with x bits of precision"

These proposals describe somehow accurately the set but

completely discard the importance of the underlying algebraic

structure. Here was proposed "pseudo-field" and "quasi-field"

(M. Jung). I think that both of these names are bad because

"pseudo" and "quasi" are used in many mathematical concepts

but here would refer to non standard terminology. I proposed

"numerical field" which is also an invented concept

but has the advantage to fit well with the "is_exact()"

method already present on some parents.

So question number 1:

1. Should we drop any reference to the algebraic structure

for numerical approximations?

(J. Cremona, S. Lelievre)

2. Should we have a common adjective for all approximations?

Which one "pseudo", "quasi", "numerical", "nonexact", ...?

Should we differentiate various kind of approximations (eg

floating-point vs balls/intervals, various flavors of p-adics)?

Parallel to this question is the "categorical" version

1'. Should RealField simply be a member of the Sets() category?

2'. Should we develop some categorical machinery to differentiate

exact fields from approximate fields? Which one?

Best

Vincent

Oct 21, 2020, 7:43:43 AM10/21/20

to sage-devel

On Wed, Oct 21, 2020 at 11:56 AM Vincent Delecroix

Unfortunately nobody has written an adapted to mathematicians version of

the classic "What Every Computer Scientist Should Know About

Floating-Point Arithmetic", by David Goldberg :-)

I gather that (ignoring NaNs and +/-infinities)

the addition and multiplication are commutative here, but not associative,

and not distributive. Moreover none of these is a quasigroup.

Looks like not enough to coordinatise a projective plane. :-)

As far as I am concerned, putting Field in "" will do, to raise

the awareness that it's not a field.

>

> Parallel to this question is the "categorical" version

>

> 1'. Should RealField simply be a member of the Sets() category?

>

> 2'. Should we develop some categorical machinery to differentiate

> exact fields from approximate fields? Which one?

>

> Best

> Vincent

>

> --

> 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/b4e612ec-e4cc-23ac-25c3-e409b93102df%40gmail.com.

the classic "What Every Computer Scientist Should Know About

Floating-Point Arithmetic", by David Goldberg :-)

I gather that (ignoring NaNs and +/-infinities)

the addition and multiplication are commutative here, but not associative,

and not distributive. Moreover none of these is a quasigroup.

Looks like not enough to coordinatise a projective plane. :-)

As far as I am concerned, putting Field in "" will do, to raise

the awareness that it's not a field.

>

> Parallel to this question is the "categorical" version

>

> 1'. Should RealField simply be a member of the Sets() category?

>

> 2'. Should we develop some categorical machinery to differentiate

> exact fields from approximate fields? Which one?

>

> Best

> Vincent

>

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

Oct 21, 2020, 10:27:21 AM10/21/20

to sage-...@googlegroups.com

On 10/20/20 11:32 AM, Nathan Dunfield wrote:

>

> Yes, I am all too well-aware that all code requires some level of

> maintenance. The question is how often and how much, and I don't think

> the fact that maintenance is inevitable is a good argument for

> increasing the amount required unnecessarily. Especially in the context

> of software used by mathematical researchers. Enough trivial changes

> add up to something nontrivial, and my main point is that for a lot of

> Sage users, something like this is not trivial and has the potential to

> turn mathematicians away from Sage to one of the "M" tools that are

> likely more stable (I'm not sure about that, I of course avoid the M's

> when at all possible ;-).

>

This is a bit of a digression, but I personally take the Linux kernel
>

> Yes, I am all too well-aware that all code requires some level of

> maintenance. The question is how often and how much, and I don't think

> the fact that maintenance is inevitable is a good argument for

> increasing the amount required unnecessarily. Especially in the context

> of software used by mathematical researchers. Enough trivial changes

> add up to something nontrivial, and my main point is that for a lot of

> Sage users, something like this is not trivial and has the potential to

> turn mathematicians away from Sage to one of the "M" tools that are

> likely more stable (I'm not sure about that, I of course avoid the M's

> when at all possible ;-).

>

approach with my own published code. The SageMath website can make

whatever guarantees it wants about backwards-compatibility, but the

reality is -- especially in a dynamic language -- that it's quite

impossible to not break anything at all. Nobody has time to deprecate

every buggy result, and many things simply can't be deprecated.

But, SageMath is open source. And like the Linux kernel, it's pretty

accepting of strange research algorithms useful to like five people on

the planet. We also have an *enforced* policy of not breaking existing

doctests... which means that we can't break library code, since "all"

library code is tested.

So, when I publish an algorithm, I add the code to Sage itself. The

output in the paper may become obsolete, but when readers follow the

reference, they should get some nice, up-to-date, working documentation

and a potentially improved implementation.

Oct 21, 2020, 1:10:01 PM10/21/20

to sage-...@googlegroups.com

Nathan Dunfield wrote:

> -1: I don't really care what RealField.__repr__ returns, but cast a

> token no vote to object to the logical next move of breaking backwards

> compatibility by changing the meaning of RealField and/or RR. I see

> the need for a "genuine real field", but it seems a lot simpler just

> to call it something other than "RealField" and so not break a lot of

> existing users' Sage code.

I agree.
> -1: I don't really care what RealField.__repr__ returns, but cast a

> token no vote to object to the logical next move of breaking backwards

> compatibility by changing the meaning of RealField and/or RR. I see

> the need for a "genuine real field", but it seems a lot simpler just

> to call it something other than "RealField" and so not break a lot of

> existing users' Sage code.

More precisely, I am in favor of changing the string representation so

that it contains the word "floating-point". I don't care about the

exact wording.

However, I think that the drawbacks of changing the meaning of RealField

or RR greatly outweigh the benefits (at least now, probably also in the

long term, but I might change my mind if a really useful

AbstractRealField is ever implemented). To the backward compatibility

reasons others have mentioned, I would add that for many people, "real

numbers" in a "computational" context *does* mean floating-point

numbers!

--

Marc

Oct 21, 2020, 2:45:19 PM10/21/20

to sage-...@googlegroups.com

Rather than pseudo fields I would advocate for an "axiom" such

as

sage: Sets().Finite()

Category of finite sets

we could have

sage: Fields().Exact()

Category of exact fields

and

sage: Fields().Numerical()

Category of numerical fields

The reason is that in some situations you don't want to

differentiate between the two and being an approximate

or exact field does not matter much. Also, I am not sure

the granularity is good enough as we have two very different

kinds of "Numerical"

- truncation (floating-point): numbers are somehow exact but

operations are approximate

- guaranteed (intervals and balls): numbers are fuzzy but operations

are guaranteed

For the actual content of the ticket, to my mind "Floating-Point"

is explanatory in itself. Your proposition

> "Real Field realized by Floating-point arithmetics of precision xx"

is a bit heavy. And the "realized" is not precise enough (ie no

mathematical well-defined meaning).

as

sage: Sets().Finite()

Category of finite sets

we could have

sage: Fields().Exact()

Category of exact fields

and

sage: Fields().Numerical()

Category of numerical fields

The reason is that in some situations you don't want to

differentiate between the two and being an approximate

or exact field does not matter much. Also, I am not sure

the granularity is good enough as we have two very different

kinds of "Numerical"

- truncation (floating-point): numbers are somehow exact but

operations are approximate

- guaranteed (intervals and balls): numbers are fuzzy but operations

are guaranteed

For the actual content of the ticket, to my mind "Floating-Point"

is explanatory in itself. Your proposition

> "Real Field realized by Floating-point arithmetics of precision xx"

mathematical well-defined meaning).

Oct 21, 2020, 5:14:45 PM10/21/20