"Real Field" -> "Real Floating-point Field"

445 views
Skip to first unread message

Vincent Delecroix

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

Emmanuel Charpentier

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

Eric Gourgoulhon

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

Dima Pasechnik

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

Samuel Lelievre

unread,
Oct 14, 2020, 5:13:04 AM10/14/20
to sage-devel
+1

Michael Jung

unread,
Oct 14, 2020, 5:13:29 AM10/14/20
to sage-devel
+1 from my side, too.

Thierry

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

Matthias Koeppe

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

Travis Scrimshaw

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

Thierry Dumont

unread,
Oct 15, 2020, 2:01:55 AM10/15/20
to sage-...@googlegroups.com
tdumont.vcf

Kwankyu Lee

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

 

John Cremona

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

Samuel Lelievre

unread,
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?

John Cremona

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

Thierry

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

Thierry

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

Michael Jung

unread,
Oct 15, 2020, 8:14:03 AM10/15/20
to sage-devel
Hi everyone,

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.


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

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

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.

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

Big +1!

Best,
Michael


Nils Bruin

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

Thierry

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

Nils Bruin

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

Kwankyu Lee

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

 

Vincent Delecroix

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

Michael Jung

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

Nathan Dunfield

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

Frédéric Chapoton

unread,
Oct 20, 2020, 3:07:05 AM10/20/20
to sage-devel
-1, agreed with Nathan Dunfield

Dima Pasechnik

unread,
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 :-)
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.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/d9e2e654-6cb8-42b7-821f-2be818332451n%40googlegroups.com.

Samuel Lelièvre

unread,
Oct 20, 2020, 4:31:21 AM10/20/20
to Sage-devel
Le ven. 16 oct. 2020 à 07:50, Vincent Delecroix:
>
> 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,
but I'm not strongly attached to it.

Michael Orlitzky

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

Nathan Dunfield

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

Nathan

Michael Orlitzky

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

Dima Pasechnik

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

Michael Jung

unread,
Oct 20, 2020, 10:58:42 AM10/20/20
to sage-devel
Dear all,

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

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?

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

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

Nathan Dunfield

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

David Roe

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

Nils Bruin

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

Matthias Koeppe

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

chris wuthrich

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

Emmanuel Charpentier

unread,
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 \mathbb{N}, \mathbb{Z} and \mathbb{Q} respectively, and
    • 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 \mathbb{R} nor \mathbb{C} 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 ?

Dima Pasechnik

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

Vincent Delecroix

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

Dima Pasechnik

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

Michael Orlitzky

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

Marc Mezzarobba

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

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

Vincent Delecroix

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

Samuel Lelievre

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