On Tue, 18 Apr 2023, 19:33 aw, <aw.phone.00...@gmail.com> 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. > > For general environments, the right way to think of the precision > parameter is, it's the required precision in the output. The internals of > the environment are free to work in any precision, including infinite > precision. Integer calculations are infinite precision. If the environment > internals use only integer math to evaluate an expression and then convert > the resulting value to finite precision to serve to the user, the only > place the precision parameter was used was for formatting the output. The > calculation itself was independent of the precision parameter. > > Using infinite precision internally is ideal and should always be > preferred. For expressions using only the operations *,/,+,- and only > rational arguments, you can treat the rationals as pairs of ints and just > do integer math, which is infinite precision. >
There are plenty of examples where it's impossible in practice to do this, as algebraic operations cause memory blowup, and unacceptable slowdown. Sage or any other system is not running on an ideal all-powerful computer, there are resource limitations. Are you familiar with computational complexity theory? Before accusing us of making "subtle mistakes", I suggest you to familiarise yourself with it. But for other expressions this isn't possible, eg a non-square integer to > the power 1/2. In that case you have to use some kind of series expansion > evaluated to only finitely many terms, or some kind of iterated map that > converges to the right answer, but you only iterate it a finite number of > times. This is working to only finite precision. In effect you choose an > internal precision, by choosing the number of terms to evaluate in the > expansion, or the number of times to iterate the map. You choose this > internal precision to be *higher* than the user's requested precision, so > that you can round your internal result to the user's requested precision > and it is correct to that precision. > > On Monday, April 17, 2023 at 6:24:13 PM UTC-6 Nils Bruin wrote: > > Fixed precision floating point is fundamentally unable to do this: the > number of real numbers it can represent in the interval [1,2] is bounded > (by the set precision), whereas that interval contains infinitely many > rational, algebraic, and transcendental real numbers. So there are pairs of > numbers in there it won't be able to represent with distinct > representations. > > > For each value of the precision parameter, there are only finitely many > distinct numbers that the environment can output. But taking the union over > all precision parameters, the environment can output infinitely many > numbers - in fact, a dense subset of the rationals, hence a dense subset of > the reals. > > The fact that this set is dense in the reals is the whole basis for using > finite precision strings of digits as arbitrarily good approximations to > arbitrary real numbers! > > Specify enough digits, and you can approximate a real number as closely as > you like. > > Set the precision of your environment high enough, and you can approximate > exact real quantities as closely as you like. > > RealField(200) alone can't do that. > But RealField() can. > > And I think it does, except when I pass it an expression with a float > literal, because in that case you guys change the literal's value to a > 53-bit approximation, and that trashes, for all n>53, the n-bit > approximation that RealField(n) is supposed to give us. > > -aw > > > > > -- > 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/4c3e87b7-1fbc-46b3-aeb1-8770c17d10c2n%40googlegroups.com > <https://groups.google.com/d/msgid/sage-devel/4c3e87b7-1fbc-46b3-aeb1-8770c17d10c2n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAAWYfq1xdNppaUVupKN1d%2Bw66RHq0x6O8G8h2rFL2706bq8h7A%40mail.gmail.com.
