On Saturday, 15 April 2023 at 14:39:40 UTC-7 aw wrote: Here's one:
RealField(200)(2*1.1) 2.2000000000000001776356839400250464677810668945312500000000 Let's check the types: type(2) <class 'sage.rings.integer.Integer'> type(1.1) <class 'sage.rings.real_mpfr.RealLiteral'> type(2*1.1) <class 'sage.rings.real_mpfr.RealNumber'> The type on that last result gives you a hint that something has changed by multiplying by 2: sage: parent(2*1.1) Real Field with 53 bits of precision As you saw, "1.1" lead to a "real literal". Doing arithmetic with it will result in something that's not a literal anymore (the literal is mainly there so that "RealField(100)(1.1)" does what you'd expect). It has to choose a default precision which, without further information, is taken to be 53 bits (because that agrees with Python's float and the IEEE standard for "double" floats). Since the literal (but not the real number that results from multiplying by 2) does remember the string it was created from, you can actually imply different precision: sage: parent(2*1.1000000000000000000000000000000) Real Field with 107 bits of precision The representation is still not exactly 11/5, because that number does not admit an exact representation in binary floating point, for any precision, but it will result in a binary floating point that lies closer to 11/5. 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 . The usual reason for preferring floats is either because you're interested in doing computations that lead to transcendental numbers (which are problematic to compute with exactly) or because you want to avoid the explosion-of-digits that arises from exact arithmetic. Compare: sage: %time a=factorial(10000000) CPU times: user 2.22 s, sys: 41 ms, total: 2.26 s Wall time: 2.27 s sage: %time b=factorial(10000000.0) CPU times: user 396 µs, sys: 0 ns, total: 396 µs Wall time: 414 µs As you can see, the results coming from sagemath may not meet *your* expectations, but the design decisions leading to the behaviour are actually quite well-motivated. It's entirely possible the design can be refined and improved even further, but you didn't make a convincing case that your examples would lead to such an improvement. -- 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/37d4852e-e837-48be-9b54-f3f321ce99c8n%40googlegroups.com.
