On Mon, Apr 17, 2023 at 3:47 AM aw <aw.phone.00...@gmail.com> wrote: > > On Saturday, April 15, 2023 at 9:12:09 PM UTC-6 Nils Bruin wrote: > > The design decision here to let the multiplication of a "RealLiteral" by a > sage integer result in a "RealNumber" is because your use of RealLiteral was > taken to signal intent to use floats over exact types. If you wanted exact > results you could have used 2*11/10 . > > > Even in an expression using floats, when a user types "1.1", they intend that > to mean 11/10, exactly. They don't expect it to get changed to a different > number, as RealField does. > > Here's what users expect when they type an expression into a higher-precision > environment: they expect the answer to be the exact answer, truncated to the > precision of that environment. Period. This is not negotiable. There is no > latitude for the software to deviate from that.
No. A floating point environment is always fragile, due to accumulation of rounding errors. If you want to make sure you have control over error propagation, you need ball arithmetic (RBF, RealBallField, in Sage), or interval arithmetic (RIF in Sage). > > When I type 2*1.1 into an environment with a precision of 200 bits, I expect > the answer to be the exact answer truncated to 200 bits, or about 59 digits. How about 1.999999999999999999999999....99 ? Would you also fall off your high horse in surprise? > > Here's what Sage gives me: > > RealField(200)(2*1.1) > 2.2000000000000001776356839400250464677810668945312500000000 > > How the heck can you defend that? Look at that junk! that's what a system which does eager evaluation (e.g. Sage/Python) will give you - assuming you accept that 2*1.1 is a floating point number. At the point when 2*1.1 is computed, it does not know you want precision higher than the default. If you want to delay evaluation of 2*1.1, you better use a compiler, not an interpreter, or an interpreter with lazy evaluation (note that both of these options are slower to run, and harder to implement). Indeed, a compiler would be able to see the precision needed here; lazy evaluation would start with "RealField(200)(...)" and (hopefully) propagate the precision to the argument, "2*1.1". > > This violates some of the most basic expectations of users. No user expects > junk like that to be in their answer. > > RealField is doing something completely unanticipated here, and worse, is > doing it silently: it silently interprets "1.1" as the nearest 53-bit binary > rational, which is not 1.1 but some other value. Hence the result is not 2.2, > but some other value, a value with junk in it. > > Users should never be handed junk. > And defaults should always be what most users expect (especially when it's > 99%+ of users, as it is in the case). > > -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/907a5fe5-8ee1-49b0-a9a1-13d5b84f3145n%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/CAAWYfq35m6%2BPRS081Z-DdJzx17-1zeDiSy8Wr3qOA-X_WgMafA%40mail.gmail.com.
