Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"
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. -- 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/4cfaa8d1-b8b6-4ac6-bce9-0b8633ce68a6o%40googlegroups.com.
Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"
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). Le 19/10/2020 à 16:40, Michael Jung a écrit : 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 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/6b55f85a-3830-3d10-16ef-b7f6627d9340%40gmail.com.
[sage-devel] Global Virtual Sage Days 110 - October 29-30, 2020 (all timezones) Announcement
The Global Virtual Sage Days 110 will take place from Thursday, October, 29th, 2020 at 08:00 UTC through Friday, October, 30th, 2020 at 24:00 UTC. All talks will be taking place via videoconferencing software such as Zoom and BigBlueButton. Information about each talk will appear on the Sage Days 110 Zulip stream. The schedule of talks will be released soon. To register, please use the Sage Days 110 Zulip stream: https://zulip.sagemath.org/#narrow/stream/128-sd110/topic/Registration Registration is free. For more information, please visit - the conference website at https://wiki.sagemath.org/days110 - the stream #sd110 on https://zulip.sagemath.org/ Confirmed Speakers: - Katja Berčič, KWARC, University of Ljubljana - Rekha Biswal, Max Planck Institute, Germany - Guy Blachar, Bar-Ilan University, Israel - Erik Bray, LRI, Université Paris-Saclay, France - David Coudert, Inria and COATI, France - Isuru Fernando, University of Illinois, USA - Éric Gourgoulhon, CNRS, France - Reimundo Heluani, Instituto de Matemática Pura e Aplicada, Brazil - Ben Hutz, Saint Louis University, USA - Michael Jung, Vrije Universiteit Amsterdam, Netherlands - Simon King, Friedrich-Schiller-Universität Jena, Germany - Matthias Köppe, UC Davis, USA - Alba Málaga, albamath.com - Miguel Marco-Buzunariz, Universidad de Zaragoza, Spain - Jianping Pan, UC Davis, USA - Dima Pasechnik, University of Oxford, UK - Wencin Poh, UC Davis, USA - Viviane Pons, Paris-Saclay University, France - Amri Prasad, Instiute of Mathematical Sciences, India - Anna Puskas, University of Queensland, Australia - Tom Roby, University of Connecticut, USA - Tobias Rossmann, NUI Galway, Ireland - Martin Rubey, TU Wien, Austria - Jessica Striker, North Dakota State University, USA - https://mathics.org/ We look forward to seeing you at the online Sage Days 110. The Sage Days 110 Organizers, Tomer Bauer, Samuel Lelièvre, Julian Rüth, Travis Scrimshaw, and Yuan Zhou -- 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/d3c4ab42-4aa3-4904-822d-e31c51f89421n%40googlegroups.com.
[sage-devel] Re: "Real Field" -> "Real Floating-point Field"
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 -- 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/rmpq0o%24ec8%241%40ciao.gmane.io.
Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"
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. -- 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/c8785199-3c8f-9de8-8a73-74438bccfc91%40orlitzky.com.
Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"
On Wed, Oct 21, 2020 at 11:56 AM Vincent Delecroix <20100.delecr...@gmail.com> wrote: > > 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)? 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+unsubscr...@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. -- 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/CAAWYfq33HBavwuerRN9nrNg5UVGsnuTCxdWe65N37WXzZpTd2Q%40mail.gmail.com.
Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"
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 -- 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/b4e612ec-e4cc-23ac-25c3-e409b93102df%40gmail.com.
Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"
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 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.
Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"
We have a *new* problem here :
-
Sage’s NN, ZZ and QQ are :
- mathematically corect representations of [image: \mathbb{N}], [image:
\mathbb{Z}] and [image: \mathbb{Q}] 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 [image: \mathbb{R}] nor [image: \mathbb{C}] 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.
Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"
+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/b437be3b-27e0-4a9b-8714-7f249a6762f2n%40googlegroups.com.
