On Tuesday, 18 April 2023 at 11:33:38 UTC-7 aw wrote: On Monday, April 17, 2023 at 6:24:13 PM UTC-6 Nils Bruin wrote:
On Monday, 17 April 2023 at 16:39:01 UTC-7 aw wrote: If properly implemented, it can emulate exact computation followed by a truncation to finite precision. When I say a very high precision environment is for doing exact computation, I don't mean that it should handling infinite digit strings. I mean that the input-output function for such an environment should be identical to the input-output function of a hypothetical environment that *does* do the full exact computation and then truncates the answer to the requested precision. In other words, a very high precision environment should emulate an environment that does the full exact computation and truncates the result to finite precision before giving it to the user. And, this emulation should be perfect. Unfortunately, not for a fixed precision. If you're working with 200 bits precision, then you cannot express the roots of x^2-3 and x^2-(3+2^-200) as different floating point numbers. They are too close for that. In that case the environment sees the two roots as having the same value, which to 200 bits may be absolutely correct. In that case the environment *is* perfectly emulating an exact calculation truncated or rounded to 200 bits, as it is required to do. I think your comment here is based on a subtle mistake in thinking about the precision parameter. You're thinking of it as the precision of the internal calculations in the implementation of the environment. In effect, you're assuming a certain kind of implementation, something like a fixed grid of binary fractions. But the environment can use any implementation, not just that one. In such a computational model, there is no reason to carry around the 200 through the computations. In that case you just compute with the objects "lazily" and once you want to get 200 digits approximating the number you're interested in, you just ask "what is the 200 digit approximation to this number". You can then turn around and ask for the 400 digit approximation as well and instead of having to start from scratch, the system can just continue refining its approximation using the work it's already done. This is implemented already. In AlgebraicField for algebraic numbers and in RealLazyField for loads of computable transcendental numbers too. The difficult question in computation doesn't tend to be "what is the 200 digit approximation to this number" it's "are these two quantities obtained through different computations actually equal". AlgebraicField and RealLazyField try to do that as well (but I suspect with limitations for the latter). What is presently called RealField is fundamentally not that. In the medium future, it may well be the case that RealLazyField will feature much more prominently in sagemath as a computational model for real numbers, but the current implementation is still under quite active development and, while usable, not quite ready to be a *default* in sagemath. Example: sage: R=RealLazyField() sage: a=cos(R.pi()/13) sage: a.numerical_approx(200) 0.97094181742605202715698227629378922724986510573900358858764 sage: a.numerical_approx(400) 0.970941817426052027156982276293789227249865105739003588587644526477041708760006676932574606408384261554438205497500991925 sage: a.numerical_approx(800) 0.970941817426052027156982276293789227249865105739003588587644526477041708760006676932574606408384261554438205497500991925446304849693046415555347324930136179166290724598721026150846791024698868142304028116956960541355031116767265861274416574 Once again, someone who's looking for standard scientific computation tools and gets confronted with this instead will be very disappointed because performance will be way different and generally MUCH slower. So a general purpose computer algebra system would need both, as sagemath has. -- 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/ffec5ae8-3500-4444-a8b4-bf2e71bf8bc7n%40googlegroups.com.
