Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"

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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/56ad6138-92ef-4a55-a986-e747550bdd16o%40googlegroups.com.

Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"

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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/181b3f35-e443-4ee4-95c6-0942d1a56325o%40googlegroups.com.

Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"

[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

On Tue, Oct 20, 2020 at 11:32 AM Nathan Dunfield 
wrote:

> 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
>
> --
> 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+unsubscr...@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
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAChs6_%3D%2BtOWRJLDCpJZ3EUzPmRmJtpxjTH1A80-jEXUiMeS2fQ%40mail.gmail.com.

Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"

[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

-- 
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+unsubscr...@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.

Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"

[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

dim...@gmail.com schrieb am Dienstag, 20. Oktober 2020 um 16:28:19 UTC+2:

>
>
> On Tue, 20 Oct 2020, 15:12 Nathan Dunfield,  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
>>  
>> 
>> .
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ac1ab546-428c-4500-8f86-a558d4a03224n%40googlegroups.com.

Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"

[Dima Pasechnik]

On Tue, 20 Oct 2020, 15:12 Nathan Dunfield,  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+unsubscr...@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
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq2AWUsk9nkUzhjUQ-msZmqgCLen6sUG9v4XA0A9fZP5TQ%40mail.gmail.com.

Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"

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

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/81c97896-623e-d6f6-9cc1-e4c446fe9346%40orlitzky.com.

Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"

[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

-- 
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+unsubscr...@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.

Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"

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


--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/f043b40e-d48d-96c4-2cbb-31e1f19211c1%40orlitzky.com.

Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"

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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAEcArF2EXURmwUESOEmj_BCQruaOoUo9uzfYoCpUOUzXJm3-Ww%40mail.gmail.com.

Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"

[Dima Pasechnik]

On Tue, Oct 20, 2020 at 8:07 AM Frédéric Chapoton  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+unsubscr...@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.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq1igQazowjxCesBi2nPdkGABX59Kuzmt2xEfWE3gro3Ng%40mail.gmail.com.

[sage-devel] Re: "Real Field" -> "Real Floating-point Field"

[Frédéric Chapoton]

-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.
>
> 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+unsubscr...@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.