On Mon, Apr 17, 2023 at 10:12 PM aw <aw.phone.00...@gmail.com> wrote: > > To the folks defending RealField's behavior: the reasons you cite for why > it's acceptable would also apply to low-precision environments like single or > double precision. > > But very high precision environments have a different purpose than those > low-precision environments. So you shouldn't be thinking about them in the > same way as low-precision environments. > > In this post I'm going to highlight two critical things that are specific to > very high precision environments, which I think are getting overlooked. I'll > label them A and B. > > (A), exact vs inexact: > > The purpose of a very high precision environment like RealField(200) is to > compute with exact quantities - some combination of ints, rationals, exact > rationals like sqrt(2), or exact transcendentals like pi. > > It would be nuts to pass RealField(200) an inexact quantity x that is > knowable only to a much smaller number of bits, for example 23 bits, because > you can never get more than 23 good bits from any expression involving x. > There's no point in asking for anything more than 23, so it would be crazy > and wrong to ask for 200. > > In other words, when used correctly, very high precision environments like > RealField(200) are for computing exact quantities, not approximate floating > point quantities. > > They are for exact computation, not inexact computation. > > The answer they give is the exact answer truncated to a finite precision that > we specify. > > This is completely different from an inexact computation limited to a finite > precision by the inexactness of its inputs. > > I think you guys may have failed to appreciate this fundamental distinction, > and that's what led you to mishandle float literals in RealField's input. > > You guys were thinking, RealField is for inexact floating point, so we should > treat the float literal as an inexact floating point quantity. What you > should have been thinking is, RealField is for exact values that we will > truncate at the end, so we should treat the float literal as an exact > rational. > > By the way, if you want some corroboration for my claim that very high > precision environments are for exact computation, just look at how they are > implemented. > > The implementation of a very high precision environment will use integers > *only*, so that the calculation can be exact. This says the environment is > intended for doing exact computation with exact quantities.
Hardware floats are no less exact than hardware integers. Arithmetic on hardware integers suffers from the same inevitable loss of precision or overflow, and in fact nowadays computations with integer data is in some cases done with hardware floats - they are often much faster, as they have parallel hardware capabilities. > > Contrast that with the implementation of a lower precision environment like > single or double precision: this will use machine floats, because the > calculation doesn't need to be exact. These environments are intended for > doing inexact compution with inexact quantities. > > > (B), required behavior: > > I'm gonna get math-y for this one. > > Let X be a high precision environment. > We can see X as a function which takes an input expression S along with a > parameter P specifying the desired precision for the output. It produces an > output value V, with that precision. > > I claim that for X to be working correctly, the input-output pairs (S,V) must > satisfy the following condition: > > V = exact value of S truncated to precision P > > An easy corollary of this is the following: > > V is independent of the internal representation used by X > > Another way to put that is, the internal representation used by X should > never be visible in X's output. > > This is required behavior. Implementations are not allowed to deviate from > this. Any deviation is a mistake. > > > Ok, that was two critical things, (A) and (B), about very high precision > environments. > > Now let's re-visit the 2*1.1 example: > > RealField(200)(2*1.1) > 2.2000000000000001776356839400250464677810668945312500000000 > > There are two separate problems with this, corresponding to (A) and (B): > > (1) the literal 1.1 is not treated as the exact rational 11/10 > (2) the values of the junk digits in the middle of the output depend on the > internal representation > > This says there are at least two separate problems in RealField, as a very > high precision environment: > > (1') RealField can mishandle float literals passed to it > (2') RealField can wrongly allow its implementation details to get into its > output > > RealField's behavior doesn't meet the requirements for a very high precision > environment. > > I'm scratching my head trying to understand why you guys are defending > RealField's behavior, instead of wanting to fix it. you cannot get the behavior you want with eager evaluation, full stop. > > Here's a question that might help: what kind of user would look at the output > of RealField(200)(2*1.1) and say, "Yeah, that's awesome, that's exactly what > I was looking for! Thanks, Sage!" > > Describe the kind of user who would say that. > > And then ask yourself, what percentage of Sage users are like that? > > How about this: what percentage of beginner or student Sage users are like > that? > > -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/be6cf0f0-cd47-43dc-816a-987a93759d5bn%40googlegroups.com. -- 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/CAAWYfq0AXNC3NZc583aSj%2Bm%3DFGu5BZQwjbx3EEOhU2be6EJHGg%40mail.gmail.com.
