On Mon, Apr 17, 2023 at 7:39 PM aw <aw.phone.00...@gmail.com> wrote:
> 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. > It's certainly not no cost. Here are several problems with this proposal: * If you simply interpret float literals as rationals, they will print as rationals. I would find this extremely surprising and annoying; it makes Sage more difficult to use as a basic calculator (I use Sage for my taxes for example). * Something that Nils has alluded to a bit is performance. The above issue could be resolved with some work by making a new kind of real field parent that stored elements internally as rational numbers (at least until you applied a transcendental function) but printed as decimals. But it would then be susceptible to coefficient blowup, which can make some computations with rationals (especially in linear algebra) drastically slower than computations with floating point values. Hiding the fact that real literals are implemented as rationals means that even people who are aware of such issues wouldn't be expecting. And you still face similar problems as soon as you apply a transcendental function, unless you go fully over to the symbolic ring. So I think a concrete version of Dima's suggestion would be 1. Implement a new field that stores elements internally as rationals, printing as decimals to some precision (you could get a higher precision by casting explicitly to RealField(prec), or by using .n(prec)). 2. Real literals would land in this field, which would have coercion maps from Z and Q so arithmetic would be exact under the hood. 3. Coercion would go to the symbolic ring, so e^1.1 would live in the symbolic ring (rather than RealField(53) where it lives now). For lack of annoyance it should probably still print as a 53-bit decimal, but you could cast it to RealField(200) and it would give the correct result. I guess other transcendental functions (log, trig) would also land in the symbolics. 4. Live with the performance implications. As Dima says, you can use RDF if you want fast floating point arithmetic. But it's already the case that the symbolic ring is a performance trap for unwary users, and I'm not sure it's a good idea encouraging more use of it implicitly. This is a nontrivial project, though not unreasonable. I'm certainly not going to do it. aw, if there was general agreement on an approach like this (I'm not sure if I think it's a good idea or not, but I could be convinced) would you be interested in implementing it? David > > -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 > <https://groups.google.com/d/msgid/sage-devel/a2e8c4ba-5a73-44a4-992b-449e6d24b479n%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/CAChs6_mfZGOp-SgH0XRqzFKzZRL0W5_BqQGyK4-Tj0wKx%3D1bRA%40mail.gmail.com.
