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.