On Tue, Jan 17, 2023 at 2:33 AM S.Y. Lee <sylee...@gmail.com> wrote: > Sympy runs on the uni-typed system of Basic, and I previously thought that > it was fallen from sky, and I also seen coworkers in my work following that > practice naively, > But now I concluded that the recursive data structure with only one base > type (like Basic) is incomplete and leads to very awkward solutions. > > Although it is still possible to represent any mathematical objects in > uni-typed system like "Basic" in complete way, but we have no option but to > reinvent alphabets, numerals from the scratch and represent numbers like > Number(One(), Two(), Three(), ...), which gives technically very > inefficient solution eventually. And you would find resemblance of this > with things like Von Neumann numerals or Church numerals, which is only > theoritically interesting. > > So it was always something needed to distinguish Basic with Atom, and had > loose interface about how things are designed in such way. > > But I'm trying to rethink about why things had to be designed in the first > place, because I believe that this is source of controversies about why > sympy objects are too heavy or why sympy objects have very fragile behavior > when subclassed, composed. > > For example, we could allow `args` to be both `Basic` and not `Basic` (we > can split all python universe with some interior and exterior), and could > have defined Bi-Typed structural induction from objects that fall under > `isinstance(..., Basic)` and not. >
The "should args allow non-Basic?" question has come up before. It boils down to the fact that we make heavy use of the object interface in Python. This makes things short to spell, but it means that attributes only exist if the object is the right class. We could have made it so everything is functional, like args(x) instead of x.args. But if you do that, you have to go all in, because no attribute can be guaranteed to exist if objects can be any class. The attributes are a little easier to read, but they do require that the data be wrapped in a common class. > Or there could further be many-typed term system that allows mixing in > different types of int, str, or any other python objects with `Basic` in > correct positional places, or in some places with regular pattern. > I'm trying to have a overview for such type system, because that can serve > for building a very general and lightweight framework of computer algebra > system. > > I'm sure that there are some 'champions' trying to cleaning up the core, > with following the old practices. But for the worst cases, if any attempts > fail for that, we may think of soft archiving the old sympy core and invest > on designing the stuff like matrices, physics from the scratch, from the > abstract syntax tree level. So the conclusion is everyone should design > their own AST if things are extended from SymPy. > > Actually, I think that the introduction of custom functions, matrices as > workarounds for Expr had made things complicated and made sympy fragile of > 'shape errors' because they have broken the consistency of sympy in some > way, as I see issues revolving around them if any attempt is done for > fixing the core. I'm not sure if it has positive progress though. > I hope the kind system can help resolve these sorts of "shape error" things you are talking about. It would be interesting if we could make a static type checker like mypy understand it. I think there's two extremes. The purely structural way of composing expressions, where everything is just a tree and anything can be a child expression of anything. This is sort of analogous to the set theory foundation of mathematics, where everything is "just a set". This is more or less how systems like Mathematica work (as far as I understand) which allow you to make nonsense expressions like Integral(Image). The other extreme is a fully typed system where only things that are specifically allowed in the type system are allowed. This is more akin to the "type theory" foundation of mathematics. I think SymPy operates somewhere in the middle of the two. The nice thing about the type theory approach is that you avoid incorrect "nonsense expressions" that at best are just meaningless and at worst produce TypeErrors or some garbage result. But the downside is that if you want to represent something that can make sense but the type system doesn't know about, you can't do it. SymPy in some ways gets the best of both worlds here and in other ways it gets the worst of both worlds. For instance, you can shove any kind of object into the core classes (like Add, Mul) if you try hard enough, but at the same time, they will fall apart pretty quickly if it's something they don't recognize, and it's pretty hard or even impossible to tell it how to work. Aaron Meurer -- > 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/3c199913-3d70-4966-a862-daf8a65060e4n%40googlegroups.com > <https://groups.google.com/d/msgid/sympy/3c199913-3d70-4966-a862-daf8a65060e4n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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%3D6K59nK5BXY%2BUAWyvnESDGyk%3DZOrssh08BWHr_HT68X%3DZQ%40mail.gmail.com.
