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

[Vincent Delecroix]

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]

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]

A big +1 from my side.

Eric.

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

[Dima Pasechnik]

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]

+1

[Michael Jung]

+1 from my side, too.

[Thierry]

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]

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]

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]

[Kwankyu Lee]

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

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

-1, agreed with Nathan Dunfield

[Dima Pasechnik]

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]

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]

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]

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]

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]

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.

[Michael Jung]

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]

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]

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.

[Nils Bruin]

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]

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]

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

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 ?

​

[Dima Pasechnik]

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]

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]

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]

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]

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]

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]

Getting back on topic as kindly requested

(apologies for the wild digression earlier).

The docstring for `RR` currently reads:

```

sage: RR?

Type:           RealField_class

String form:    Real Field with 53 bits of precision

File:           /opt/s/sage92b6/local/lib/python3.8/site-packages/sage/rings/real_mpfr.pyx

Docstring:

   An approximation to the field of real numbers using floating point

   numbers with any specified precision. Answers derived from

   calculations in this approximation may differ from what they would

   be if those calculations were performed in the true field of real

   numbers. This is due to the rounding errors inherent to finite

   precision calculations.

   See the documentation for the module "sage.rings.real_mpfr" for

   more details.

```

which very adequately

- starts with the words "an approximation to the field

  of real numbers using floating point numbers"

- ends with a reference to the sage.rings.real_mpfr documentation,

  which itself, as accessed by `sage: sage.rings.real_mpfr?`,

  clearly formulates what we are dealing with.

So I think we're mostly fine, but I understand the need

to clarify the string representation.

The first sentence in the `RR` docstring suggests we could replace

the current string forms:

```

sage: RealField(8)

Real Field with 8 bits of precision

sage: RealField()

Real Field with 53 bits of precision

sage: RR

Real Field with 53 bits of precision

```

with the following ones:

```

sage: RealField(8)

Real Field approximation with 8 bits of precision

sage: RealField()

Real Field approximation with 53 bits of precision

sage: RR

Real Field approximation with 53 bits of precision

```

or if we need something shorter:

```

sage: RealField(8)

Real Field 8 bit approximation

sage: RealField()

Real Field 53 bit approximation

sage: RR

Real Field 53 bit approximation

```

I'm also fine with other suggested solutions.

[Volker Braun]

On Wednesday, October 21, 2020 at 1:43:43 PM UTC+2 dim...@gmail.com wrote:

I gather that (ignoring NaNs and +/-infinities)
the addition and multiplication are commutative here

Actually not even x+y == x+y is guaranteed and may fail once you let the optimizer loose ;)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

[Emmanuel Charpentier]

[ Snip... ]

 

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!

