Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"
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. Le 15/10/2020 à 11:24, Samuel Lelievre a écrit : 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? -- 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/1871a4a7-47fc-e585-ebfa-813d6d4cc9de%40gmail.com.
Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"
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. -- 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/4ce80aa7-ca26-4f08-9be9-5ef30824c039n%40googlegroups.com.
Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"
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. -- 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/7ad9b5aa-9f9e-4eb6-95b5-c788b7f646cfo%40googlegroups.com.
Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"
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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/6fc17ac7-284c-4041-8e99-ea36cd15134do%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/20201015195352.tkua3pfntezfrkuu%40metelu.net.
Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"
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. -- 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/6fc17ac7-284c-4041-8e99-ea36cd15134do%40googlegroups.com.
Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"
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 -- 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/9ad6b7ca-1a91-4753-8b43-a8f939e98ebdn%40googlegroups.com.
Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"
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 > This is a big change, so we should make sure that many people have a > chance to give their opinion. > > John > > On Thu, 15 Oct 2020 at 10:24, Samuel Lelievre > wrote: > > > > 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? > > > > -- > > 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+unsubscr...@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. > > -- > 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/CAD0p0K5%2BSB9%2BNR8j%3DuQdTkrQC2tp5WXurS7aQQtqiuL9vv%2B_Gg%40mail.gmail.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/20201015105549.y42ox7ytzh52trbs%40metelu.net.
Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"
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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/2fd10f7c-4e65-4800-b32f-e7b208ad63cbn%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/20201015104504.5uv7btpcqyrss5gg%40metelu.net.
Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"
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 On Thu, 15 Oct 2020 at 10:24, Samuel Lelievre wrote: > > 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? > > -- > 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+unsubscr...@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. -- 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/CAD0p0K5%2BSB9%2BNR8j%3DuQdTkrQC2tp5WXurS7aQQtqiuL9vv%2B_Gg%40mail.gmail.com.
[sage-devel] missing docker images of sagemath
Bonjour, Thanks to Vincent, I learned recently how to use continuous integration in gitlab and the docker images of previous versions of sage posted https://hub.docker.com/r/sagemath/sagemath-dev/ in order to test that my optional package works with all those versions. It basically made me realize that my package was broken on most versions of sage except the most recent. And hopefully soon, I will be able to fix those issues. So thanks to those involved in having these various docker images available. For the curious, the most recent run is available here: https://gitlab.com/seblabbe/slabbe/-/pipelines/202932270 it shows that my package works for 9.1.rc5 but not 9.0 or earlier versions (I need to work on it). Unfortunately, it seems the docker images of various versions of sage are not uploaded since 4 months. Maybe it was too much energy to upload all beta versions there. In fact, I don't really need all beta in there. What I think is important to have are the final releases. With that respect, the following are missing: 8.6: ok 8.7: ok 8.8: ok 8.9 is missing or is broken 9.0 : ok 9.1 is missing (so I am using 9.1.rc5 and 9.1.rc5-py3) No 9.2.betaX are there, but I would be happy that 9.2 be there when released. Thanks to the people involved. Sincerely, Sébastien -- 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/b9c33f11-804a-48a0-ba2d-04eb5d5b7c3bn%40googlegroups.com.
Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"
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? -- 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/cd24bb8e-ab14-43be-ada6-7da6a720ae4fo%40googlegroups.com.
Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"
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 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+unsubscr...@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.
Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"
> > +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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/c96bd84e-68cb-4bec-a659-ec42e47d6c58n%40googlegroups.com.
