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. 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. Here's what Sage gives me: RealField(200)(2*1.1) 2.2000000000000001776356839400250464677810668945312500000000 How the heck can you defend that? Look at that junk! 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.
