On 05/07/2023 21:40, Aaron Meurer wrote:
For interactive use, just passing a string to S() (or equivalently
sympify() or parse_expr()) is the simplest way to deal with this.
However, I would avoid this for non-interactive usage (i.e., any code
that gets saved to be executed later). Putting your expression in a
string breaks the ability for Python to parse it directly, meaning
things like simple syntax errors won't be caught until the code gets
run.
You should also be very careful when doing this if you use
assumptions. S("x + 1") will create a symbol x with the default
assumptions. If you already defined x with assumptions, like
x = symbols('x', real=True)
then this will be a *different* symbol. For example:
Thanks for that caution, Aaron,
This whole problem reminds me vaguely of a friend of mine that bought an
early Sinclair calculator. He discovered that ln(2) was seriously
inaccurate, so he wrote to them. They replied that there was nothing
wrong with his calculator, he had just chosen an unfortunate example!
What I'm trying to say is that there must be people out there who gave
given up on SymPy after discovering what it does to 1/2*x, or worse
still, got an error in their work (particularly if using Python 2).
Thinking about it, I can see how hard it is to do something really
effective about this problem, but couldn't you prevail on the Python
term to insert a hook in the Python parser to make it possible to change
an input string before Python parses it and applies its integer division
rule?
David
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/d6b19b21-d61c-e4f8-3116-f5f64ac6ab48%40dbailey.co.uk.
