On Tue, 18 May 2021 at 11:41, Stephen J. Turnbull
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
When you want to use Fraction you need to decide explicitly that that is what you are doing because you want arithmetic without rounding errors. You also need to understand that that limits what you can do because e.g. math.sin can not give a rational number for (most) rational input. The same is true of writing code that should work only with integers and the distinction between a // b and a / b: you need a // b to divide ints exactly but you definitely shouldn't use it to divide "integer-valued" floats unless you are very careful because a // b is extremely sensitive to rounding errors. Likewise maybe you want to use real numbers or maybe complex numbers: should you use math.sqrt or cmath.sqrt? Or maybe numpy.sqrt or sympy.sqrt? I see a lot of novices get confused by these things. Some languages like matlab or Julia do a better job of integrating different types so that it feels more seamless to the user. Apart from very basic operations though nothing really obviates the need for the user to have some understanding about whether they are doing exact vs inexact calculations or integer vs float vs fraction vs multiprecision vs symbolics etc.
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.
The error analysis for arithmetic with Fraction is much easier than for float: If you didn't get a ZeroDivisionError then the result is exact and the error is zero.
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.
I think declaring the symbols is fine. It's better to be explicit with these things. You need to be able to do that so that you can say what kind of thing the symbol represents anyway e.g.: x = Symbol('x', positive=True) What I would like though is to eliminate the repetition in something like this: x, t, Ck, Cr, Cl = symbols('x, t, Cr, Ck, Cl') I've seen people write scripts using sympy that declare anything up to a hundred symbols like this at the top. It's very easy for a bug to creep in e.g. because Ck and Cr are the wrong way round and I do see people getting bitten by this: https://github.com/sympy/sympy/issues/21368 The Julia bindings for sympy and also Julia's new Symbolics.jl both have a syms macro so that you can do: julia> using Symbolics julia> @syms x y (x, y) julia> e = (x + y)^2 (x + y)^2 SageMath has something similar but you write var('x, y, z') and sympy has the same but it is discouraged because it uses global-injection which is problematic. Also var puts the variable names in strings which then makes it seem magic that they become variables in scope. The Julia way is nicer because x and y at least look like local variables in the statement. It would be great if Python could have a way of doing this as well. We already have @deco def func(): pass which is a way of avoiding this repetition: def func(): pass func = deco(func) If there was some way to make @syms x, y translate to x, y = syms('x, y') or something like that then that would be great. Maybe that doesn't have broad enough use for Python the language but I would certainly add something like that if I was providing a SymPy UI based on a modified form of Python (e.g. like SageMath). -- Oscar