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 <samuel.lelie...@gmail.com> 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.
