[sympy] Suggestion on Derivative and Expr._diff_wrt

In current SymPy, derivative such as dx/d(x+1) is not allowed. Instead, one might use `Derivative(f(x)-1, f(x)).subs(f(x), x+1)`. Although this is mathematically rigorous, the former expression is sometimes used as well, at least in the field of engineering. Hence I carefully suggest; how

[sympy] Suggestion about Derivative and Expr._diff_wrt

In current SymPy, derivative such as dx/d(x+1) is not allowed. Instead, one might use `Derivative(f(x)-1, f(x)).subs(f(x), x+1)`. Although this is mathematically rigorous, the former expression is sometimes used as well, at least in the field of engineering. Hence I carefully suggest; how

[sympy] Re: Suggestion on Derivative and Expr._diff_wrt

I have tried, and although it was working well, `diff()` method was unaffected since `Expr.diff()` method is connected to `Derivative`. Since this feature will add no backward incompatibility, I think it would be better to modify `Derivative`. 2020년 1월 4일 토요일 오후 7시 8분 39초 UTC+9, Francesco

Re: [sympy] Suggestion on Derivative and Expr._diff_wrt

It's same as df(t)/dt, where t=x+1. 2020년 1월 4일 토요일 오후 8시 6분 55초 UTC+9, David Bailey 님의 말: > > On 04/01/2020 10:08, Francesco Bonazzi wrote: > > It's suggest to subclass Derivative if this feature is needed. > > > I'd like to know what d f(x)/d(x+1) means exactly. It isn't too easy to >

Re: Re: [sympy] Suggestion on Derivative and Expr._diff_wrt

Your suggestion is true. However, using ``Derivative(f(x), x) * 1/Derivative(x+1, x)`` explicitly every time is not very systematic approach. If we know "Hey, df(x)/d(x+1) equals (df(x)/dx)/(d(x+1)/dx)!", then why don't we let SymPy know to automatically deal with this case with same

[sympy] Introduction to SymPy Community

Hello. We are the researchers in Microfluidics and Coating Process Laboratory (MCPL) in Seoul National University, South Korea. We have been developing a package for fluid mechanics for a year, which depends heavily on SymPy. Our expertise is in fluid mechanics and chemical engineering, and

Re: [sympy] Suggestion on Derivative and Expr._diff_wrt

mentioned above. And frankly speaking, it's user's fault if one mistypes the input. 2020년 1월 5일 일요일 오전 2시 22분 8초 UTC+9, David Bailey 님의 말: > > On 04/01/2020 13:08, mcpl snu wrote: > > It's same as df(t)/dt, where t=x+1. > > Thanks, and I suppose that also generalises to expressio

Re: Re: [sympy] Suggestion on Derivative and Expr._diff_wrt

ative and Expr._diff_wrt > > > > On 04/01/2020 13:08, mcpl snu wrote: > > It's same as df(t)/dt, where t=x+1. > > > > Thanks, and I suppose that also generalises to expressions such as > df(x)/d(sin(x))? > > df(t)/dt where t=sin(x) > > Given how

[sympy] Re: Discussion for introducing the hooks to core classes

I think I resolved this. Please refer to PR page . -- 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

Re: [sympy] Discussion for introducing the hooks to core classes

Aaron Meurer, Thanks for your opinion. I will try with that. -- 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

[sympy] Discussion for introducing the hooks to core classes

Discussion for introducing the hooks to core classes This thread is related to issue #5040 and PR #18769 . *1. What is the problem?* Currently, SymPy's Add and Mul are very complicated. There exist

[sympy] Question on using Symbol as instance naming

Currently, many classes in SymPy include Symbol in args to provide the names to their instances. An example for this is sympy.vector.CoordSys3D class. Although this can be a clever way to do it, I think this is wierd - perhaps it's an abuse of using Symbol. As far as I know, SymPy's Symbol is

[sympy] Question on using Symbol as instance naming

Currently, many classes in SymPy includes Symbol in args to provide the names to its each instance. An example for this is sympy.vector.CoordSys3D class. Although this can be a clever way to do it, I think this is wierd - perhaps it's an abuse of using Symbol. As far as I know, SymPy's Symbol

Re: [sympy] Re: Question on using Symbol as instance naming

I agree with SYLee. All we need is just a wrapper of str. I doubt that anyone will need to manipulate with that. SymPy doesn't need to support string manipulation indeed: That's why we don't have to implement those methods. > > -- You received this message because you are subscribed to the

Re: [sympy] Re: Question on using Symbol as instance naming

t; separately, so there were some other use cases. > > > > On Tuesday, May 26, 2020 at 5:34:43 PM UTC+9, mcpl snu wrote: > >> > >> Currently, many classes in SymPy include Symbol in args to provide the > names to their instances. An example for this is sympy.

[sympy] Re: Discussion for introducing the hooks to core classes

I found a typo in my original comment. in line 6, 'preprocessor' shoud be changed to 'postprocessor'. Also, in line 7 I wrote that postprocessor is not applied when evaluate=False is passed, which is wrong. I will write an updated description. > -- You received this message because you are

Re: [sympy] Question on using Symbol as instance naming

aving a hard time finding the discussions. > > Aaron Meurer > > On Tue, May 26, 2020 at 2:34 AM mcpl snu > > wrote: > > > > Currently, many classes in SymPy include Symbol in args to provide the > names to their instances. An example for this is sympy.vector.Coo