There might be others but I was thinking of this PR: https://github.com/sympy/sympy/pull/13872
The idea there is that functions like sin should become first-class symbolic objects. Then sin(x) would create an object that represents calling the function sin with the argument x like Call(sin, x). Then undefined functions can be more like symbols. On Sun, 8 Dec 2019 at 03:36, JS S <[email protected]> wrote: > > Can you link me to any discussions related to first-class symbolic functions? > I want to know what have been tried and why they have failed, but I couldn't > find it. > > 'D(sin) -> cos' seems good. It will be worth implementing. > > > > 2019년 12월 8일 일요일 오전 1시 54분 44초 UTC+9, Oscar 님의 말: >> >> I would like to make it so that functions like `sin` are first-class >> symbolic objects, subclassing from Basic. There has been an abandoned >> attempt to do that in the past. If we had that then we could have a >> symbolic differentiation operator. >> >> I don't think I'd want normal SymPy functions to support things like >> `sin + cos` but composition, symbolic inverse, differentiation etc >> should work. I think we need functions to be first class objects in >> order to have a differentiation operator so we can represent things >> like f'(0) without using Subs as D(f)(0). >> >> I'm not sure what sort of differential operators we would want though. >> You've proposed something like d/dx which differentiates with respect >> to x. Actually one of the most useful possibilities that we could get >> from a differential operator would be the possibility to differentiate >> functions directly without needing any reference to an unnecessary >> symbol as in `D(sin) -> cos`. In the context of multivariable >> functions and partial differentiation maybe that would be something >> like `D[2](atan2)`... >> >> -- >> Oscar >> >> On Fri, 6 Dec 2019 at 09:37, JS S <[email protected]> wrote: >> > >> > In the top docstring of core/function, such behavior is proposed. >> > I also found it mentioned in https://github.com/sympy/sympy/issues/5105, >> > which was open 10 years ago... >> > I know that using `rcall` on `Lambda(x,sin(x))+Lambda(x,cos(x))` will do >> > it, but it seems a bit verbose. >> > >> > I am currently developing modules for fluid mechanics, which are purely >> > dependent on sympy. (Hopefully, I want to contribute it to sympy after I'm >> > finished) >> > In this module, what I plan to is to make 'Operator' class, which is a >> > subclass of Expr. >> > It will have callable sympy class (not instance) as argument. >> > Also, classes such as 'OperAdd' and 'OperMul' will be introduced. >> > >> > For example, it will behave like this: >> > >> > ``` >> > >>> Operator(sin)(x) >> > sin(x) >> > >> > >>> Operator(sin)+Operator(cos) >> > OperAdd(Operator(sin), Operator(cos)) >> > >> > >>> Operator(sin) + cos # This will convert cos to Operator(cos) >> > OperAdd(Operator(sin), Operator(cos)) >> > >> > >>> OperAdd(Operator(sin), Operator(cos))(x) >> > sin(x) + cos(x) >> > >> > >>> 2*Operator(sin) >> > OperMul(2,Operator(sin)) >> > >> > >>> OperMul(2,Operator(sin))(x) >> > 2*sin(x) >> > >> > >>> Operator(sin)(cos) >> > OperComposite(sin, cos) >> > >> > >>> OperComposite(sin, cos)(x) >> > sin(cos(x)) >> > ``` >> > >> > Perhaps, it may also have not-callable Expr instance as argument. >> > ``` >> > >>> Operator(1+x)(y) >> > y + x*y >> > ``` >> > >> > >> > Also, I am planning to make differential operator class, named DiffOp, >> > which is a subclass of Operator. >> > Instead of sympy class, it will have variables which will differentiate >> > the expression. >> > DiffOp(x) will represent d/dx. >> > >> > ``` >> > >>> DiffOp(x)(sin(x)) >> > cos(x) >> > >> > >>> DiffOp(x)(DiffOp(y)) >> > DiffOp(x,y) >> > >> > >>> DiffOp(x) + Operator(sin) + x >> > OperAdd(DiffOp(x), Operator(sin), Operator(x)) >> > >> > >>> (DiffOp(x) + Operator(sin) + x)(x) >> > 1 + sin(x) + x**2 >> > ``` >> > >> > How is it? Will it be OK? >> > >> > -- >> > 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 [email protected]. >> > To view this discussion on the web visit >> > https://groups.google.com/d/msgid/sympy/b26e04b9-d137-48ca-b40a-a9b7fdec645d%40googlegroups.com. > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/f11e98e9-78eb-4289-9b8f-84efe23f3b01%40googlegroups.com. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxQdg_C%2Bkh%3DguR6DKLRNBM8ZcjqFFr6gEZXGYhRNZa-GJg%40mail.gmail.com.
