On Tue, 18 May 2021 at 11:41, Stephen J. Turnbull
<turnbull.stephen...@u.tsukuba.ac.jp> wrote:
>
> 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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4FRRG3RWFTSTLKLUCJGYXE7G4JPWTDJD/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to