Christopher Barker writes: > Python assumes, and converts to, floats all over the place. So users need > to understand and accommodate the limitations of floats anyway. Having > exact fractions in seemingly arbitrary places will not result in more > accurate (or precise) results in most cases, but would result in more > confusion
I don't see how that's a big deal. It's not arbitrary, and it happens only in one kind of context, which has to be explicit in the program (with the exception of eval, I guess?) I don't think it should be hard to learn that this applies only to parsing literal fractions, not to integer division in general. That it doesn't apply to integer division other than literals is certainly an inconsistency, but not that great. The main problem creating confusion would be in cases where Fractions propagate, taking unexpected amounts of time and space in an extended calculation. I don't think we have a good idea how to analyze how often it would happen, and how much pain it would cause. But I can easily see it happening in evaluating power series and that kind of thing. It seems far less likely, although I suppose possible, in statistical (which are going to use something like numpy) or financial computations (where fractional constants are normal expressed with decimal notation or integer percentages, not fraction literals). > and more difficult error analysis. I don't understand what you mean by "error analysis", unless you're referring to performance degradation due to Fraction propagation. Aside: I think the real weakness of the proposal is that what symbolic math "really" wants is for algebraic expressions to be returned to the program as syntax trees. The current situation where symbolic math libraries for Python create Symbol objects with full suites of arithmetic dunders that create expression trees instead of doing arithmetic is clunky, but it's almost good enough. What would be a much bigger win for me would be a package where I don't have to declare Symbols in advance, and that's exactly where the "stop at syntax trees please" mode would come in. Regards, _______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/BEISVB2IJAYXQ4AT2EO5B4PA5YFJEMAZ/ Code of Conduct: http://python.org/psf/codeofconduct/
