The best way to avoid this issue is to be hygienic in how you define
Symbols. My recommended best practices would be
- Always define symbols at the top of your file/notebook, or top of
the function if your use of sympy is restricted to a single function.
- Assign symbols to variables. Don't inline Symbol('x') in an
expression, but rather define x = symbols('x') first. Note that you
can define multiple symbols with the same assumptions on a single line
with the symbols() function.
- Always keep the same assumptions for any given symbol name. So for
instance if t = Symbol('t', positive=True) in one place, you should
always make it positive. Which variables will have which assumptions
will depend on your application.
- Name your symbol variables the same as your symbols, or as something
reasonably close if the symbol name isn't a valid variable name.
- Never overwrite a variable name assigned to a symbol. For example,
don't do this
a = Symbol('a')
...
<some stuff>
...
a = 1.1
This makes it impossible to access the symbol 'a' without recreating
it again. Use a different variable name, or consider storing values in
a dictionary, like {a: 1.1} (note that you can pass dictionaries to
subs()).
There's also a confusion I've noticed with this, where people will do
something like this
a, x = symbols('a x', real=True)
a = 1.1
expr = a*x**2
The a = symbols(...) here does nothing, because it is immediately
overwritten by a = 1.1. The fact that this sets 'a' as real is
irrelevant. More correct could would be
x = symbols('x', real=True)
a = 1.1
expr = a*x**2
Or if you wish for 'a' to be symbolic for part of the calculation then
later replaced with a numeric value,
a, x = symbols('a x', real=True)
expr = a*x**2
<symbolic calculations>
evaluated_expr = expr.subs(a, 1.1)
As Oscar noted, SymPy doesn't have a "database" or anything like that.
Symbols are defined as independent objects. On the line 'a = 1.1', the
symbol 'a' is deleted and the variable 'a' is set to 1.1. Creating a
symbol with certain assumptions has no effect on any other object.
SymPy functions are generally speaking, side effect free.
Remember that SymPy objects, including symbols, do not and cannot know
anything about the Python variable names they are assigned to. They
are just objects, and Python variables are names that point to them.
Read https://docs.sympy.org/latest/tutorial/gotchas.html and
https://nedbatchelder.com/text/names.html if you are confused about
this.
Aaron Meurer
On Sun, Apr 11, 2021 at 9:26 AM David Bailey <d...@dbailey.co.uk> wrote:
>
> Dear group,
>
> Recently Bruce Allen discussed a problem that he had after pickling a
> list. However, I think he revealed a deeper problem that is nothing to
> do with pickling.
>
> w=sin(Symbol("x", positive=True))*cos(Symbol("x"))
>
> sin(x)*cos(x)
>
> test=Integral(w,,x)
>
> Integral(sin(x)*cos(x), x)
>
> test.doit()
>
> sin(x)*sin(x)
>
> OK, that was a bit contrived, but it does show how worryingly easy it is
> to generate multiple symbols with the same name in the same Python context.
>
> Clearly when processing the first statement, SymPy inserts x into its
> data base as a symbol with an assumption. After that it creates a
> distinct symbol x without that assumption!
>
> I would have thought it would be kinder to cause an exception in that
> case to prevent the ensuing confusion.
>
> 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/e008170c-fc64-8101-3f03-9f988429c848%40dbailey.co.uk.
--
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/CAKgW%3D6KMgycne8_8i0Wa2hQbmC0%3DQpYDk4YV%2BOe5b2TJdOZcuA%40mail.gmail.com.