That's a bad (filthy ?) habit 60+ years of "scientific computing" indoctrinated us into, and that we should get rid of... if we can ! This of course hasn't even the slightest chance of working but for a convenient and reasonably efficient implementation of $\mathbb{R}$ (resp. $\mathbb{C}$...

 

--
Marc

[Fredrik Johansson]

Currently working on that (see http://fredrikj.net/calcium/ and http://fredrikj.net/blog/2020/09/benchmarking-exact-dft-computation/).

But "convenient and reasonably efficient" is relative, and there are truly no silver bullets in this domain...

Fredrik

 

[Kwankyu Lee]

Currently working on that (see http://fredrikj.net/calcium/ and http://fredrikj.net/blog/2020/09/benchmarking-exact-dft-computation/).

Looks great! The standard question is then: do you think your library fits for the throne of RealField and could rule peacefully other "real fields" of Sage? 

[Vincent Delecroix]

The answer is no. The GenuineRealField is not meant to have elements.
Even though Calcium is doing an amazing job at symbolic computations
with real numbers and might contain all other exact implementations
there is in SageMath, it will remain a set of computable real
numbers. That is a tiny subset of all the real numbers.

The need for a GenuineRealField is explained in

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

Vincent

[Fredrik Johansson]

On Fri, Oct 23, 2020 at 8:38 AM Kwankyu Lee <ekwa...@gmail.com> wrote:

Currently working on that (see http://fredrikj.net/calcium/ and http://fredrikj.net/blog/2020/09/benchmarking-exact-dft-computation/).

Looks great! The standard question is then: do you think your library fits for the throne of RealField and could rule peacefully other "real fields" of Sage? 

I'm not sure if there can be such a field. For exact use, perhaps. In general, Calcium will be much slower than RR or RBF if you just want numerical values. It will be terrible for plotting, for example. In any case, there would probably not be a unique "Calcium field" -- you would be able to create different fields with different internal simplification behavior (absolute vs relative algebraic numbers, expanding complex exponentials into real and imaginary parts, etc.).

The other main alternative that I can see would be lightweight symbolic expression DAGs for "lazy computable numbers" (something I'm also interested in). That would give you relatively cheap numerical evaluation and the opportunity to fall back to exact simplification for deciding predicates. The problem is when expressions start building up without simplifying, say (((((x+1)-1)+1)-1)...). Again, no silver bullet.

Fredrik

[Dima Pasechnik]

we are talking about MPFR floats here, not the bare metal (RDF).
Not sure if MPFR are slightly less insane.

Otherwise, yes, to quote a comment on bugzilla/show_bug.cgi?id=323:

I'd like to welcome the newest members of the bug 323 community, where all x87
floating point errors in gcc come to die! All floating point errors that use
the x87 are welcome, despite the fact that many of them are easily
fixable, and
many are not! We're all one happy family, making the egregious
mistake of wanting
accuracy out of the most accurate general purpose FPU on the market!

>
> --
> 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/ca1e2497-e7df-43f5-97fc-72d1a837ff33n%40googlegroups.com.

[Dima Pasechnik]

On Fri, Oct 23, 2020 at 8:04 AM Vincent Delecroix

<20100.d...@gmail.com> wrote:
>
> Le 23/10/2020 à 08:38, Kwankyu Lee a écrit :
> >
> >>
> >> Currently working on that (see http://fredrikj.net/calcium/ and
> >> http://fredrikj.net/blog/2020/09/benchmarking-exact-dft-computation/).
> >>
> >
> > Looks great! The standard question is then: do you think your library fits
> > for the throne of RealField and could rule peacefully other "real fields"
> > of Sage?
> >
>
> The answer is no. The GenuineRealField is not meant to have elements.

Are we now into computing with uncomputable ?
The next non-virtual Sagemath event is in danger of turning into a bacchanalia,
as it'll have unlimited supply of wine from an unmeasurable bottle
from Bordeaux... :P

For all practical purposes, it seems that Calcium is ripe for becoming an
important part of Sage. Anyone working on it?

Dima

> Even though Calcium is doing an amazing job at symbolic computations
> with real numbers and might contain all other exact implementations
> there is in SageMath, it will remain a set of computable real
> numbers. That is a tiny subset of all the real numbers.
>
> The need for a GenuineRealField is explained in
>
> https://trac.sagemath.org/ticket/24456
>
> 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/bab7621b-8b98-9026-ad61-65567975f32f%40gmail.com.

[Vincent Delecroix]

Le 23/10/2020 à 10:27, Dima Pasechnik a écrit :
> On Fri, Oct 23, 2020 at 8:04 AM Vincent Delecroix
> <20100.d...@gmail.com> wrote:
>>
>> Le 23/10/2020 à 08:38, Kwankyu Lee a écrit :
>>>
>>>>
>>>> Currently working on that (see http://fredrikj.net/calcium/ and
>>>> http://fredrikj.net/blog/2020/09/benchmarking-exact-dft-computation/).
>>>>
>>>
>>> Looks great! The standard question is then: do you think your library fits
>>> for the throne of RealField and could rule peacefully other "real fields"
>>> of Sage?
>>>
>>
>> The answer is no. The GenuineRealField is not meant to have elements.
>
> Are we now into computing with uncomputable ?

What are you talking about? The set of real numbers is perfectly
manageable by a computer. Its elements are not. For example, the
genuine real field would be used for things like

sage: QQ.metric_completion()
Real Field
sage: RR.is_complete()
True

It is explained in https://trac.sagemath.org/ticket/24456 and you
are welcome to participate.

[Dima Pasechnik]

On Fri, Oct 23, 2020 at 11:19 AM Vincent Delecroix

<20100.d...@gmail.com> wrote:
>
> Le 23/10/2020 à 10:27, Dima Pasechnik a écrit :
> > On Fri, Oct 23, 2020 at 8:04 AM Vincent Delecroix
> > <20100.d...@gmail.com> wrote:
> >>
> >> Le 23/10/2020 à 08:38, Kwankyu Lee a écrit :
> >>>
> >>>>
> >>>> Currently working on that (see http://fredrikj.net/calcium/ and
> >>>> http://fredrikj.net/blog/2020/09/benchmarking-exact-dft-computation/).
> >>>>
> >>>
> >>> Looks great! The standard question is then: do you think your library fits
> >>> for the throne of RealField and could rule peacefully other "real fields"
> >>> of Sage?
> >>>
> >>
> >> The answer is no. The GenuineRealField is not meant to have elements.
> >
> > Are we now into computing with uncomputable ?
>
> What are you talking about? The set of real numbers is perfectly
> manageable by a computer. Its elements are not. For example, the
> genuine real field would be used for things like
>
> sage: QQ.metric_completion()
> Real Field
> sage: RR.is_complete()
> True

Right, but how is it useful for a CAS, apart from pedagogical purposes
(it certainly is useful in a proof assistant, though) ?
No computable subfield would be complete, anyway.

>
> It is explained in https://trac.sagemath.org/ticket/24456 and you
> are welcome to participate.


>
> > The next non-virtual Sagemath event is in danger of turning into a bacchanalia,
> > as it'll have unlimited supply of wine from an unmeasurable bottle
> > from Bordeaux... :P
> >
> > For all practical purposes, it seems that Calcium is ripe for becoming an
> > important part of Sage. Anyone working on it?
> >
> > Dima
> >
> >> Even though Calcium is doing an amazing job at symbolic computations
> >> with real numbers and might contain all other exact implementations
> >> there is in SageMath, it will remain a set of computable real
> >> numbers. That is a tiny subset of all the real numbers.
> >>
> >> The need for a GenuineRealField is explained in
> >>
> >> https://trac.sagemath.org/ticket/24456
> >>
> >> 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/bab7621b-8b98-9026-ad61-65567975f32f%40gmail.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.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/4b1546d2-4b62-edf5-163c-08693274a8a6%40gmail.com.

[Kwankyu Lee]

On Friday, October 23, 2020 at 4:13:52 PM UTC+9 Fredrik Johansson wrote:

I'm not sure if there can be such a field. For exact use, perhaps. In general, Calcium will be much slower than RR or RBF if you just want numerical values. It will be terrible for plotting, for example. In any case, there would probably not be a unique "Calcium field" -- you would be able to create different fields with different internal simplification behavior (absolute vs relative algebraic numbers, expanding complex exponentials into real and imaginary parts, etc.).

The legend of RealField, as I heard, tells  that it is really an illusion of the real field in which you compute symbolically but exactly. Internally different fields are created but they all cooperate to create the illusion. It walks slow but exact. Numerical battles are just delegated to the other "real fields".

If it is possible though not perfect, I would prefer it to an abstract ghost. 

[kcrisman]

If it is possible though not perfect, I would prefer it to an abstract ghost. 

So we should also start adding infinitesimals [1] to the RealField as well? ;-)  

[1] cf. Berkeley's "ghosts of departed quantities"

[Dima Pasechnik]

well, for doing various things in real algebraic geometry, one
certainly needs fields of Puiseux series, with (non-Archimedean)
ordering
dictated by 0<<e<<1, so that ne<1 for all natural n. :P

> --
> 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/4f5bd614-20ca-45c1-9514-9aedb21ca086o%40googlegroups.com.

[Emmanuel Charpentier]

You might as well create support for nonstandard analysis (which would be eased  by some form of intuitionist logic in the framework...).

We're no longer in Kan^Ka CAS, Toto... But that could be a fine use of Sage, bridging to proof systems. Maybe a separate development, to be merged when ready (à la differentiable manifolds...).

[Michael Jung]

Hi,

so, what's the punch line now? I totally lost track because we digressed too much. Is the representation change still wanted or not? And if so, what shall be it? I would like to conclude https://trac.sagemath.org/ticket/24523.

Best,
Michael