Re: [sympy] Error with inverse_laplace_transform (easy to solve)

May be using `as_int` with the second argument in `RisingFactorial` should solve the problem. Just an idea. With Regards, Gagandeep Singh Github - https://github.com/czgdp1807 LinkedIn - https://www.linkedin.com/in/czgdp1807 On Thu, 7 May, 2020, 2:55 AM Aaron Meurer, wrote: > Here is the error

Re: [sympy] Error with inverse_laplace_transform (easy to solve)

Here is the error >>> inverse_laplace_transform(0.5/(.5*s+1)*1/s, s, t) Traceback (most recent call last): File "./sympy/polys/polyutils.py", line 211, in _parallel_dict_from_expr_if_gens monom[indices[base]] = exp KeyError: RisingFactorial(_t + 1, 2.0) During handling of the above

Re: [sympy] Error with inverse_laplace_transform (easy to solve)

Hi Javier, I'm not sure exactly the problem with the example you showed. I think it's a bug somewhere. It is usually better not to use floats in sympy. With exact rational numbers your example works for me: In [17]: inverse_laplace_transform(S.Half/(S.Half*s+1)*1/s, s, t) Out[17]: -2⋅t

Re: [sympy] Control Systems package

Good to know! Jason moorepants.info +01 530-601-9791 On Wed, May 6, 2020 at 1:20 PM Aaron Meurer wrote: > Regarding galgebra, at first it did languish quite a bit, but now it > has been picked up by several people and is doing well > https://github.com/pygae/galgebra. So I think the main

Re: [sympy] Control Systems package

Regarding galgebra, at first it did languish quite a bit, but now it has been picked up by several people and is doing well https://github.com/pygae/galgebra. So I think the main issue is that for a package to do well on its own, it needs to have a strong community, which is independent of the

Re: [sympy] Control Systems package

Sounds good, I will add it to sympy.physics. Thanks all for your suggestions. On Thu, May 7, 2020, 00:48 Jason Moore wrote: > Gagandeep, > > Thanks for the consideration of my comments. > > Jason > moorepants.info > +01 530-601-9791 > > > On Wed, May 6, 2020 at 12:13 PM Gagandeep Singh

Re: [sympy] Control Systems package

Gagandeep, Thanks for the consideration of my comments. Jason moorepants.info +01 530-601-9791 On Wed, May 6, 2020 at 12:13 PM Gagandeep Singh (B17CS021) < singh...@iitj.ac.in> wrote: > Hi Jason, > > Thanks for presenting points on why sub-packages should be kept in the > main sympy repo.

Re: [sympy] Control Systems package

Hi Jason, Thanks for presenting points on why sub-packages should be kept in the main sympy repo. What I suggested was just an immature approach. Obviously, there will be trade-offs in too much granulation of the codebase. I didn't mean that what I suggested must be done. > It allows the code to

Re: [sympy] Re: Control Systems package

Aaron, The main challenge for the SymPy-PyDy codes is that we have to separate the symbolic and the numerical/visualization codes, with the numerical codes being in the external PyDy repository and that the PyDy tests are not run in the SymPy CI. It would be nice if all the code was together or

Re: [sympy] Control Systems package

Gangandeep, I disagree with your thoughts on this. We've dealt with this over a decade ago with the symbolic pydy package (which started as a separate package). After careful consideration we decided to add this to SymPy and it was the right decision. It allows the code to be tested along with

Re: [sympy] Re: Control Systems package

Thanks for your interest, Javier! I was thinking of adding a basic control systems functionality in SymPy as my project. It includes the following: * Representation of State space and transfer function, symbolic evaluation. * Controllability and Observability. * Inter conversion between two

Re: [sympy] Re: Control Systems package

My suggestion would be to start with it in SymPy, since that will be the easiest. You won't have to deal with setting up any of the boilerplate that is required for a separate repository, like packaging, setting up the testing and CI, and so on. The only concern is if we later want to move it

Re: [sympy] Re: Control Systems package

Naman, I'd have a look at the maxima package. They likely have good and useful ideas for your design. Jason moorepants.info +01 530-601-9791 On Wed, May 6, 2020 at 10:37 AM Javier Arantegui wrote: > Hello, > > it sounds interesting. > > What do you have in mind? Something like COMA < >

Re: [sympy] Control Systems package

Naman, I think we should add it to SymPy in the physics package. Jason moorepants.info +01 530-601-9791 On Wed, May 6, 2020 at 8:43 AM Naman Nimmo wrote: > Hi everyone. > > Since the accepted GSoC projects are out now, and my project - "Control > Theory - Implement a control systems package"

Re: [sympy] Control Systems package

Hi, IMHO, the control systems should go as a separate repository under sympy with the main sympy repository as a dependency. In fact that should have happened with sympy.stats as well, as no other module uses features of stats and the case is other way around but that is a thing for another day.

[sympy] Error with inverse_laplace_transform (easy to solve)

Hello! I'm using Sympy 1.5.1 and Python is 3.7.7. Both installed using Anaconda. I have tried to do an inverse Laplace transform and I got an error: inverse_laplace_transform(0.5/(.5*s+1)*1/s, s, t) The error message is quite long, tell me if you need it. I spent 10 minutes in front of my

[sympy] Re: Control Systems package

Hello, it sounds interesting. What do you have in mind? Something like COMA ? COMA is a control engineering package for Maxima. I have my own script inspired in COMA to do some calculationl. It uses sympy a lot. Honestly it's quite bad,

[sympy] Control Systems package

Hi everyone. Since the accepted GSoC projects are out now, and my project - "Control Theory - Implement a control systems package" was in that list, I would like to first know whether it will be a part of the main sympy project or some other project to go on PyPI? I personally feel It *should*

[sympy] Dropping Login support for SymPy Live and SymPy Gamma

Hi, SymPy Gamma [1] and Live [2] runs on Google App Engine's Python 2 Runtime. We currently have the ability to login in both of these apps via Google App Engine's User's API that comes bundled with Python 2 runtime. [3] Now, since as you all know Python 2 is no longer supported, we need to