Would it be breaking sympy's main design to introduce `sin + cos`?

[JS S]

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?

[Oscar Benjamin]

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

> --
> 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+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/b26e04b9-d137-48ca-b40a-a9b7fdec645d%40googlegroups.com.

[JS S]

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 님의 말:

> To unsubscribe from this group and stop receiving emails from it, send an email to sy...@googlegroups.com.

[Oscar Benjamin]

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.

> To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/f11e98e9-78eb-4289-9b8f-84efe23f3b01%40googlegroups.com.

[JS S]

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 님의 말:

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/f11e98e9-78eb-4289-9b8f-84efe23f3b01%40googlegroups.com.

[Aaron Meurer]

This is the relevant issue for this https://github.com/sympy/sympy/issues/4787.

Aaron Meurer

> To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/8439f6aa-1f64-4a44-a320-b2ee8c1f88e6%40googlegroups.com.

[Jisoo Song]

A PR related to this post is made.

https://github.com/sympy/sympy/pull/18320