--
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/e2d5c7e3-a311-4ec7-b612-c698f27e10ddn%40googlegroups.com.
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".
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".
+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.
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 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.
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
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.
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 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.
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)
--
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/d714fefb-8925-4350-9422-0ebe1fb6ceccn%40googlegroups.com.
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 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 [...]
We have a new problem here :
Sage’s NN
, ZZ
and QQ
are :
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:
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 ?
I gather that (ignoring NaNs and +/-infinities)
the addition and multiplication are commutative here
[ Snip... ]
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
Currently working on that (see http://fredrikj.net/calcium/ and http://fredrikj.net/blog/2020/09/benchmarking-exact-dft-computation/).
Currently working on that (see http://fredrikj.net/calcium/ and http://fredrikj.net/blog/2020/09/benchmarking-exact-dft-computation/).Looks great! The standard question is then: do you think your library fits for the throne of RealField and could rule peacefully other "real fields" of Sage?
I'm not sure if there can be such a field. For exact use, perhaps. In general, Calcium will be much slower than RR or RBF if you just want numerical values. It will be terrible for plotting, for example. In any case, there would probably not be a unique "Calcium field" -- you would be able to create different fields with different internal simplification behavior (absolute vs relative algebraic numbers, expanding complex exponentials into real and imaginary parts, etc.).
If it is possible though not perfect, I would prefer it to an abstract ghost.