I see.
My idea is quite similar with WrapFunction concept which Upabjojr suggested.
In my case, it would be 'Operator' instead of 'WrapFunction'.
The difference is, my plan does not include overriding the namespace, such
as sin=WrapFunction(sin).
Instead, it leaves sin class completely unmodified. However, __add__,
__sub__, ... methods will be added to FunctionClass, which is a metaclass
of sin.
It will be like this:
class FunctionClass(ManagedProperties):
def __add__(cls, other):
return Operator(cls) + Operator(other)
* Operator(cls) + Operator(other) will return
AddedOperator(Operator(cls),Operator(other))
2019년 12월 8일 일요일 오후 8시 35분 52초 UTC+9, Oscar 님의 말:
>
> 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] <javascript:>>
> 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] <javascript:>.
> > 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/8439f6aa-1f64-4a44-a320-b2ee8c1f88e6%40googlegroups.com.
