On Monday, April 17, 2023 at 4:05:56 PM UTC-6 Nils Bruin wrote: But you WON'T be computing with exact quantities in RealField(200) unless your number can be expressed as +- an unsigned 200-bit integer times a power of two, so you're very fundamentally using the wrong tool if you're interested in exact computation.
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. That is the behavior that a very high precision environment is required to have. For input expressions that don't have float literals in them, it looks like RealField does have the required behavior! Example: RealField(200)(sqrt(2)) 1.4142135623730950488016887242096980785696718753769480731767 actual digits, from https://apod.nasa.gov/htmltest/gifcity/sqrt2.1mil: 1.41421356237309504880168872420969807856967187537694807317667... RealField here gives the exact value of sqrt(2) rounded to 59 digits, which is 196 bits. 196 bits is slightly under the requested 200, but let's no get sidetracked by that here. By the way, when I say "truncated", I mean any acceptable truncation method. Rounding is one such method. The main point is that based on this and other similar examples involving algebraic irrationals or transcendentals like e and pi, RealField looks like it is trying hard to be a good high precision environment. But for some input expressions, it fails to have the required behavior. It gives an output that is not any kind of truncation of the exact value. Here's a question: if in pre-processing we interpret all float literals as rationals, as Dima Pasechnik suggested could be an option in an earlier post, do these failures all disappear? Does RealField then fully meet the behavior requirements for a very high precision environment? If that one tiny change would make it a good environment, whose answers are always the exact answers truncated to the requested precision, then why the heck would you not make that change? It would give you something more useful than you have now, at no cost. -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/a2e8c4ba-5a73-44a4-992b-449e6d24b479n%40googlegroups.com.
