On Monday, 17 April 2023 at 20:44:36 UTC-7 David Roe wrote:
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. We don't need to implement something new for this. AlgebraicField() does this for algebraic (and hence rational) numbers and RealLazyField tries to do this for a reasonable class of computable real numbers. AlgebraicRealField is not a reasonable field to use for a default "real field" because it misses common transcendental elements. But RealLazyField might be. I'm not so sure floating point literals should land in it, though, because to me writing a number as a decimal fraction implies it is meant as an imprecise quantity (and the number of digits written is an indication of how many significant digits it has). I'm pretty sure I'm not alone in that expectation, so there is going to be a subset of users who would be upset that their floats end up not being floats any more. I don't think there are interesting elements in RealLazyField that could be easily constructed from a decimal fraction that can't easily be constructed in a different way and a lot of basic elements (like 1/3) cannot be constructed via decimal fractions, so I don't think using decimal fraction literals for RealLazyField elements makes sense. You'd teach people antipatterns that will paint them in a corner fairly soon. It's certainly reasonable to not call a floating point field "RealField". C and python don't even do that: they call such elements floats. I'm less sure whether such a RealFloats field should be any less prominent than it is now. Plus the whole renaming transition would be super painful. -- 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/416a3fc5-5875-4c4a-84a2-4d622be9e4d0n%40googlegroups.com.
