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.charpent...@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+unsubscr...@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. -- 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/CAAWYfq0BowgaHq0ahXJrjBhLikeqVL8RyYgM8f7KJ2p0gQ__Og%40mail.gmail.com.
