On Mon, 12 Apr 2021 at 12:03, 'Bruce Allen' via sympy
<sympy@googlegroups.com> wrote:
>
> Hi David,
>
> > However, my feeling is that some proportion of SymPy users will work
> > interactively - in one scope - without defining any Python functions. So
> > they might calculate a polynomial without regard to any assumptions, and
> > then wish to apply an assumption for one specific calculation and hit
> > the problem you encountered.
>
> Agreed.
>
> >> On the
> >> other hand, there must be a notion of the scope of a declaration.
>
<snip>
>
> > I would have thought that it would not be hard for the SymPy developers
> > to provide a switch that could fault the situation where a symbol is
> > redefined with the same name but different assumptions. I fully accept
> > that this would be mostly useful for interactive work.
>
> IMO it would be good to flag ANY instance of a symbol redefinition that
> creates a different object than the original one. But if I understood
> Oscar's reply to your message, this could add a lot of overhead. I
> suppose there a function which is called each time a new Symbol is
> instantiated. If that's only called for code that looks like
>
> x = Symbol('x', ...)
>
> then I would not expect a big overhead. But Oscar's reply suggests that
> it could be called much more frequently.
It wouldn't be hard to make any new definition of a Symbol with the
same name as a previously created symbol raise an error but it would
break the assumption that it is okay to define a symbol that is only
used local to some context and that assumption is depended on by many
users and downstream libraries and is also used internally by sympy
itself.
I just checked with grep and there are hundreds of lines in sympy's
internal code using either Symbol or symbols to define some symbol.
That's an underestimate because there are other functions that can
create symbols as well. I expect that without some changes it wouldn't
even be possible to import sympy if an error was raised any time two
symbols have the same name.
It would also mean that if you import the sympy.abc module then that
would conflict with defining any single letter symbol name and giving
it any assumptions e.g.:
from sympy import Symbol
from sympy.abc import x
y = Symbol('y', real=True) # This would raise because abc already
defined Symbol('y')
What I said about the overhead is that when creating an expression like
x = Symbol('x')
x2 = Symbol('x', positive=True)
expr = x*x2
it would be possible to check here that expr contains two different
symbols having the same name. However that would need to be checked in
the evaluation of x*x2 and then also in the evaluation of cos(x) +
3*sin(x2) etc. We would need to walk the expression tree looking for
symbols with the same name every time any operation constructs a new
expression which would be too expensive.
> > I feel that gotchas of this sort could cause some real disaster because
> > it might be burried in a mass of algebra, and not be noticed before
> > papers or theses had been written.
>
> Certainly the behavior surprised me, and it means that some of the sympy
> code I have written in the past month is wrong. Even though it appears
> to work correctly, that's accidental, not by design.
I think that the root of the surprise here is the fact that it
sometimes works. Actually it is better to never depend on independent
calls to Symbol giving interchangeable results regardless of the names
of the symbols. All symbols in your calculation should just be defined
in one place and then if you need to use them somewhere else (e.g. in
a function) then you should pass them through.
Of course pickle does need to depend on this and so we need to fix the
pickling code to do this correctly. I sent a pull request here that
fixes the original issue that Bruce had although it disables pickling
with older versions of the pickle protocol:
https://github.com/sympy/sympy/pull/21260
Oscar
--
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/CAHVvXxRKM9SxQLKmN4Yy8tqmmWC7Wdy2mie_kEFHAK-N6bdeRg%40mail.gmail.com.
