Re: [sympy] GSOC 24 Proposal - Classical Mechanics: Efficient Equations of Motion Generation

[Jason Moore]

Hi Maria,

Ok. I just saw this email which seemed late. If you applied, you will be
fully considered.

Jason
moorepants.info
+01 530-601-9791


On Wed, Apr 24, 2024 at 1:27 PM Марія Гартованець <
marisagartovan...@gmail.com> wrote:

> Dear Jason,
> I am so grateful for your reply!
>
> Yes, I know.
> I've already submmited my proposal for this idea, when It was available
> and opened for applications.
> I have a barchelor's degree , and also go on as a student of Applied Math
> and Informatics in the Ivan Franko National University of Lviv , Ukraine
> to get master's degree.
> I have a plenty of knowlege of Python, Machine learning, different libs to
> use in Python, also i have been working with DB for a long time.
>
> So, I hope I'll have an opportunity of beging part of your team.
>
> All the best,
> Maria
> середу, 24 квітня 2024 р. о 08:29:53 UTC+3 moore...@gmail.com пише:
>
>> Dear Maria,
>>
>> The submission period for applications is unfortunately already over.
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791 <(530)%20601-9791>
>>
>>
>> On Tue, Apr 23, 2024 at 9:25 PM Марія Гартованець 
>> wrote:
>>
>>>
>>> *Dear community of Sympy,*
>>> I am interested into this *idea: Classical Mechanics: Efficient
>>> Equations of Motion Generation.*
>>>
>>> That is why I am writing t you. I want to have more information of that
>>> project to analyze a behavior of Kane's and Lagrange's methods. It will
>>> help me to   optimize algorithms and codebase enhancements into the SymPy
>>> Mechanics packages.
>>>
>>> Also I will be very thankful for sending me a code with the
>>> implementation of   Kane's and Lagrange's methods. It will help me to get
>>> familiar with the code and i will do my best to achieve my aim.
>>>
>>> Looking forward to hearing from you!
>>>
>>> *All the best,Maria*
>>>
>>>
>>> --
>>> 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/63e9346f-cf68-496d-8a28-51b3768fea05n%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 sympy+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/f41b18b7-e59c-4ae9-b4bd-54de3a957ca1n%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AjKJY1wpLuJGN-ebcgn-XCsT7wVS4FGm%3DqOQ-NC%3D6NzTw%40mail.gmail.com.

Re: [sympy] GSOC 24 Proposal - Classical Mechanics: Efficient Equations of Motion Generation

[Jason Moore]

Dear Maria,

The submission period for applications is unfortunately already over.

Jason
moorepants.info
+01 530-601-9791


On Tue, Apr 23, 2024 at 9:25 PM Марія Гартованець <
marisagartovan...@gmail.com> wrote:

>
> *Dear community of Sympy,*
> I am interested into this *idea: Classical Mechanics: Efficient Equations
> of Motion Generation.*
>
> That is why I am writing t you. I want to have more information of that
> project to analyze a behavior of Kane's and Lagrange's methods. It will
> help me to   optimize algorithms and codebase enhancements into the SymPy
> Mechanics packages.
>
> Also I will be very thankful for sending me a code with the implementation
> of   Kane's and Lagrange's methods. It will help me to get familiar with
> the code and i will do my best to achieve my aim.
>
> Looking forward to hearing from you!
>
> *All the best,Maria*
>
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/63e9346f-cf68-496d-8a28-51b3768fea05n%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Aj360MwNvhiRs0W5fh44tywT%2BGA5MY9-1WFqiadAWi98A%40mail.gmail.com.

Re: [sympy] Inquiry About GSoC Parsing Project

[Jason Moore]

Hi Assem,

Sam and myself are unlikely to mentor a project on parsers, as we don't
have much familiarity with that.

Jason
moorepants.info
+01 530-601-9791


On Mon, Apr 1, 2024 at 2:48 PM Aquazod  wrote:

> Hello,
> My name is Assem Ali and I'm currently working on my proposal for the
> Parsing project.
>
> First of all, I know that I'm really late but I had a job and I needed to
> quit it to find time to work on the proposal and I couldn't quit it before
> the 26th of this month.
>
> The Parsing project caught my interest and I read about the work that was
> done at GSoC 2019 regarding the C & Fortran parsers. Here
> <https://github.com/sympy/sympy/wiki/GSoC-2019-Report-Nikhil-Maan:-Creating-a-C-and-Fortran-parser-for-SymPy>
>
> My question is, what is the best plan to follow? should I propose to
> implement parsers for Julia and Octave, or propose to improve the current C
> & Fortran parsers?
>
> My original plan was to create Julia & Octave parsers, and then work on
> optimizing the C parser in case there is time left or in case the deadline
> will be expanded. I picked the C parser specifically because it had the
> lowest test coverage rate.
>
> My other question is if it will be so late to post my proposal here at 1st
> April.
>
> Can potential mentors Jason Moore or Sam Brockie reply to me please.
>
> Thank you in advance!
>
> Kind Regards.
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/3709d308-3834-4450-8881-fdcce5a6db18n%40googlegroups.com
> <https://groups.google.com/d/msgid/sympy/3709d308-3834-4450-8881-fdcce5a6db18n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Ahd6JxK78GkuDPqDxJL%2B_N4%2BAYKgoQDz_7Ss-yF5915rA%40mail.gmail.com.

Re: [sympy] Re: GSOC: Benchmark Project Questions

[Jason Moore]

This is my opinion, not sure if it is shared, but I don't think anyone uses
the information that is displayed on the pull request. This isn't because
the information isn't accurate or informative, but because of how and when
it is presented. I haven't looked at all pull requests, of course, but I
don't recall one where someone noticed the slowdown and it led to change in
the PR. It has probably happened, but it happens rarely.

The current system shows two things: timing differences in the current
commit vs last release and current commit vs master. The current commit vs
last release is most helpful for making the new release, but can be
confusing for the PR because it contains slowdowns/speedups from more than
your own PR work. The current commit vs master should show the PR author
that they have made some good or bad change wrt to the benchmarks. That's
all we really need to tell them (besides which benchmarks are slower and by
how much). It does this, but it is easy to just not read it.

The old way was that some of us monitored the asv generated websites and
then opened issues about slowdowns and commented on the old PRs. This isn't
automated but it did lead to specific comments on PRs that PR authors then
were very aware of.

Jason
moorepants.info
+01 530-601-9791


On Mon, Apr 1, 2024 at 2:57 AM Sam Lubelsky  wrote:

> Is there any specific problems with the current pull request benchmarking
> system that this project should address?
> On Sunday, March 31, 2024 at 1:41:58 PM UTC-5 moore...@gmail.com wrote:
>
>> HI Sam,
>>
>> I think that idea could be a bit outdated. I'm not sure if the text was
>> updated for this year. If it was, then someone else can speak up about it.
>>
>> I think that improving our sympy_benchmarks repository with more and
>> better benchmarks and making the benchmarking system that we have setup
>> with each pull request to sympy more useful is a better focus. I'm not sure
>> we can run the benchmarks on a dedicated machine unless we spend some sympy
>> funds to do that.
>>
>> We basically want to know if a pull request slows down sympy and make
>> sure the pull request authors are warned about this in a clear way before
>> merging. In the past it was helpful to see the historical speed of various
>> SymPy benchmarks (here is an example I used to maintain:
>> https://www.moorepants.info/misc/sympy-asv/) but that does require a
>> dedicated machine so that benchmarks are comparable over time.
>>
>> Another thing I thought would be useful in the past, is to run benchmarks
>> as part of the release process (or just before) so we can see if the
>> upcoming release is slower than the prior release.
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791 <(530)%20601-9791>
>>
>>
>> On Sun, Mar 31, 2024 at 8:13 PM Sam Lubelsky  wrote:
>>
>>> Sorry if it is kinda intimidating that I put so many questions.  I
>>> really just need the answer to the first one to make my proposal.  I know I
>>> am a little late to GSOC, but I've really enjoyed getting to know the Sympy
>>> community a little bit in this past week and I am committed to putting
>>> together a good project proposal.
>>> Thanks,
>>> Sam.
>>> On Friday, March 29, 2024 at 4:37:55 PM UTC-5 Sam Lubelsky wrote:
>>>
 I put an introduction a few emails down, but to recap my name is Sam,
 I'm a college freshman, and I'm very interested in working on improving
 Sympy's benchmarking services over this summer through GSOC.

 While going through the project description I had a few questions:

 1) *"It also needs an automated system to run them"*
 What exactly is meant by this.  Right now, github actions seems to be
 already automatically running benchmarking after each pr.  Why is this not
 an automated system?  Is the meaning of automated system something that
 runs weekly/monthly on the whole repo, generates a benchmark report and
 sends it* somewhere?*

 2) *How to go about hosting benchmarks on a remote, dedicated machine?*
 What's the general idea of how to go about this in open source project.  Is
 there money available to pay some cloud provider to host it?  Free hosting
 options?(doesn't seem reliable enough for benchmarking).

 3) *SymEngine vs SymPy.  *I'm not familiar with SymEngine.
 Approximately how similar are SymPy and SymEngine?  Is making the project
 also work with SymEngine more of a quick fix(≈1-2 weeks) or should I expect
 it to take longer?

 4) *Current Benchmark Suite*
 *"We currently have a benchmarking suite and run the benchmarks on
 GitHub Actions, but this is limited and is often buggy"*

 What are the limitation(s) to github actions that this project should
 address?
 If we don't use github actions, is there another way to make it run
 after every PR like we have now?

 5) *Where are the tests run now?*
 On the project description it says " the results are run and hosted Ad

Re: [sympy] Re: GSOC: Benchmark Project Questions

[Jason Moore]

HI Sam,

I think that idea could be a bit outdated. I'm not sure if the text was
updated for this year. If it was, then someone else can speak up about it.

I think that improving our sympy_benchmarks repository with more and better
benchmarks and making the benchmarking system that we have setup with each
pull request to sympy more useful is a better focus. I'm not sure we can
run the benchmarks on a dedicated machine unless we spend some sympy funds
to do that.

We basically want to know if a pull request slows down sympy and make sure
the pull request authors are warned about this in a clear way before
merging. In the past it was helpful to see the historical speed of various
SymPy benchmarks (here is an example I used to maintain:
https://www.moorepants.info/misc/sympy-asv/) but that does require a
dedicated machine so that benchmarks are comparable over time.

Another thing I thought would be useful in the past, is to run benchmarks
as part of the release process (or just before) so we can see if the
upcoming release is slower than the prior release.

Jason
moorepants.info
+01 530-601-9791


On Sun, Mar 31, 2024 at 8:13 PM Sam Lubelsky  wrote:

> Sorry if it is kinda intimidating that I put so many questions.  I really
> just need the answer to the first one to make my proposal.  I know I am a
> little late to GSOC, but I've really enjoyed getting to know the Sympy
> community a little bit in this past week and I am committed to putting
> together a good project proposal.
> Thanks,
> Sam.
> On Friday, March 29, 2024 at 4:37:55 PM UTC-5 Sam Lubelsky wrote:
>
>> I put an introduction a few emails down, but to recap my name is Sam, I'm
>> a college freshman, and I'm very interested in working on improving Sympy's
>> benchmarking services over this summer through GSOC.
>>
>> While going through the project description I had a few questions:
>>
>> 1) *"It also needs an automated system to run them"*
>> What exactly is meant by this.  Right now, github actions seems to be
>> already automatically running benchmarking after each pr.  Why is this not
>> an automated system?  Is the meaning of automated system something that
>> runs weekly/monthly on the whole repo, generates a benchmark report and
>> sends it* somewhere?*
>>
>> 2) *How to go about hosting benchmarks on a remote, dedicated machine?*
>> What's the general idea of how to go about this in open source project.  Is
>> there money available to pay some cloud provider to host it?  Free hosting
>> options?(doesn't seem reliable enough for benchmarking).
>>
>> 3) *SymEngine vs SymPy.  *I'm not familiar with SymEngine.
>> Approximately how similar are SymPy and SymEngine?  Is making the project
>> also work with SymEngine more of a quick fix(≈1-2 weeks) or should I expect
>> it to take longer?
>>
>> 4) *Current Benchmark Suite*
>> *"We currently have a benchmarking suite and run the benchmarks on GitHub
>> Actions, but this is limited and is often buggy"*
>>
>> What are the limitation(s) to github actions that this project should
>> address?
>> If we don't use github actions, is there another way to make it run after
>> every PR like we have now?
>>
>> 5) *Where are the tests run now?*
>> On the project description it says " the results are run and hosted Ad
>> Hoc", which I assumes means whatever computer is running all the other PR
>> tests.  Just want to make sure this is correct.
>>
>>
>> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/9c277927-7ac7-4c91-8c10-9ec63263f307n%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AgMBvGuzZC2c_jahOtpcF%2B8viaKLW%2BayxTQXoHSxAcw3A%40mail.gmail.com.

Re: [sympy] Regarding reviewing of proposal in physics.control

[Jason Moore]

Hi Abhishek,

The proposal looks good and thorough. My only concern is that the proposed
contributions are mostly focused on mimicking behavior from python control
or matlab, which are purely numerical. We should focus on adding things to
and improving sympy control that leverages symbolics. Please think about
each of your proposed features and what they look like from a symbolic
perspective and whether you are adding functionality that python control
already has or actually bringing some interesting new symbolic features to
a user's "control toolbox".

Jason
moorepants.info
+01 530-601-9791


On Tue, Mar 26, 2024 at 11:41 PM ABHISHEK KUMAR 
wrote:

>
> On Wed, 27 Mar 2024, 4:04 am ABHISHEK KUMAR, 
> wrote:
>
>> Hi,
>>
>> I'm Abhishek, and I'm currently a third-year student at NIT Delhi. I'm
>> eager to participate in the upcoming GSoC 2024. Due to my examinations, I
>> couldn't contribute for about three weeks. Now, I'm keen to work on the
>> control system module of SymPy. I've included a link to my draft proposal
>> below. While it's not perfect, I'm committed to refining it as much as
>> possible.
>>
>> I kindly request potential mentors Jason and Anurag to review my
>> proposal. Any suggestions or feedback would be greatly appreciated.
>>
>> *Link to Proposal*
>>
>> https://docs.google.com/document/d/1dmm7goYEyVcVkXrpwJm84yp6BmwfKrLB9rntZDA7R8g/edit?usp=sharing
>>
>> Thank you.
>> Abhishek Kumar
>> Github: abhiphile 
>>
>> --
>> 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 discussion on the web visit
>> https://groups.google.com/d/msgid/sympy/9553738b-f42f-4d9d-99c9-9031c3276c22n%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 sympy+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAHZvv1b6zY-ysyv%3DOz4LOeCjnscg5%2BL7ZbPh1M64%2B4yU8wM_VQ%40mail.gmail.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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AidMpydxkUp5Lu%3DiAM%2BEaNV9HvY5PDWR7Mr-0FQTAOt3w%40mail.gmail.com.

Re: [sympy] GSoC'24: Project idea and proposal

[Jason Moore]

Dear Bhavya,

We recommend applying for one of the ideas on our ideas list. The chances
that we accept things not proposed there are rather low I'm afraid.

Jason


On Tue, Mar 26, 2024 at 2:13 PM Bhavya Duggi 
wrote:

> Greetings Sympy community!
>
> I am Bhavya Duggi, a third-year undergraduate from the Department of
> Electronics & Electrical Communication Engineering at Indian Institute of
> Technology Kharagpur, India. I am writing to express my interest in
> contributing to Sympy as part of GSoC’24.
>
> Going through the Sympy codebase for quite some time now, I could think of
> a potential idea – Digital Electronics. The controls module being so
> relevant to my major was a huge inspiration for this idea. Considering the
> fact that Digital Electronics is fundamental to many fields like
> communication, controls and computer systems, this would definitely enrich
> the application of Sympy for the benefit of the community majoring in
> Electronics & Communication or any such closely related field.
>
> Having taken the Digital Electronics course in the fourth semester of my
> curriculum and thus having the conceptual clarity, I am confident to carry
> out this project for the upcoming summer.
>
> I would be grateful if any mentor would like to extend the discussion on
> this and on a positive note, help me strengthen my proposal for the same.
>
> Regards,
>
> Bhavya Duggi,
>
> Github: invigorzz313 
>
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/4cf57061-8461-45a7-b946-eabdbdff6296n%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AhEEhQsiEFjpsauBm3mQvS3U%3D5mQNbKa3CYyoa71Gmm3A%40mail.gmail.com.

Re: [sympy] Proposal for GSoC 24

[Jason Moore]

Here is a really good example of a proposal:
https://github.com/sympy/sympy/wiki/GSoC-2016-Application-Sampad-Kumar-Saha:-Singularity-Functions

Jason
moorepants.info
+01 530-601-9791


On Sat, Mar 23, 2024 at 12:20 PM Jason Moore  wrote:

> Hi Spiros,
>
> We really want to see more clearly what you propose to do. Show some code
> examples of what you hope you may implement. Describe the set of fixes or
> features you will add.
>
> See some of the old successful applications on the sympy wiki
>
> Jason
> moorepants.info
> +01 530-601-9791
>
>
> On Sat, Mar 23, 2024 at 12:16 PM Spiros Ts 
> wrote:
>
>> Author: Spyridon Tsioupros
>> Github account: https://github.com/Spiros7bit
>> <https://github.com/Spiros7bit>
>>
>> I wrote the proposal but before making the submission to the GSoC:
>> 1. I wanted to send you the proposal in pdf format to let me know if
>> anything else is needed.
>> 2. I wanted to ask if, apart from GSoC, I should send it somewhere
>> else.
>>
>> The proposal is below in pdf format.
>>
>> Your sincerely, Spyridon.
>>
>> --
>> 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 discussion on the web visit
>> https://groups.google.com/d/msgid/sympy/7634bf5d-d467-4271-989c-5f9f1f4e0b59n%40googlegroups.com
>> <https://groups.google.com/d/msgid/sympy/7634bf5d-d467-4271-989c-5f9f1f4e0b59n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Aiub3fm7TrQXH5yt1NvjMQp1k-j%2Bgra1LwpM%2BVmh1bT3w%40mail.gmail.com.

Re: [sympy] Proposal for GSoC 24

[Jason Moore]

Hi Spiros,

We really want to see more clearly what you propose to do. Show some code
examples of what you hope you may implement. Describe the set of fixes or
features you will add.

See some of the old successful applications on the sympy wiki

Jason
moorepants.info
+01 530-601-9791


On Sat, Mar 23, 2024 at 12:16 PM Spiros Ts 
wrote:

> Author: Spyridon Tsioupros
> Github account: https://github.com/Spiros7bit
> 
>
> I wrote the proposal but before making the submission to the GSoC:
> 1. I wanted to send you the proposal in pdf format to let me know if
> anything else is needed.
> 2. I wanted to ask if, apart from GSoC, I should send it somewhere
> else.
>
> The proposal is below in pdf format.
>
> Your sincerely, Spyridon.
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/7634bf5d-d467-4271-989c-5f9f1f4e0b59n%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Aj-7AC8DsDMkhLAbNiqffANjBLUEtArLC_0z0ze8quB2A%40mail.gmail.com.

Re: [sympy] GSoC Proposal: Enhancing Physics Mechanics Module

[Jason Moore]

Dear Prey,

We listed each item in your bullet list as different projects. I think the
scope will be too large if you try to do all of them. I recommend writing a
proposal for a single idea in the ideas list. We listed our priority ideas
at the top of the mechanics list.

Jason
moorepants.info
+01 530-601-9791


On Mon, Mar 11, 2024 at 10:16 PM 'Patel Prey' via sympy <
sympy@googlegroups.com> wrote:

> Hello everyone,
>
> I am Prey Patel, a B. Tech student from IIT Gandhinagar. I am pursuing
> dual majors in Computer Science and Engineering as well as Civil
> Engineering. Over the past few months, I've been actively engaged with
> SymPy, primarily focusing on resolving issues related to the physics beam
> module.
>
>
> I am interested in contributing to the GSoC project related to classical
> mechanics. My project aims to
>
>- Implement Newton Euler's method and Hamilton's method to generate
>equations of motion.
>- Improve the code base to speed up the generation of equations of
>motion.
>- Create a benchmark suite deriving the equations of motions using
>different methods.
>- Implement a set of common forces and torques. (Contact forces and
>Aerodynamic forces)
>
> Through these, I aim to contribute to SymPy's capabilities in the
> mechanics of physics. I have gone through the physics mechanics module and
> also studied Newton Euler's method for generating EoM.
>
>
> I would greatly appreciate any feedback or validation from the mentors
> regarding the feasibility and suitability of my proposed project. Your
> insights and guidance would be invaluable in ensuring that my contributions
> align effectively with the goals and expectations of SymPy.
>
>
> Thank you for your time.
>
>
> Yours sincerely,
>
> Prey Patel
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/63950552-b5c8-4f2f-bd02-9825e91f4f9fn%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Ajt4hyqc2U62FNaAwUSQSQPKG47ixCJAL%3DoVB3gN2SNUw%40mail.gmail.com.

Re: [sympy] In memory of Kalevi Suominen

[Jason Moore]

Hi Oscar,

That is very sad to hear. I did not know Kalevi other than through SymPy
but it looks like he was an Emeritus mathematics professor from the
University of Helsinki. This page shows a photo of him:

https://wiki.helsinki.fi/xwiki/bin/view/mathstatHenkilokunta/Henkil%C3%B6t/Suominen%2C%20Kalevi/

His contributions to SymPy will live on. I believe he mentored GSoC
students. If anyone knows more about Kalevi and can share, that would be
much appreciated.

Sincerely,

Jason
moorepants.info
+01 530-601-9791


On Sun, Mar 10, 2024 at 5:31 PM Oscar Benjamin 
wrote:

> Hi all SymPy community,
>
> It is with great sadness that I bring the news that Kalevi Suominen
> (@jksuom on GitHub) passed away on the 4th of March. Kalevi's son
> Risto passed on this news to me and some others by email yesterday.
>
> I never met Kalevi in person but we had many conversations online over
> many years. Kalevi was an outstanding SymPy contributor and was
> involved with the project long before me and so there are others here
> who have known him much longer than I have. Kalevi guided many SymPy
> contributors and supervised many GSOC students over many years.
> Looking in the git history his earliest commit was from almost exactly
> 10 years ago.
>
> Personally I learnt a huge amount from Kalevi and I am very grateful
> for the time he took to teach me and others and to guide the project
> generally. Kalevi's expertise in many areas of Mathematics and across
> the full depth of many parts of the SymPy codebase was unmatched
> within the community.
>
> Interacting through GitHub I guess that many of us did not realise
> that Kalevi's health was in decline. He continued to be involved
> including most recently reviewing a pull request just 6 weeks ago. A
> few weeks ago he sent me some files with what he was most recently
> working on but was no longer able to finish. I will try to complete
> that work and submit it as Kalevi's final pull request.
>
> Kalevi's passing is a huge loss to SymPy but I don't want to dwell on
> that. Instead I invite those of us who have known Kalevi to share
> their thoughts and memories here.
>
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAHVvXxTRWVQp_N_0%3DNnf-yBJwSu373sw-NB7UKuZCks2HTHGaA%40mail.gmail.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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AgzKoA5-P_OH0GZwFOjd4M5ipFPVV14RgSaHL73qwxYCQ%40mail.gmail.com.

Re: [sympy] Addin sympy to SPEC 0?

[Jason Moore]

A reason to depend on and be compatible with more than 1 version of SymPy
would be to maximize compatibility when installing your package (and thus
SymPy) alongside a collection of interdependent packages.

Jason
moorepants.info
+01 530-601-9791


On Sun, Mar 10, 2024 at 4:40 PM Oscar Benjamin 
wrote:

> Hi Anton,
>
> To be clear I am not against adding SymPy to SPEC 0. I just want to
> understand what this means in practice. Presumably if SymPy is added
> there then people will have some expectation that it means something
> somehow.
>
> I don't really know how to answer the question "which versions of
> SymPy should I try to support within my package that has SymPy as a
> dependency" because I am not sure what the benefit would be of
> supporting more than 1 version of SymPy.
>
> Is there a reason that someone would need to combine a newer version
> of your package with an older version of SymPy?
>
> Oscar
>
> On Sun, 10 Mar 2024 at 15:18, Anton Akhmerov 
> wrote:
> >
> > Hi Oscar,
> >
> > I want to be able to answer a question: "which versions of SymPy should
> I try to support within my package that has SymPy as a dependency". It
> doesn't make a big difference whether this question is answered by SPEC 0
> or by SymPy itself, except for SPEC 0 being a central point of reference. I
> realized that SymPy has no support cycle, but I think the question is still
> useful regardless.
> >
> > Anton
> > On Sunday 10 March 2024 at 15:48:13 UTC+1 Oscar wrote:
> >>
> >> Hi Anton,
> >>
> >> What difference does it make to you in practice whether or not SymPy
> >> is listed in SPEC 0?
> >>
> >> SymPy does not really support old versions with maintenance releases
> >> so it does not really have a "support cycle" in the sense that SPEC 0
> >> seems to describe. There can be a bugfix release shortly after a
> >> feature release to fix some obvious regressions but that is basically
> >> it.
> >>
> >> SymPy itself broadly tries to have wide version support for other
> >> packages like numpy just because without listing them as hard
> >> dependencies there is no way to indicate which versions sympy is
> >> compatible with. There is no way to put version constraints on
> >> optional dependencies in pip/PyPI land.
> >>
> >> Oscar
> >>
> >> On Sun, 10 Mar 2024 at 14:24, Anton Akhmerov 
> wrote:
> >> >
> >> > Hi all,
> >> >
> >> > There is now SPEC 0, a SciPy-community-wide standard for versions of
> different packages that developers should aim supporting, see
> https://scientific-python.org/specs/spec-/
> >> >
> >> > I believe Sympy is the biggest package missing from SPEC 0, and I've
> asked the maintainers of SPEC 0 what is the best way to proceed (
> https://discuss.scientific-python.org/t/spec-0-include-sympy/975?u=akhmerov).
> They appear to welcome the idea and recommended to reach out via this
> mailing list.
> >> >
> >> > So here's the question I'd like to know (as someone authoring
> software that depends on Sympy): would Sympy like to join SPEC 0?
> >> >
> >> > Thank you for your consideration,
> >> > Anton
> >> >
> >> > --
> >> > 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/e21d2db6-8ac4-4b01-a92c-7e49eb591146n%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 sympy+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/abcea775-f3aa-45c0-883e-ceec9482cc6cn%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 sympy+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAHVvXxRk_ZZmbXig0fTJ3rQ_dn0Ecu4FfO_Nv9qG%3Dzd9Jy8AWg%40mail.gmail.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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Ag%3D7Di32DZRSRX01X2y_%3DBHTm4-o5W_GMRKoOX%3DgTu2Sw%40mail.gmail.com.

Re: [sympy] Add some links to README.md

[Jason Moore]

The test check failures you see are from something else, not your README
changes. We don't check anything about the readme other than it being
present.

Jason
moorepants.info
+01 530-601-9791


On Sun, Mar 3, 2024 at 12:09 PM Spiros Ts  wrote:

> Author: Spiros Tsioupros
> Github: https://github.com/Spiros7bit
> email: tsiouprosspi...@gmail.com
>
> Hello community, I made a pull request to add some links to README.md.
> While 63/68 checks are passed, 5 errors about test and
> test_optional_dependencies are thrown. I had read in the Development
> Workflow Process
> 
> that we should write tests when making pull requests for code changes.
>
> My question is: Do we have to write a test when we make changes to
> README.md or is the problem elsewhere?
>
> pull request link  is here.
>
> Yours sincerely.
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/0d348c35-8350-4f7c-a787-89d7ac7ea89fn%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AiR-vgX3Zu6tiA8%2BFBWsVQEX6jttoTApJBaousZdW2_GA%40mail.gmail.com.

Re: [sympy] Classical Mechanics: Efficient Equations of Motion Generation

[Jason Moore]

Timo Stienstra and myself will mentor any
physics.vetor/mechanics/biomechanics related projects. But please ask
questions on the mailing list.

Jason


On Thu, Feb 22, 2024 at 10:52 PM Tommaso Vaccari  wrote:

> Thank you Jason, If I have further questions, who would be the mentor for
> this project?
>
> Il giorno giovedì 22 febbraio 2024 alle 22:31:56 UTC+1 moore...@gmail.com
> ha scritto:
>
>> HI Tommaso,
>>
>> You can review the mechanics issues on the repo, there are some about
>> speed.
>>
>> But, the basic idea for this project is to profile vector and mechanics
>> code for complex problems and then write more efficient algorithms for
>> whatever is slow.
>>
>> Jasn
>>
>>
>> On Thu, Feb 22, 2024 at 6:00 PM Tommaso Vaccari 
>> wrote:
>>
>>> I am eager to apply for this idea. I am excited about the opportunity to
>>> contribute to optimizing the equation of motion (EoM) generation process
>>> using Kane's and Lagrange's methods in SymPy.
>>>
>>> I would like to know if there are other issues related to the speed of
>>> the module.
>>>
>>> Thanks !
>>>
>>>
>>> --
>>> 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/ee8ad307-c6b0-4f87-9a15-55ac5b5a1ed4n%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 sympy+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/35cb25b0-ccce-4711-a02c-475df17038e2n%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AhiQxcGtL%2BkxzwsE_25hN30KJtRa4c7GG2CMFM0L7p%2BTQ%40mail.gmail.com.

Re: [sympy] Classical Mechanics: Efficient Equations of Motion Generation

[Jason Moore]

HI Tommaso,

You can review the mechanics issues on the repo, there are some about speed.

But, the basic idea for this project is to profile vector and mechanics
code for complex problems and then write more efficient algorithms for
whatever is slow.

Jasn


On Thu, Feb 22, 2024 at 6:00 PM Tommaso Vaccari  wrote:

> I am eager to apply for this idea. I am excited about the opportunity to
> contribute to optimizing the equation of motion (EoM) generation process
> using Kane's and Lagrange's methods in SymPy.
>
> I would like to know if there are other issues related to the speed of the
> module.
>
> Thanks !
>
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/ee8ad307-c6b0-4f87-9a15-55ac5b5a1ed4n%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AhODY-A%3DRby6FEE_ypfzD5gOm%2BXEQbs_GVxJkzuY-%3DCLA%40mail.gmail.com.

Re: [sympy] Reviewing PRs and old SymPy issues

[Jason Moore]

Note that we get lots of PRs at this time because we require GSoC
applicants to have at least one merged PR. We could encourage the other
activities if we allow those to fulfill the requirement for the GSoC
application.

Jason


On Tue, Feb 6, 2024 at 6:05 AM Aaron Meurer  wrote:

> I'll also add that if you want to, we'll give triage permissions to
> just about anyone so they can go through and label old issues (triage
> permissions give you permissions to label issues). Just ask me or
> Oscar.
>
> Aaron Meurer
>
> On Mon, Feb 5, 2024 at 2:25 PM Oscar Benjamin
>  wrote:
> >
> > Hi all,
> >
> > There are currently a large number of new contributors opening various
> > pull requests and commenting on issues in the SymPy repo. This is
> > great to see, and I want to thank everyone who has been contributing.
> >
> > I would like to highlight though that opening pull requests is not the
> > only way to contribute to SymPy. There are many other ways to
> > contribute. In fact more important than opening pull requests is
> > *reviewing* pull requests and issues. For example if you can see that
> > a pull request likely needs some changes, then it is helpful to
> > comment on the pull request and suggest what changes are needed until
> > it looks ready to merge. I am sure that some of the new contributors
> > could tell quite quickly what changes would be needed in many of the
> > recently opened pull requests.
> >
> > In fact one of the most useful things that a relatively new
> > contributor can do is to review old issues. The SymPy repo currently
> > has over 4000 open issues. Many of these are old and are no longer
> > relevant or already fixed. You can often review these issues just by
> > testing the code in them. If the issue seems to be fixed then a pull
> > request with a test could be opened to close the issue. If you do want
> > to review old issues then I suggest using the issue labels to focus on
> > a particular area of the code base like "integrals" or "solvers" etc.
> >
> > This sort of work is actually much more helpful to the project than
> > opening pull requests for "easy to fix" issues.
> >
> > --
> > 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+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAHVvXxQFLH7L%3DjO8EosasVETJn1fCmWaCvbYp%3DMbxvQmg1pB9Q%40mail.gmail.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 sympy+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2B8WUQJa_d%2BATjAekCbRgi4D6XCevJqiCmf0EsieSf8gQ%40mail.gmail.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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AhzY_A2Rt9aMQy1M_6MzZ09L1uP0p_0RLcni1TpX8rwpw%40mail.gmail.com.

Re: [sympy] SymPy CZI Grant Code Generation & Biomechanics Outcomes

[Jason Moore]

Hi Aaron,

Thanks for the pointer to the transmutagen code. I was aware of what was
there, maybe we can revive it and get it into SymPy.

Jason
moorepants.info
+01 530-601-9791


On Tue, Nov 14, 2023 at 10:32 PM Aaron Meurer  wrote:

> Thank you for sharing the blog post Jason.
>
> Some of the work you are doing related to getting the codegen to
> output a matrix solve instead of inverses is related to the work I did
> years ago here
> https://github.com/ergs/transmutagen/blob/master/transmutagen/codegen.py.
> I wish I had taken the time to upstream it. I'm excited to see that
> codegen for matrix expressions is finally starting to improve.
>
> Aaron Meurer
>
> On Fri, Oct 27, 2023 at 12:31 AM Jason Moore  wrote:
> >
> > Hi,
> >
> > I've made a blog post summarizing all the work we did for 1/3 of the CZI
> grant:
> >
> > https://mechmotum.github.io/blog/czi-sympy-wrapup.html
> >
> > Feedback welcome and please try out the new code!
> >
> > Jason
> > moorepants.info
> > +01 530-601-9791
> >
> > --
> > 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAP7f1Ag9n7HdZWdLTD%3DrpVTDB_wLhZdC%2BZuOcFkL2nw0Atb-BQ%40mail.gmail.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 sympy+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAKgW%3D6LGLJyG4FR%2Bdd99ctge5L0%3DDBsZ65hNyU3FU1kUYi9s1A%40mail.gmail.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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Ah0b3iMwMePoRJLCuN4fys70HD%2BWZHzR4fauLodEwUOXA%40mail.gmail.com.

[sympy] Blog post using SymPy and Python Control

[Jason Moore]

I thought this was a nice demo and intro in using SymPy with numerical
packages:

https://alefram.github.io/posts/How-to-use-python-for-pid-controller-design

Jason
moorepants.info
+01 530-601-9791

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AjsW-crrGcWUCAaW67XFZVXzEoAgq3bk9zX_fJu8iD6EQ%40mail.gmail.com.

Re: [sympy] SymPy CZI Grant Documentation Blog Post

[Jason Moore]

Great work Aaron! A docs upgrade has been long needed.

Jason
moorepants.info
+01 530-601-9791


On Thu, Nov 2, 2023 at 8:16 AM Aaron Meurer  wrote:

> I have written a blog post about the documentation work that I did as
> part of the CZI EOSS cycle 4 grant.
>
> https://labs.quansight.org/blog/sympy-documentation
>
> Feedback on the new documentation pages or documentation feedback in
> general is always welcome.
>
> Aaron Meurer
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAKgW%3D6KU57OZmyJ0wB2MvW-HLW%3DqjJWJU8CiKBdRbGcMUw5DXQ%40mail.gmail.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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AiT2u7CkAhi%2BDysWG6%3DOXk9%3DRdO-Hy7zaQtUueUAiXZRw%40mail.gmail.com.

[sympy] SymPy CZI Grant Code Generation & Biomechanics Outcomes

[Jason Moore]

Hi,

I've made a blog post summarizing all the work we did for 1/3 of the CZI
grant:

https://mechmotum.github.io/blog/czi-sympy-wrapup.html

Feedback welcome and please try out the new code!

Jason
moorepants.info
+01 530-601-9791

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Ag9n7HdZWdLTD%3DrpVTDB_wLhZdC%2BZuOcFkL2nw0Atb-BQ%40mail.gmail.com.

[sympy] Re: Proposal to accept SymPEP #1: SymPEP Purpose and Process

[Jason Moore]

Dear all,

SymPEP 1 has been accepted. This outlines the process to use as we move
forward with new SymPEPs.

See: https://github.com/sympy/SymPEPs/blob/main/SymPEP-0001.md

Thanks for all the review comments and help getting this merged. Thanks to
Aaron for initiating it.

Jason
moorepants.info
+01 530-601-9791


On Thu, Aug 31, 2023 at 3:22 PM Jason Moore  wrote:

> Dear all,
>
> I have renewed work on helping us adopt a PEP-style procedure for SymPy.
> The first step would be to agree on a process. Aaron started SymPEP 1
> roughly 2 years ago and I've worked on it recently to address all the
> comments from the past 2 years. My final draft is available for viewing
> here:
>
> https://github.com/sympy/SymPEPs/pull/2
>
> To follow the process outlined in the SymPEP I would like to propose this
> draft for acceptance.
>
> There have been no real major points of contention, but I suppose there
> could be unspoken reluctance to adopt this process at all as it adds
> formality to SymPy's development that we haven't had in the past. I believe
> we need this formality to allow SymPy to make larger changes so that we can
> remain a leading open source CAS. Most large changes get bogged down and
> never realized. This method for adopting and agreeing on change has proven
> effective in many other major Python projects.
>
> *If there are no substantive objections within 7 days from this email,
> then the SymPEP will be accepted; see SymPEP 1 for more details.* I
> propose the 7 days, because it has been up for review for 2 years already.
>
> Thanks for the support on this.
>
> Sincerely,
>
> Jason
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Aj8s6W3qttS9OMMV4AtKGH1V0mGTGz9Jfmf9%2B6ULH3L7g%40mail.gmail.com.

[sympy] Proposal to accept SymPEP #1: SymPEP Purpose and Process

[Jason Moore]

Dear all,

I have renewed work on helping us adopt a PEP-style procedure for SymPy.
The first step would be to agree on a process. Aaron started SymPEP 1
roughly 2 years ago and I've worked on it recently to address all the
comments from the past 2 years. My final draft is available for viewing
here:

https://github.com/sympy/SymPEPs/pull/2

To follow the process outlined in the SymPEP I would like to propose this
draft for acceptance.

There have been no real major points of contention, but I suppose there
could be unspoken reluctance to adopt this process at all as it adds
formality to SymPy's development that we haven't had in the past. I believe
we need this formality to allow SymPy to make larger changes so that we can
remain a leading open source CAS. Most large changes get bogged down and
never realized. This method for adopting and agreeing on change has proven
effective in many other major Python projects.

*If there are no substantive objections within 7 days from this email, then
the SymPEP will be accepted; see SymPEP 1 for more details.* I propose the
7 days, because it has been up for review for 2 years already.

Thanks for the support on this.

Sincerely,

Jason

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AhV1L10%3DbosUpu%3DMnpaNLsvRfK_m8gmjpeiOiqKxp6skA%40mail.gmail.com.

Re: [sympy] SymPy 1.12 released

[Jason Moore]

Peter, you might find that lambdify is significantly faster for your work :)

Jason
moorepants.info
+01 530-601-9791


On Thu, May 11, 2023 at 11:58 AM Peter Stahlecker <
peter.stahlec...@gmail.com> wrote:

> Thanks! I installed, all works fine.
> An impressive list of contributors!!
> A shame, I am likely too old (and probably not smart enough)to be one,
>  but I am a happy user!
>
> On Thu 11. May 2023 at 15:15 Oscar Benjamin 
> wrote:
>
>> Hi all,
>>
>> I've pushed out the release of SymPy 1.12 last night. It can be
>> installed from PyPI with
>>
>> pip install --upgrade sympy
>>
>> The release files are also available from GitHub:
>>
>> https://github.com/sympy/sympy/releases/tag/sympy-1.12
>>
>> Please try out SymPy 1.12 and report and issues to GitHub. If you find
>> a new issue with this release then please make it clear when opening
>> an issue if it is a regression compared to 1.11.
>>
>> It has been 9 months since the release of SymPy 1.11 so there are many
>> changes including bug fixes and new features. The release notes for
>> 1.12 are here:
>>
>>https://github.com/sympy/sympy/wiki/Release-Notes-for-1.12
>>
>> The following people contributed at least one patch to this release
>> (names are
>> given in alphabetical order by last name). A total of 76 people
>> contributed to this release. People with a * by their names contributed a
>> patch for the first time for this release; 42 people contributed
>> for the first time for this release.
>>
>> Thanks to everyone who contributed to this release!
>> - Jyn Spring 琴春*
>> - anutosh491
>> - Ayush Aryan*
>> - Blair Azzopardi
>> - Stefan Behnle*
>> - Oscar Benjamin
>> - Evandro Bernardes*
>> - Anurag Bhat
>> - Francesco Bonazzi
>> - Sam Brockie*
>> - Pontus von Brömssen*
>> - Zach Carmichael
>> - Michele Ceccacci*
>> - cocolato
>> - Costor*
>> - Björn Dahlgren
>> - Nikhil Date
>> - Eric Demer*
>> - Devansh*
>> - Pieter Eendebak
>> - ForeverHaibara*
>> - Tim Gates
>> - Aaron Gokaslan*
>> - Kishore Gopalakrishnan*
>> - Oscar Gustafsson
>> - Charles Harris*
>> - haru-44*
>> - Jan-Philipp Hoffmann*
>> - Glenn Horton-Smith*
>> - Victor Immanuel*
>> - Karan*
>> - Chris Kerr*
>> - Steve Kieffer
>> - Uwe L. Korn*
>> - Zoufiné Lauer-Baré*
>> - S.Y. Lee
>> - Andrey Lekar
>> - Phil LeMaitre*
>> - Qijia Liu
>> - luzpaz
>> - Megan Ly
>> - Gareth Ma*
>> - Aaron Meurer
>> - Arthur Milchior*
>> - Shreyash Mishra*
>> - Sayan Mitra*
>> - Jeremy Monat
>> - Carlos García Montoro*
>> - Jason Moore
>> - NotWearingPants*
>> - Julien Palard
>> - Ishan Pandhare*
>> - Abhishek Patidar*
>> - Advait Pote
>> - Mamidi Ratna Praneeth
>> - Psycho-Pirate
>> - Biswadeep Purkayastha*
>> - Juha Remes
>> - Klaus Rettinghaus*
>> - Clément M.T. Robert*
>> - Saicharan*
>> - Tejaswini Sanapathi*
>> - Davide Sandonà
>> - Hanspeter Schmid
>> - José Senart*
>> - Kunal Sheth*
>> - Aman Kumar Shukla*
>> - Chris Smith
>> - Paul Spiering
>> - Timo Stienstra
>> - Kalevi Suominen
>> - Parcly Taxel*
>> - Yves Tumushimire*
>> - Eric Wieser
>> - wookie184*
>> - Zouhair
>>
>> The SHA 256 hashes for the release artifacts are:
>>
>> ebf595c8dac3e0fdc4152c51878b498396ec7f30e7a914d6071e674d49420fb8
>> sympy-1.12.tar.gz
>> c3588cd4295d0c0f603d0f2ae780587e64e2efeedb3521e46b9bb1d08d184fa5
>> sympy-1.12-py3-none-any.whl
>> c1249cd14c5bc2ad20ce8d5fd4884bc51062bc0eddb79537e0996b05befe1097
>> sympy-docs-html-1.12.zip
>> 34455a55aece7dc38a090728b500e5f6bdebe588be93ed6fbc3262694d681ed6
>> sympy-docs-pdf-1.12.pdf
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/sympy/CAHVvXxQ8CE4Ac%3DpnOLb%3DO4-v8kZc3JTN0T94U7n6EcU0U%3DKyKA%40mail.gmail.com
>> .
>>
> --
> Best regards,
>
> Peter Stahlecker
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CABKqA0brVsYWsdZ3MVTV5Xji2XeO7iZPW%3DZjCamTnz-RQ8HDdg%40mail.gmail.com
> <https://groups.google.com/d/msgid/sympy/CABKqA0brVsYWsdZ3MVTV5Xji2XeO7iZPW%3DZjCamTnz-RQ8HDdg%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Aidk1XkAkE8YaC4d3vB7T3G9xSPPJ-NVibbhwkfFiG14w%40mail.gmail.com.

Re: [sympy] Preferred way to include printing functionalities

[Jason Moore]

This is the file:
https://github.com/sympy/sympy/blob/master/sympy/physics/vector/printing.py

I believe you are correct in that it could be located with the printing
package.

Jason
moorepants.info
+01 530-601-9791


On Fri, Apr 14, 2023 at 3:18 AM Aaron Meurer  wrote:

> I wonder if this is really necessary. I'd say as a general rule that
> printing logic for things that are part of SymPy should go in the
> printers themselves. The printers should already support dispatching
> to non-Basic classes. Is there some other reason this is needed?
>
> An advantage of keeping the code in the printer itself is that any
> time someone does a code cleanup in the printers they will apply it to
> the physics printers as well. It also makes it easier for those
> printers to reuse internal helper functions in the printers. I've
> noticed that the physics objects have had a lot more printing bugs
> than most other SymPy objects.
>
> Aaron Meurer
>
> On Wed, Apr 12, 2023 at 8:28 AM Jason Moore  wrote:
> >
> > For the physics objects, I recommend copying how we've done it for
> Vector and Dyadic. We keep the printing code in the physics.vector modules
> because these objects don't subclass from basic and need some special
> attention.
> >
> > Jason
> > moorepants.info
> > +01 530-601-9791
> >
> >
> > On Wed, Apr 12, 2023 at 3:44 PM Pedro Xavier 
> wrote:
> >>
> >> I'm trying to add printing functionalities to
> physics.vector.point.Point and looking at other printable objects in the
> package I've noticed that there are at least two ways of going about this.
> I've seen classes inheriting from printing.defaults.Printable and then
> implementing the required methods for printing inside the class definition
> (e.g. physics.vector.vector.Vector) and I've seen methods being implemented
> directly into the printer (e.g. vector.basisdependent.BasisDependent). My
> question is: which way of handling printing is preferred?
> >>
> >> --
> >> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/c478a183-ced3-4971-b851-0f8128cbd1b6n%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 sympy+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAP7f1Ai4Y-z9g%2Bpbf_XXCPdZSMEZjrwNp%3Dcv8Ddk7WHJ8ixACA%40mail.gmail.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 sympy+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAKgW%3D6J8dCbxrsOxfM_5FV2qJDFfhNrqQoFHWwsgwOiH%2BVCfVg%40mail.gmail.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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AiP7rDO6WuzvyG3qqeqNwmJdvcd%3DvLEyZqHu1fT8xdTng%40mail.gmail.com.

Re: [sympy] Preferred way to include printing functionalities

[Jason Moore]

For the physics objects, I recommend copying how we've done it for Vector
and Dyadic. We keep the printing code in the physics.vector modules because
these objects don't subclass from basic and need some special attention.

Jason
moorepants.info
+01 530-601-9791


On Wed, Apr 12, 2023 at 3:44 PM Pedro Xavier 
wrote:

> I'm trying to add printing functionalities to physics.vector.point.Point
> and looking at other printable objects in the package I've noticed that
> there are at least two ways of going about this. I've seen classes
> inheriting from printing.defaults.Printable and then implementing the
> required methods for printing inside the class definition (e.g.
> physics.vector.vector.Vector) and I've seen methods being implemented
> directly into the printer (e.g. vector.basisdependent.BasisDependent). My
> question is: which way of handling printing is preferred?
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/c478a183-ced3-4971-b851-0f8128cbd1b6n%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Ai4Y-z9g%2Bpbf_XXCPdZSMEZjrwNp%3Dcv8Ddk7WHJ8ixACA%40mail.gmail.com.

Re: [sympy] Enabling precommit.ci to fix common PR problems automatically

[Jason Moore]

When the # of dependencies is large, dependabot is a very annoying feature.
I contributed to a Javascript lib and the dependabot floods your inbox and
notifications with useless PRs. It may be ok for us, since it is only
checking a handful of dependencies and those don't change too often.

Jason
moorepants.info
+01 530-601-9791


On Fri, Mar 31, 2023 at 10:44 PM Aaron Meurer  wrote:

> I only ever hear bad things about dependabot. I don't have any
> experience with it myself, but I would be cautious about using it.
> Maybe try reaching out to other communities that have tried it to see
> what their experiences have been.
>
> Aaron Meurer
>
> On Fri, Mar 31, 2023 at 8:20 AM Oscar Benjamin
>  wrote:
> >
> > Okay, so it seems people are not keen on integrating the pre-commit.ci
> bot.
> >
> > We can of course continue to make a pre-commit config that any
> > contributor wants to use.
> >
> > Another question I have is what people think about using dependabot.
> > We regularly have problems where new versions of SymPy's dependencies
> > cause breakage in CI. This can happen because of things like:
> >
> > - New Sphinx versions. Basically every significant release of Sphinx
> > seems to break some part of building SymPy's docs.
> > - New numpy/scipy etc versions. It is common that these will introduce
> > things like deprecation warnings and also various things will break
> > because of the removal of functions etc.
> > - New versions of linters like flake8 and its plugins or mypy.
> >
> > Whenever this happens and CI gets broken it is both disruptive and
> > confusing for any contributors whose PRs will fail CI checks because
> > of problems that are unrelated to the changes they have made.
> >
> > A common way to prevent CI from breaking is to pin dependencies of the
> > things that are used in CI but the difficulty with that is the need to
> > keep the pinned versions updated as new releases are made. A widely
> > used solution for this is dependabot which is a bot that can
> > automatically open PRs to update pinned versions. Depending on how
> > many versions are pinned and how often the pinned things make new
> > releases there would be some number of PRs from dependabot updating
> > versions one dependency at a time (dependabot does not have a way to
> > do several dependencies in a single PR).
> >
> > The advantage of using dependabot is that if a new version of some
> > dependency causes CI to break then it will only break in dependabot's
> > PR that tries to bring in the update. Otherwise we can keep things
> > updated by updating the versions only when CI passes.
> >
> > The dependabot update PRs can be annoying but at the same time they
> > are very simple PRs that are easy to review and merge if CI passes.
> > When CI fails they would often also be easy problems to fix and would
> > often make suitable "easy to fix" issues (we can afford to do this if
> > there is no need to rush in a fix because of broken CI).
> >
> > Does anyone have any views on enabling dependabot on the SymPy repo
> > (or some similar alternative)?
> >
> > --
> > Oscar
> >
> > On Tue, 28 Mar 2023 at 22:53, Aaron Meurer  wrote:
> > >
> > > That's what I was worried about too. If the bot pushes a commit, then
> the PR author won't be able to push any additional commits unless they
> either pull first or force push. Personally I would find that a little
> surprising, and might not even notice it when I do "git push". Plus I feel
> like this would push people into the bad habit of always force pushing.
> > >
> > > Aaron Meurer
> > >
> > > On Tue, Mar 28, 2023 at 9:50 AM Jason Moore 
> wrote:
> > >>
> > >> I personally would find a bot adding commits to my work a bit
> intrusive. If the bot posted a comment to the issue telling me what to fix,
> that would be preferable. Right now we have to make a few clicks to see why
> the linter failed.
> > >>
> > >> Conda forge has a bot that will add commits to your branch, but only
> if you explicitly ask it to. If we had some bot commands like '@sympy/bot
> please fix flake8 issues' then that would run the fix and add the commit,
> but it is the author's choice to do so.
> > >>
> > >> Jason
> > >> moorepants.info
> > >> +01 530-601-9791
> > >>
> > >>
> > >> On Tue, Mar 28, 2023 at 3:41 PM Oscar Benjamin <
> oscar.j.benja...@gmail.com> wrote:
> > >>>
> > >>> Hi all,
> > >>>

Re: [sympy] Regarding GSoC 2023 Project idea

[Jason Moore]

Yes they are both valid.

Jason
moorepants.info
+01 530-601-9791


On Wed, Mar 29, 2023 at 2:48 PM Jay Sharma  wrote:

> Hello Everyone! My name is Jay Sharma, I want to know about the current
> status of these projects and potential mentors of that ideas?
> 1. Benchmark and Performance
> 2. Assumptions
> Are both ideas valid for GSoC 2023?
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/de25fad1-23a6-4f30-9e22-27a2de32c8f6n%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AhAVrwxe7%3DCD9Ew%3DKYv6Sq6u%2BEq8DVrZRdbTcb0P%2B8hfw%40mail.gmail.com.

Re: [sympy] Intro and Potential GSOC Project Ideas

[Jason Moore]

The old are what I just showed "positive=True" when defining variables.

The new idea is to do something like:

with assume(x > 0):
res = Abs(x)

res will then be just x.

That's not the syntax though, I don't know it off the top of my head.

moorepants.info
+01 530-601-9791


On Wed, Mar 29, 2023 at 11:10 AM Peter Stahlecker <
peter.stahlec...@gmail.com> wrote:

> Dear Jason,
>
> YES, of course I remember.
> This means, assumptions have the literal English meaning, like 'I asssume
> x to be real and larger than 5'?
> If I understood correctly, then what are 'old' and 'new' assumptions?
>
> Thanks, Peter
>
> On Wed 29. Mar 2023 at 10:11 Jason Moore  wrote:
>
>> Hi Peter,
>>
>> You've probably seen this example:
>> https://moorepants.github.io/learn-multibody-dynamics/sympy.html#differentiating,
>> but in the "warning" box you can see how setting assumptions on the
>> variables changes the results (positive, real, etc).
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791
>>
>>
>> On Wed, Mar 29, 2023 at 10:03 AM Peter Stahlecker <
>> peter.stahlec...@gmail.com> wrote:
>>
>>> Dear Tilo,
>>>
>>> I am just a (semi retired) recreational user of sympy, mostly
>>> sympy.physics.mechanics. I have no ambition, and certainly no skills to do
>>> anything with the code itself.
>>> Still, I like to understand things as much as possible, therefore my
>>> question:
>>>
>>> what is meant by *assumptions*?
>>>
>>> Thanks a lot!
>>>
>>> Peter
>>>
>>> On Wed 29. Mar 2023 at 09:26 Aaron Meurer  wrote:
>>>
>>>>
>>>>
>>>> On Wed, Mar 29, 2023 at 12:21 AM Tilo RC  wrote:
>>>>
>>>>> Thank you for your response Oscar. I think I’m interested in taking a
>>>>> stab at improving the capabilities of the new assumption system to deal
>>>>> with inequalities (and perhaps relations between symbols in general?). 
>>>>> I’ve
>>>>> spent a lot of time reading through the documentation, code, discussions,
>>>>> and previous proposals related to assumptions and come to some
>>>>> understanding. I’ve tried to explain what I understand so far below. Could
>>>>> you read through what I’ve written and correct any mistakes in my 
>>>>> thinking?
>>>>>
>>>>> For around a decade the SymPy community has wanted to transition from
>>>>> the “old assumptions” to the “new assumptions.” The old assumptions are
>>>>> seen as fundamentally limited compared to the new assumptions for reasons
>>>>> I’m trying to figure out. This is my understanding:
>>>>>
>>>>>-
>>>>>
>>>>>The old assumption system is deeply connected to the core of
>>>>>sympy. I think this is bad because it’s responsible for some of the 
>>>>> other
>>>>>problems with it and violates OOP principles.
>>>>>
>>>>>
>>>> It's not bad because of some abstract reasons. The issue is that the
>>>> old assumptions design limits what it is able to do. Assumptions can only
>>>> be made on symbols, deductions can only be done via direct chains of
>>>> inference from handlers, and it's impossible to add additional facts to the
>>>> system except by adding handlers to the specific relevant classes.
>>>>
>>>> Just as an example, inequality assumptions like x > 1 are simply
>>>> impossible to even represent in the old assumptions.
>>>>
>>>>
>>>>>
>>>>>-
>>>>>
>>>>>One fundamental flaw of the old assumption system is that it’s not
>>>>>possible to make assumptions about relations between different 
>>>>> variables.
>>>>>The new assumption system has this capability, and even though it is 
>>>>> not
>>>>>very feature rich, it has a lot of potential.
>>>>>
>>>>>
>>>> This is correct.
>>>>
>>>>
>>>>>
>>>>>-
>>>>>
>>>>>The old assumption system slows down SymPy. I’m not sure how true
>>>>>this still is. It seems like the core and the old assumption system 
>>>>> have
>>>>>gotten many improvements to make them faster. For example, because I
>>>&

Re: [sympy] Intro and Potential GSOC Project Ideas

[Jason Moore]

Hi Peter,

You've probably seen this example:
https://moorepants.github.io/learn-multibody-dynamics/sympy.html#differentiating,
but in the "warning" box you can see how setting assumptions on the
variables changes the results (positive, real, etc).

Jason
moorepants.info
+01 530-601-9791


On Wed, Mar 29, 2023 at 10:03 AM Peter Stahlecker <
peter.stahlec...@gmail.com> wrote:

> Dear Tilo,
>
> I am just a (semi retired) recreational user of sympy, mostly
> sympy.physics.mechanics. I have no ambition, and certainly no skills to do
> anything with the code itself.
> Still, I like to understand things as much as possible, therefore my
> question:
>
> what is meant by *assumptions*?
>
> Thanks a lot!
>
> Peter
>
> On Wed 29. Mar 2023 at 09:26 Aaron Meurer  wrote:
>
>>
>>
>> On Wed, Mar 29, 2023 at 12:21 AM Tilo RC  wrote:
>>
>>> Thank you for your response Oscar. I think I’m interested in taking a
>>> stab at improving the capabilities of the new assumption system to deal
>>> with inequalities (and perhaps relations between symbols in general?). I’ve
>>> spent a lot of time reading through the documentation, code, discussions,
>>> and previous proposals related to assumptions and come to some
>>> understanding. I’ve tried to explain what I understand so far below. Could
>>> you read through what I’ve written and correct any mistakes in my thinking?
>>>
>>> For around a decade the SymPy community has wanted to transition from
>>> the “old assumptions” to the “new assumptions.” The old assumptions are
>>> seen as fundamentally limited compared to the new assumptions for reasons
>>> I’m trying to figure out. This is my understanding:
>>>
>>>-
>>>
>>>The old assumption system is deeply connected to the core of sympy.
>>>I think this is bad because it’s responsible for some of the other 
>>> problems
>>>with it and violates OOP principles.
>>>
>>>
>> It's not bad because of some abstract reasons. The issue is that the old
>> assumptions design limits what it is able to do. Assumptions can only be
>> made on symbols, deductions can only be done via direct chains of inference
>> from handlers, and it's impossible to add additional facts to the system
>> except by adding handlers to the specific relevant classes.
>>
>> Just as an example, inequality assumptions like x > 1 are simply
>> impossible to even represent in the old assumptions.
>>
>>
>>>
>>>-
>>>
>>>One fundamental flaw of the old assumption system is that it’s not
>>>possible to make assumptions about relations between different variables.
>>>The new assumption system has this capability, and even though it is not
>>>very feature rich, it has a lot of potential.
>>>
>>>
>> This is correct.
>>
>>
>>>
>>>-
>>>
>>>The old assumption system slows down SymPy. I’m not sure how true
>>>this still is. It seems like the core and the old assumption system have
>>>gotten many improvements to make them faster. For example, because I
>>>accidentally read the SymPy 1.11
>>>
>>> 
>>>instead of the SymPy 1.13
>>>
>>> 
>>>documentation I learned about the ManagedProperties metaclass and then 
>>> saw
>>>it was removed to improve efficiency. (By the way, both of these sections
>>>from the documentation say that “This explanation is written as of SymPy
>>>1.7.” even though the writing clearly changed between 1.11 and 1.13).
>>>
>>>
>> This is still true. The issue isn't just the speed of the old
>> assumptions, but the fact that object constructors make heavy use of them.
>> Take the expression in https://github.com/sympy/sympy/issues/24565,
>> which takes 30 seconds just to construct. This time is all spent in
>> assumptions. Ideally, simply constructing an expression shouldn't call any
>> assumptions. One of the reasons the new assumptions are separate from the
>> core is that there was a hope that this would make it easier to remove
>> assumptions from core constructors (but really that isn't necessary; we
>> just need to be better about not using assumptions in constructors).
>>
>>
>>>
>>> As for improving how the new assumptions deal with inequalities, there
>>> are some very basic features they’re missing. For example,
>>> ask(Q.negative(x),Q.ge(x,1)) returns None under the current system even
>>> though it seems like it would be really simple to implement something where
>>> if x > 0 then x is not negative. Similarly, ask(Q.gt(x,0),Q.gt(x,1))
>>> returns None. A more complicated query that returns None is ask(Q.eq(x,1),
>>> Q.integer(x) & Q.gt(x,0) & Q.lt(x,2)).
>>>
>>> I also notice that even equality is somewhat limited in the new
>>> assumption system. For example, ask(Q.positive(y), Q.eq(x,y) &
>>> Q.positive(x)) returns None. I’m a bit unsure why this hasn’t been
>>> implemented. One guess I have is that 

Re: [sympy] Enabling precommit.ci to fix common PR problems automatically

[Jason Moore]

I personally would find a bot adding commits to my work a bit intrusive. If
the bot posted a comment to the issue telling me what to fix, that would be
preferable. Right now we have to make a few clicks to see why the linter
failed.

Conda forge has a bot that will add commits to your branch, but only if you
explicitly ask it to. If we had some bot commands like '@sympy/bot please
fix flake8 issues' then that would run the fix and add the commit, but it
is the author's choice to do so.

Jason
moorepants.info
+01 530-601-9791


On Tue, Mar 28, 2023 at 3:41 PM Oscar Benjamin 
wrote:

> Hi all,
>
> There are two open PRs discussing the potential use of pre-commit and
> pre-commit.ci in SymPy:
>
> https://github.com/sympy/sympy/pull/24908
> https://github.com/sympy/sympy/pull/24941
>
> I want to know what others think specifically about enabling
> pre-commit.ci on the sympy repo or otherwise encouraging use of
> pre-commit for contributors.
>
> I'll explain below but you can also read about pre-commit and
> pre-commit.ci here:
>
> https://pre-commit.com/
> https://pre-commit.ci/
>
> The pre-commit tool is something that can be installed locally and can
> be used directly or as a git hook so that when making a git commit
> some quick checks can run on the code. The PR gh-24908 would add some
> configuration for this so that a contributor can either run some
> checks before committing or can install pre-commit as a git hook so
> that git commit automatically runs the checks.  The configuration in
> gh-24908 means that pre-commit runs flake8 and ruff but specifically
> only on the files that are being changed in the commit which is
> convenient because it is much faster than checking the whole codebase.
>
> To be clear adding the pre-commit config to the sympy repo does not
> make it mandatory for all contributors to use the git hook. However it
> could be something that is "recommended" as it will quickly show up
> some common problems that would otherwise fail the checks in CI after
> opening a PR or after pushing to a PR.
>
> What is also discussed in those PRs is adding pre-commit.ci to the
> sympy repo which is something different from just adding a pre-commit
> configuration that contributors can choose to use or not. The
> difference is that pre-commit.ci is a GitHub bot that will run the
> pre-commit hooks on all pull requests and can often fix the problems
> automatically by pushing a new commit to the PR.
>
> Currently if someone pushes a PR that has simple problems like
> trailing whitespace or unnecessary imports then the flake8 or quality
> checks in CI will report an error asking the contributor to fix those
> problems. With pre-commit.ci we could make it so that those problems
> are just fixed automatically without the contributor needing to do
> anything.
>
> Both trailing whitespace and unnecessary imports are automatically
> fixable e.g. there is already a bin/strip_whitespace script and ruff
> can fix the imports with:
>
> ruff check --select F401 --fix sympy
>
> Obviously other things could be fixed automatically but these are the
> two that I see most often where someone pushes and then needs to push
> a followup fixing commit after seeing CI checks fail. If precommit.ci
> was used there would be no need to push a follow up commit because the
> bot would just do it automatically.
>
> On the other hand if someone uses the pre-commit hook locally then
> that could fix these things automatically before pushing and there
> wouldn't be any need for the bot to fix them in CI. The advantage of
> the CI bot would be that it could apply simple fixes for someone who
> does not use the git hook and didn't check pre-commit before pushing.
>
> To be clear there would not be any requirement for any individual
> contributor to use pre-commit locally. However if pre-commit.ci runs
> on PRs then that is obviously not optional and there would be a bot
> pushing fix commits to PRs.
>
> Does anyone have any thoughts on enabling pre-commit.ci or otherwise
> encouraging contributors to use pre-commit?
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAHVvXxSmJ2aGsiHf6%2BNFLaBL0xkUeH0_CJ86uqQR-py6uCZnxg%40mail.gmail.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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Ah9-uRCPqpFWzbNLp_4z4gBSmQ6xmr0_aHPcuD78W6%3DZA%40mail.gmail.com.

Re: [sympy] GSoC Application - Symbolic Control Systems (sympy.physics.control)

[Jason Moore]

The controls package in SymPy should, at least at first, let you solve
linear control systems problems symbolically found in an introductory
control textbook. My recommendation is to try to solve all the problems in
a controls textbook with SymPy (at least the symbolically relevant ones)
and in the process you will find all kinds of bugs and desired features.

Jason
moorepants.info
+01 530-601-9791


On Sun, Mar 26, 2023 at 10:57 AM Baiyuan Qiu (ColourfulWhite) <
qby1061688...@gmail.com> wrote:

> Dear SymPy Community,
>
> My name is Baiyuan Qiu, I am graduated with a bachelor of Communication
> Engineering and currently studying at the National University of Singapore
> for my master's degree. After browsing the project list of this year's
> GSoC, I found my interest in SymPy and Symbolic Control Systems.
>
> I want to express my motivation and concern of this idea. And I want to
> share with you some of my information.
>
> Firstly, why I choose the SymPy.
> To be short. I really hate Matlab when I was an undergraduate. It's
> powerful, but it's too bulky and cumbersome. It took up a big chunk of hard
> drive space on my cheap computer, and even when I set the installation
> location to a different hard drive, it added a lot of files to the C
> drive. Whether I want to start Simulink or just do symbolic computing, I
> have to wait at least five minutes to start Matlab (my computer was so
> cheap at that time).
> That's totally a terrible experience in my life. Although Python was
> introduced in class at that time, I never thought it could be so powerful
> to replace Matlab. I feel excited to support this project, I wanna join the
> Pythonic Knights to fight the Monster Matlab.
>
> Secondly, why I choose Symbolic Control Systems (sympy.physics.control) as
> my target idea.
> As I mentioned above, I am a bachelor of Communication Engineering. I had
> courses like Signals and Systems, and Digital Signal Processing. So the
> concepts like zero pole, bode, nyquist in the Future work part of the idea
> attract me immediately. I quickly found that it is the same technique as I
> learnt, although in a physics context.
> But I still have some concern, as I am working on Deep Learning recently,
> the knowledge of TransferFunction, Pole Zero are fading away in my memory,
> I have to pick them up if I am selected. I was also curious that the
> mathematics in the context of physics and control systems would not go
> beyond the mathematics in the context of signal processing that I studied.
> As I check the table of content of the reference book Feedback Systems:
> An Introduction for Scientists and Engineers
> , the
> topics are familiar to me. But I still feel a little worried. I would be
> really appreciated if anyone can clarify the boundary for me.
> Another point is that, I think this idea is a perfect one-person's job to
> experience open source workflow from design to implementation, to
> documentation.
>
> If you still have some interest on me after reading such a long email,
> here are some more information about me.
> This is my GitHub page: bugmaker2-github 
> As you can see, there are no serious big repositories, but some simple
> toys like this Spider
>  I
> wrote for myself. My GitHub serves more like an underground storehouse for
> my codes. Although I knew that open source and collaboration is the most
> important part in GitHub, it is hard for me to find a place to start.
>
> This is my website: Bugmaker's website 
> I haven't updated it for a long time, as I am considering moving the page
> to a more convenient platform. But you can still get to know a little bit
> more about me from the page.
>
> Regards,
> Baiyuan
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/30259e32-545c-4b8a-b909-49d344804e4fn%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AgXHdPJ7_pVM6aKMwCVrOjKDGt_HEvPCKOePBCq99ioGw%40mail.gmail.com.

Re: [sympy] Regarding Project idea for GSoC 2023

[Jason Moore]

HI Abhishek,

It will be best if you focus on an idea in the ideas list. In general, it
is better to do a project that improves existing code than adding new
packages. The control package still needs lots of work to make it very
useful to users, for example. Lastly, anything we add should be based in
symbolics, so copying matlab toolboxes isn't generally a good paradigm to
follow because matlab is primarily a numeric tool.

Jason
moorepants.info
+01 530-601-9791


On Sat, Mar 25, 2023 at 9:27 AM ABHISHEK KUMAR <
abhishekkumarupra...@gmail.com> wrote:

> I am a  sophomore student from NIT Delhi doing Bachelor in Technology in
> Electronics and Communication. I want to increase the capabilities of the
> SymPy library by including a communication toolbox for it as available in
> MATLAB. I plan to add all the modulation schemes, including analog and
> digital communication, with their plots in both time and frequency domains.
>
> I want to add a Signal and System module to SymPy, which will calculate
> everything about the signal bandwidth, time period, modulation index, power
> of the signal, error in signal due to noise from different channels, etc.
> I will use the SymPy plotting feature to plot various modulated and
> demodulated signals with and without noise.
> *This communication toolbox will contain modulation and demodulation of
> all the modulated signals.*
> *I have a detailed plan in my mind about the same topic. I have studied
> Signal and Systems, Control Theory, and Analog and Digital Communication in
> depth, which will help me implement it in the SymPy library. Sir, Please
> provide some feedback on my project idea. *
>
> Sir, I saw in 2020 the same way a new Control System module was added to
> this library by Naman Gera; this has increased the functionality of SymPy
> to solve the transfer functions,
> calculate the time response of the transfer function plot root locus
> diagrams, etc
> Sir, in the same way, this will help increase the capabilities to analyze
> signals more efficiently.
>
> Currently, I've completed the reading of about half of the docs and also
> implemented them on code in Jupyter, which has helped me to get interested
> in the library and its capabilities.I have to read the source code and
> understand how SymPy is written, and follow the same.
> I am confident that I will be able to implement the Communication toolbox
> in the SymPy library,
> Sir, please guide me on this so that I can create a detailed plan for this
> communication toolbox.
> Any small suggestion regarding GSoC or this library will be extremely
> valuable to me.
> Hoping for a positive response.
>
> Yours Sincerely
> Abhishek Kumar
> NIT DELHI
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/b74f12ed-081c-451e-87b2-f0f6fcb3e43en%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AiBRUOM60Ok635aVeKBb9rmBRVUagJLx28a1Z_LxgQczw%40mail.gmail.com.

Re: [sympy] Re: C Code Generator

[Jason Moore]

You can make custom printers for any SymPy function to return what you
desire. Subclass the C printer and overwrite/create methods for your
functions. The current c code printer does not target any specialized C
libraries (but that would be a nice addition!).

Jason
moorepants.info
+01 530-601-9791


On Sat, Mar 18, 2023 at 3:18 PM brombo  wrote:

> I have looked further and while ccode(expr) can export functions like sin,
> cox, exp it cannot export special functions such as bessel, elliptic, etc..
> Is there a way to export special functions into c-code?
>
> On Saturday, March 18, 2023 at 9:52:48 AM UTC-4 brombo wrote:
>
>> Does the C code generator generate special function calls with the same
>> syntax that is used in the gsl (GNU Scientific Library).  For example is
>> the sympy call besselj(nu,z) translated to J(nu,z) etc.?
>>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/73a99292-df6c-420a-804a-b2a52dfae437n%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AhS9tMr%2BZ7KsoQ23eX09Y2O%2BKswbqn4N28t7M_xtpHkxQ%40mail.gmail.com.

Re: [sympy] Feedback requested on new deprecations policy

[Jason Moore]

I now see that this is a thread from a year ago and that the PR is already
merged. S.Y. Lee's comment made me think this was a new thread. I probably
wouldn't have written this if I new this was old.

Jason
moorepants.info
+01 530-601-9791


On Sun, Jan 15, 2023 at 1:26 PM Jason Moore  wrote:

> 1 year seems too short from my perspective. As a downstream package
> maintainer, I release many packages less often than SymPy makes releases
> and keeping up with deprecations disappearing effectively each SymPy
> release would be stressful. I would advocate for at least 2 years, which
> equates to at least a couple of SymPy releases. Or even stating something
> like "deprecations can be removed if they've existed both for two years and
> two SymPy releases".
>
> I also think the current method of leaving the deprecations in
> indefinitely is fine and preferable. I don't think having a policy written
> in a way that encourages people to constantly look for deprecations that
> are just over the minimum time period to immediately remove them. They
> should really only be removed when they both reach the minimum AND are
> causing some issue with new code refactoring or designs.
>
> Jason
> moorepants.info
> +01 530-601-9791
>
>
> On Wed, Jan 26, 2022 at 10:38 PM Aaron Meurer  wrote:
>
>> We are currently in the process of revamping our deprecations policy
>> at https://github.com/sympy/sympy/pull/22900, and we would like any
>> feedback from the community, both users and developers. Our current
>> policy that this would replace is on the wiki
>> https://github.com/sympy/sympy/wiki/Deprecating-policy.
>>
>> In particular, the new policy would have
>>
>> 1. An official period of at least 1 year for all deprecations to last.
>> Previously there was no official period for deprecations, and
>> deprecated functionality was removed more or less whenever we felt
>> like it.
>>
>> 2. Deprecations will still raise a SymPyDeprecationWarning, but the
>> proposed policy is to make the warnings contain much more verbose and
>> helpful messages. In addition, all warnings will be documented in the
>> respective docstrings, listed in a separate "all active deprecations"
>> document in the docs, and listed in the release notes for each release
>> (currently only the last of these is done).
>>
>> 3. The current silly "deprecation removal issue" thing that we (tried)
>> to do will be removed. All documentation for deprecations will be in
>> the documentation.
>>
>> 4. I have added some text to the document going over when backwards
>> compatibility breaks should be made (tl;dr: sparingly), and what does
>> and doesn't require deprecation to change. The document also has
>> developer instructions on how to add a deprecation to the code.
>>
>> One question we have for users is if you are happy with our current
>> SymPyDeprecationWarnings, which are relatively loud by default (they
>> use a warnings filter that always turns them on). Would you prefer
>> more silent warnings, like warnings that are documented but aren't
>> accompanied by a warning printed to the screen?
>>
>> Aaron Meurer
>>
>> --
>> 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 discussion on the web visit
>> https://groups.google.com/d/msgid/sympy/CAKgW%3D6JkAa0jbEDKPHy7p6yVpjB8pBomcinV%3Dp-UdaBD_hiQhw%40mail.gmail.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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AiazYWp8ukqtafKVQmBMGewHGPt3%2B8fr%2BEdsgLUXKYJbQ%40mail.gmail.com.

Re: [sympy] Feedback requested on new deprecations policy

[Jason Moore]

1 year seems too short from my perspective. As a downstream package
maintainer, I release many packages less often than SymPy makes releases
and keeping up with deprecations disappearing effectively each SymPy
release would be stressful. I would advocate for at least 2 years, which
equates to at least a couple of SymPy releases. Or even stating something
like "deprecations can be removed if they've existed both for two years and
two SymPy releases".

I also think the current method of leaving the deprecations in indefinitely
is fine and preferable. I don't think having a policy written in a way that
encourages people to constantly look for deprecations that are just over
the minimum time period to immediately remove them. They should really only
be removed when they both reach the minimum AND are causing some issue with
new code refactoring or designs.

Jason
moorepants.info
+01 530-601-9791


On Wed, Jan 26, 2022 at 10:38 PM Aaron Meurer  wrote:

> We are currently in the process of revamping our deprecations policy
> at https://github.com/sympy/sympy/pull/22900, and we would like any
> feedback from the community, both users and developers. Our current
> policy that this would replace is on the wiki
> https://github.com/sympy/sympy/wiki/Deprecating-policy.
>
> In particular, the new policy would have
>
> 1. An official period of at least 1 year for all deprecations to last.
> Previously there was no official period for deprecations, and
> deprecated functionality was removed more or less whenever we felt
> like it.
>
> 2. Deprecations will still raise a SymPyDeprecationWarning, but the
> proposed policy is to make the warnings contain much more verbose and
> helpful messages. In addition, all warnings will be documented in the
> respective docstrings, listed in a separate "all active deprecations"
> document in the docs, and listed in the release notes for each release
> (currently only the last of these is done).
>
> 3. The current silly "deprecation removal issue" thing that we (tried)
> to do will be removed. All documentation for deprecations will be in
> the documentation.
>
> 4. I have added some text to the document going over when backwards
> compatibility breaks should be made (tl;dr: sparingly), and what does
> and doesn't require deprecation to change. The document also has
> developer instructions on how to add a deprecation to the code.
>
> One question we have for users is if you are happy with our current
> SymPyDeprecationWarnings, which are relatively loud by default (they
> use a warnings filter that always turns them on). Would you prefer
> more silent warnings, like warnings that are documented but aren't
> accompanied by a warning printed to the screen?
>
> Aaron Meurer
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAKgW%3D6JkAa0jbEDKPHy7p6yVpjB8pBomcinV%3Dp-UdaBD_hiQhw%40mail.gmail.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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Ag9BVr9nmzAYizmXRvhDK4tKdJqnkD4GA%3DPJgbBwtkeOw%40mail.gmail.com.

Re: [sympy] Contributing new SymPy benchmarks (comparative & non-time metrics)

[Jason Moore]

Hi Sam,

We used to have benchmarks (and maybe still do) in the main sympy repo, but
these were essentially never run. We were working on transferring them to
the sympy_benchmarks repo. The sympy_benchmarks repo was created and Bjorn,
Aaron, and I used to run that on every commit and publish the web output
using our own dedicated machines but I don't think that occurs anymore.
Oscar more recently connected it up to run on pairs of commits and output
those results to new PRs.

Benchmarks that can work with airspeed velocity should go in the
sympy_benchmarks repo. But your type 2 does fit nicely in the unit tests
and we have a handful of those in the main sympy repo. The key thing is
that they end up being run by CI and that people see them and hopefully
don't ignore regressions. If the tests fail due to unit tests then it can't
be ignored (having your type 2 in the main sympy repo). The airspeed
results in the PRs can more easily be ignored.

If it makes sense to add pytest-benchmark you can, but you'll have to get
the machinery running in CI. Note that I don't' think we actually use
pytest yet (still an old fork of it).

Jason
moorepants.info
+01 530-601-9791


On Wed, Sep 28, 2022 at 10:04 PM Sam Brockie  wrote:

> Hi All,
>
> I'd like to begin adding some additional benchmarks to SymPy to help
> inform the code generation work that I'm doing as part of the CZI grant.
>
> I'm aware of the benchmarks in the benchmarks repository
> . My understanding is that
> these are run using airspeed velocity as part of the CI, and track how the
> performance of a particular benchmark has changed relative to the most
> recent SymPy release and the master branch.
>
> There are two other types of benchmark that I think might be useful:
>
> *1. Comparison of multiple ways to do equivalent computations*
>
> Below is a contrived example in which there are two functions, option_1
>  and option_2, that produce the same result but have different
> implementations.
>
> >>> from sympy import Matrix, symbols
> >>>
> >>> def option_1(a, b):
> ... return Matrix([a+b, a*b]).jacobian(Matrix([a, b]))
> ...
> >>> def option_2(a, b):
> ... Matrix([[(a+b).diff(a), (a+b).diff(b)],
> ... [(a*b).diff(a), (a*b).diff(b)]])
> ...
> >>> a, b = symbols(“a, b”)
> >>> option_1(a, b) == option_2(a, b)
> True
>
> A benchmark in this case would time the execution of both option_1 and
> option_2 (for a range of inputs), compare the relative speeds, and report
> the differences. As this type of benchmark is not comparing the same
> benchmark across different SymPy versions, I believe that airspeed velocity
> may not be the best tool to use here.
>
> I see this type of benchmark as being useful for: (1) determining which
> algorithm to use when implementing a new function or refactoring an
> existing function; and (2) ensuring that an implementation remains superior
> to alternatives as changes are made elsewhere in SymPy.
>
> I have had success in the past implementing these sorts of benchmarks
> using pytest-benchmark
> . Is there currently
> anything similar anywhere is SymPy? Would the sympy/sympy_benchmarks
> repository be the best place to contribute PRs for these sorts of
> benchmarks? Does anyone have any differing opinions about how and where
> these should be implemented, or the value of this type of benchmark?
>
> *2. Measurement of non-time metrics*
>
> Below is another contrived example in which common subexpression
> elimination is used on an expression, y, and it is shown that the result
> of cse(y) involves fewer operations that the original expression.
>
> >>> from sympy import count_ops, cse, exp, sin, symbols
> >>>
> >>> a, b = symbols(“a, b”)
> >>> y = (sin(a/b) + (a/b) - exp(b)) * ((a/b) - exp(b))
> >>>
> >>> count_ops(y)
> 10
> >>> count_ops(cse(y))
> 6
>
> A benchmark in this case would count the number of operations in the
> return value from cse(y) and compare this to 6. Assuming that the
> implementation of the cse function has been changed, if the number of
> operations is six then we know that its performance hasn’t been changed by
> the refactor. If the count is greater than six a regression has taken
> place. If the count is less than six the performance of the function has
> been improved. Benchmarking for a range of inputs would obviously be
> required.
>
> I see this type of benchmark as being useful for: (1) measuring SymPy’s
> performance in instances where timing code snippets isn’t necessarily the
> best, or only valuable, indicator of performance; and (2) ensuring
> regressions haven’t occurred during refactoring.
>
> I believe this type of benchmark can be implemented using airspeed
> velocity’s track prefix. Or perhaps this type of benchmark would be best
> implemented as regression tests in the sympy/sympy repository’s test suite,
> comparing the non-time metrics to hard-coded values.
>
> As before, 

Re: [sympy] Just Joined SymPy Mailing List

[Jason Moore]

Hi Phil,

The quantum physics modules in SymPy have been without a maintainer for
some time. So we surely welcome anyone that would like to help work on it.

Welcome. Here is some intro information on contributing:
https://github.com/sympy/sympy/wiki/introduction-to-contributing

Jason
moorepants.info
+01 530-601-9791


On Tue, Sep 13, 2022 at 8:25 AM Phil L  wrote:

> Hello everyone,
>
> My name is Phil LeMaitre and I am a recent Master of Science in Physics
> graduate from the University of Waterloo in Canada, with 4+ years of
> experience using Python for scientific computing. My two largest projects
> consisted of developing a program to solve the relativistic hydrodynamic
> equations for a neutron star model and building an orbital-free density
> functional program from scratch to model neutral atoms. Of these two
> projects, it is the second one where I gained the most exposure to SymPy,
> using it mostly in a hybrid capacity for data visualization and extended
> precision calculations; although I did familiarize myself with many more
> features that I didn't end up using.
>
> My interests are almost exclusively physics related, so I tend to lean
> more towards functions and algorithms used in solving physical problems
> (e.g. SymPy physics module). My research experience is based mostly in
> quantum chemistry and polymer self-consistent field theory, as well as some
> general relativity. My research interests however, are at the intersection
> of quantum foundations, relativistic quantum information, and information
> geometry.
>
> I am eager to help contribute to SymPy and the rest of the Python
> ecosystem, as it has been a staple in my scientific career thus far, so I
> look forward to working with everyone.
>
> All the best,
>
> Phil
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/DM6PR05MB533815FBF5C44981D4086B1E8D479%40DM6PR05MB5338.namprd05.prod.outlook.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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Ai9Puz%3DeE7kQ0ZGj8oHSiJQdfTZcHkeoxEBHS9nzdgTMQ%40mail.gmail.com.

Re: [sympy] Sympy.physics.mechancis: RigidBody // inertia

[Jason Moore]

Peter,

You should be able to provide the inertia (I, P) about a point P other than
the mass center of the rigid body. So in your code "mass center" does not
have to equal "P". But, I never really do that so it could be that the
underlying code doesn't apply the parallel axis theorem correctly. It isn't
a feature that is likely used much, if at all. If you have an example that
shows it doesn't work, then providing that on the SymPy issue tracker would
be helpful so we can find and fix the bug.

Jason
moorepants.info
+01 530-601-9791


On Thu, Jun 23, 2022 at 1:44 PM Peter Stahlecker 
wrote:

> I = me.inertia(A, iXX….) gives the inertia in the (normally) body  - fixed
> frame A
> Body = Me.RigidBody( ‚Body‘, mass center, frame, mass, ( I, P))
>
> My question: Does RigidBody ‚assume‘, that mass center = P ?
>
> Reason behind my question:
>  For regular homogenious bodies, iXX, IYY, etc are often known relative to
> the geometric center of the body.
> If the mass center is not equal to the geometric center of the body, would
> RigidBody know, that the inertia is relative to the geometric center?
>
> In my program, the kinetic energy comes out right, if I set mass center =
> geometric center, but incorrect if I do not.
> Therefore, I wonder, whether there is a mistake in my program, or whether
> RigidBody assumes that P = mass center.
>
> Thanks a lot for any help!
>
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/0d3101eb-1fe7-4c24-a125-bab8c8a58145n%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Ag%2BpEFeUUs%3Duvn8V8enFmm4F6z9m4h6JEfRFXR-q0SEdg%40mail.gmail.com.

[sympy] CZI Grant Developer Hired: Dr. Sam Brockie

[Jason Moore]

SymPy community,

As many of you know, Oscar, Aaron, and I were awarded a 2 year CZI grant
that will fund Oscar, Aaron, and a postdoctoral researcher to complete the
objectives laid out in the proposal. We are happy to announce that we have
hired the postdoc. Dr. Sam Brockie 
will join TU Delft from September 2022 to September 2023 as a postdoc with
my research group. He'll work on improving code generation and
demonstrating the capabilities on advanced biomechanical modeling.

Sam did his PhD at Cambridge in the UK where he used SymPy to solve optimal
control problems related to bicycle racing. He most recently has been
working with the Great Britain Cycling Team as a staff scientist. Sam has
developed several packages that make use of SymPy, for example pycollo
, a tool for solving trajectory
optimization problems from SymPy model descriptions. We hope to incorporate
some of the software Sam wrote during his PhD work into SymPy.

Please welcome Sam and you'll start hearing more from him once he starts
the job in September.

Jason
moorepants.info
+01 530-601-9791

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Ah6%2BpnEJY6owv5rtiPR%3D5oNzu4dJ-yKA6Sn_a5QWWD%3DbQ%40mail.gmail.com.

Re: [sympy] My course book/reader/notes that uses SymPy (Mechanics)

[Jason Moore]

Arthur,

Thanks for having a look and your time to comment. If you file an issue on
the repo, that's easiest for me to keep track of but you can write me an
email too.

Jason
moorepants.info
+01 530-601-9791


On Tue, Jun 14, 2022 at 12:44 AM Arthur Ryman 
wrote:

> Jason,
>
> Your book looks very interesting. I like the combination of technologies
> you used to deliver the material. I've read the first few sections. I have
> some general comments. I also noticed the usual amount of typos. How would
> you like to receive feedback? Via your repo?
>
> -- Arthur
>
>
>
> On Fri, Jun 10, 2022 at 9:37 AM Jason Moore  wrote:
>
>> SymPy folks,
>>
>> I just finished the last chapter for my multibody dynamics course. It
>> teaches multibody dynamics using SymPy, NumPy, SciPy, matlplotlib,
>> pythreejs, and scikits.odes. You can find the HTML version here:
>>
>> https://moorepants.github.io/learn-multibody-dynamics/
>>
>> Once I get the PDF to build, I think it will amount to about 300 pages or
>> so. It is fairly complete and can mostly standalone.
>>
>> Right now, it is essentially a beta version for a 1.0 release, which I
>> hope to make over the summer. I also developed a set of 12 (mostly)
>> autograded computational homeworks for the course, which I may also release.
>>
>> These materials should give a complete picture of how to use
>> sympy.physics.vector and sympy.physics.mechanics (in addition to our
>> documentation of course).
>>
>> I taught about 150 students with the materials Feb till now and the
>> students seemed to take to tools and methods. Most of them didn't know any
>> Python when they started but had background in dynamics.
>>
>> I welcome any feedback and contributions. The repository is here:
>>
>> https://github.com/moorepants/learn-multibody-dynamics/
>>
>> It's very nice that I can build something like this on top of SymPy and
>> the SciPy ecosystem. Thanks!
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791
>>
>> --
>> 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 discussion on the web visit
>> https://groups.google.com/d/msgid/sympy/CAP7f1AjdO%3DQ4cY3d1h%3DtohsTW4m2RKmngGfZTyxXSuABFSfFLA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/sympy/CAP7f1AjdO%3DQ4cY3d1h%3DtohsTW4m2RKmngGfZTyxXSuABFSfFLA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAApBiOkxo4d44ig5JBkxGwTXrXv0wu6yN8j-M7p66n1MF-6ZDg%40mail.gmail.com
> <https://groups.google.com/d/msgid/sympy/CAApBiOkxo4d44ig5JBkxGwTXrXv0wu6yN8j-M7p66n1MF-6ZDg%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AhFqxCLr6dCsXCS2ry9B2kZppr2v5Cit6i2Pq2k11bHjQ%40mail.gmail.com.

[sympy] My course book/reader/notes that uses SymPy (Mechanics)

[Jason Moore]

SymPy folks,

I just finished the last chapter for my multibody dynamics course. It
teaches multibody dynamics using SymPy, NumPy, SciPy, matlplotlib,
pythreejs, and scikits.odes. You can find the HTML version here:

https://moorepants.github.io/learn-multibody-dynamics/

Once I get the PDF to build, I think it will amount to about 300 pages or
so. It is fairly complete and can mostly standalone.

Right now, it is essentially a beta version for a 1.0 release, which I hope
to make over the summer. I also developed a set of 12 (mostly) autograded
computational homeworks for the course, which I may also release.

These materials should give a complete picture of how to use
sympy.physics.vector and sympy.physics.mechanics (in addition to our
documentation of course).

I taught about 150 students with the materials Feb till now and the
students seemed to take to tools and methods. Most of them didn't know any
Python when they started but had background in dynamics.

I welcome any feedback and contributions. The repository is here:

https://github.com/moorepants/learn-multibody-dynamics/

It's very nice that I can build something like this on top of SymPy and the
SciPy ecosystem. Thanks!

Jason
moorepants.info
+01 530-601-9791

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AjdO%3DQ4cY3d1h%3DtohsTW4m2RKmngGfZTyxXSuABFSfFLA%40mail.gmail.com.

Re: [sympy] Re: SymPy documentation website down

[Jason Moore]

Aaron,

Thanks. That's surprisingly useless. They only say you violate copyright
but not what that violation exactly is.

I'm sorry you all are having to deal with this. If you need help with
anything let me know.

Jason
moorepants.info
+01 530-601-9791


On Wed, Apr 20, 2022 at 6:31 AM Aaron Meurer  wrote:

> Hi Jason.
>
> We were sent the same DMCA notice that is posted on GitHub's DMCA
> repo, which I linked to above.
>
> Aaron Meurer
>
> On Tue, Apr 19, 2022 at 10:23 PM Jason Moore  wrote:
> >
> > Aaron,
> >
> > Can you share the email you are sent that says precisely what the
> copyright violation is?
> >
> > Jason
> > moorepants.info
> > +01 530-601-9791
> >
> >
> > On Wed, Apr 20, 2022 at 4:57 AM Jeremy Monat 
> wrote:
> >>
> >> Oh, good news on HackerNews:
> >>
> >>> Hello again, Vivek, founder/CEO here. In the interest of moving
> swiftly, here are the actions we are going to take:
> >>>
> >>> (1) We have withdrawn the DMCA notice for sympy; Sent a note to senior
> leadership in Github to act on this quickly.
> >>>
> >>> (2) We have stopped the whole DMCA process for now and working on
> internal guidelines of what constitutes a real violation so that these kind
> of incidents don't happen. We are going to do this in-house
> >>>
> >>> (3) We are going to donate $25k to the sympy project.
> >>>
> >>> As a company we take a lot of pride in helping developers and it sucks
> to see this. I'm extremely sorry for what happened here.
> >>
> >>
> >> On Tue, Apr 19, 2022 at 10:54 PM Jeremy Monat 
> wrote:
> >>>
> >>> Hopefully this can get resolved soon! So is HackerRank's contention
> that one of the examples on our solvers page was taken from their site, for
> example one of their quizzes?
> >>>
> >>> Jeremy Monat
> >>>
> >>>
> >>> On Tue, Apr 19, 2022 at 10:50 PM oliphant 
> wrote:
> >>>>
> >>>> By the way, because I get to work with Aaron, I was chatting about
> this with him.  I saw the CEO post on Hacker News and I've reached out to
> him asking him to rescind the DMCA notice.   This is likely the fastest way
> to get the site back up -- though it will still take a couple of days, I
> suspect.
> >>>>
> >>>> I also suggested he make a donation to NumFOCUS to sponsor SymPy
> development for the trouble his vendor caused this community.
> >>>>
> >>>> Thanks for all of you who continue to make SymPy a very useful
> project.
> >>>>
> >>>> -Travis
> >>>>
> >>>>
> >>>> On Tuesday, April 19, 2022 at 4:48:54 PM UTC-5 Aaron Meurer wrote:
> >>>>>
> >>>>> Hi All.
> >>>>>
> >>>>> As some of you may have noticed, the SymPy documentation site is
> >>>>> currently down. This is due to a complaint that has been filed to
> >>>>> GitHub under the DMCA by HackerRank. You can read the complaint here
> >>>>>
> https://github.com/github/dmca/blob/5de8f80b171afdc3741c9ab9d4c32ea32c44e59c/2022/04/2022-04-15-hackerrank.md
> >>>>>
> >>>>> As a result of this complaint, GitHub has taken down our site. We are
> >>>>> looking into the claim and working on getting the site back up as
> soon
> >>>>> as possible.
> >>>>>
> >>>>> Aaron Meurer
> >>>>
> >>>> --
> >>>> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/d276c484-56c8-4f8d-b1a5-22fe15e04bb4n%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 sympy+unsubscr...@googlegroups.com.
> >> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAO00iLjLVg7oSs_HYYSx48GPO%2Btb-E11ufAG%3DF_1ZLbEhKuXkA%40mail.gmail.com
> .
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "sympy"

Re: [sympy] Re: SymPy documentation website down

[Jason Moore]

Aaron,

Can you share the email you are sent that says precisely what the copyright
violation is?

Jason
moorepants.info
+01 530-601-9791


On Wed, Apr 20, 2022 at 4:57 AM Jeremy Monat  wrote:

> Oh, good news on HackerNews
> :
>
> Hello again, Vivek, founder/CEO here. In the interest of moving swiftly,
>> here are the actions we are going to take:
>>
>> (1) We have withdrawn the DMCA notice for sympy; Sent a note to senior
>> leadership in Github to act on this quickly.
>>
>> (2) We have stopped the whole DMCA process for now and working on
>> internal guidelines of what constitutes a real violation so that these kind
>> of incidents don't happen. We are going to do this in-house
>>
>> (3) We are going to donate $25k to the sympy project.
>>
>> As a company we take a lot of pride in helping developers and it sucks to
>> see this. I'm extremely sorry for what happened here.
>>
>
> On Tue, Apr 19, 2022 at 10:54 PM Jeremy Monat  wrote:
>
>> Hopefully this can get resolved soon! So is HackerRank's contention that
>> one of the examples on our solvers page was taken from their site, for
>> example one of their quizzes?
>>
>> Jeremy Monat
>>
>>
>> On Tue, Apr 19, 2022 at 10:50 PM oliphant  wrote:
>>
>>> By the way, because I get to work with Aaron, I was chatting about this
>>> with him.  I saw the CEO post on Hacker News and I've reached out to him
>>> asking him to rescind the DMCA notice.   This is likely the fastest way to
>>> get the site back up -- though it will still take a couple of days, I
>>> suspect.
>>>
>>> I also suggested he make a donation to NumFOCUS to sponsor SymPy
>>> development for the trouble his vendor caused this community.
>>>
>>> Thanks for all of you who continue to make SymPy a very useful project.
>>>
>>> -Travis
>>>
>>>
>>> On Tuesday, April 19, 2022 at 4:48:54 PM UTC-5 Aaron Meurer wrote:
>>>
 Hi All.

 As some of you may have noticed, the SymPy documentation site is
 currently down. This is due to a complaint that has been filed to
 GitHub under the DMCA by HackerRank. You can read the complaint here

 https://github.com/github/dmca/blob/5de8f80b171afdc3741c9ab9d4c32ea32c44e59c/2022/04/2022-04-15-hackerrank.md

 As a result of this complaint, GitHub has taken down our site. We are
 looking into the claim and working on getting the site back up as soon
 as possible.

 Aaron Meurer

>>> --
>>> 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 discussion on the web visit
>>> https://groups.google.com/d/msgid/sympy/d276c484-56c8-4f8d-b1a5-22fe15e04bb4n%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 sympy+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAO00iLjLVg7oSs_HYYSx48GPO%2Btb-E11ufAG%3DF_1ZLbEhKuXkA%40mail.gmail.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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AhxJqgwPcEmt2K9fDi8cB%2BHWHcBcVUN5LopAx3%2BC8WF-Q%40mail.gmail.com.

Re: [sympy] New documentation theme merged

[Jason Moore]

Aaron,

Great work! This is a welcomed update.

Jason
moorepants.info
+01 530-601-9791


On Fri, Apr 8, 2022 at 12:28 AM Aaron Meurer  wrote:

> We have merged the new Furo Sphinx theme to the SymPy documentation.
> The theme is now live in the development documentation
> https://docs.sympy.org/dev/index.html, and will go live to the "latest
> version" documentation on the next SymPy release.
>
> Some notable differences in the new theme include:
>
> - A left sidebar with collapsible navigation for the top level pages.
> - A right sidebar that lists the headers on the current page.
> - Better mobile support, as well as good support for different browser
> sizes
> - Dark mode support (click the circle icon at the top of the page)
> - All colors in the documentation are now WCAG AA compatible, meaning
> the color contrast is much easier to read.
> - The SymPy Live sphinx extension has been removed. We would be
> interested in reintroducing something similar in the future that makes
> use of pyiodide, ideally via a community supported extension. If you
> are interested in this, please reach out.
>
> Please try it out and let us know if you encounter any issues.
> https://docs.sympy.org/dev/index.html
>
> Thank you to everyone who took part in our documentation theme survey
> we held earlier this year, and to everyone who helped make this
> happen, especially to Jeremy Monat who initiated the process of
> finding a new theme and who helped review my style updates to Furo.
> And thank you to Pradyun Gedam for making the excellent Furo theme and
> for helping us with various issues.
>
> Aaron Meurer
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAKgW%3D6KO_-FHUqdN7W6K5pk6JP8gPj5mTc8hZwHQde8aYKAj7A%40mail.gmail.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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AjtosynjiKFgjOuzL%2Bw2R2T2L1dUABHuAtB%2B1x%2B6cu0xg%40mail.gmail.com.

Re: [sympy] Classical Mechanics: Efficient Equation of Motion Generation with Python GSoC Project

[Jason Moore]

Arnav,

The technical implementation of those two classes are in the sympy
documentation and are the source code itself. There is no other information
that explains them.

Jason
moorepants.info
+01 530-601-9791


On Wed, Apr 6, 2022 at 10:36 AM Arnav Zutshi  wrote:

> Hi SymPy Community
>
> This is with reference to the project in the GSoC idea list 2022 *Classical
> Mechanics: Efficient Equation of Motion Generation with Python*.
> The project involves cleaning up the code base and profiling to find the
> slow functions, and digging into the SymPy code base for trigonometric
> simplification and other relevant function calls to speed up the EoM
> generation.
>
> I am familiar with the theoretical part of this project but* require a
> more know how on the technical side of the LagrangesMethod() and
> KanesMethod()* function calls. *I have referred the SymPy docs* on these
> 2 methods but some aspects in the code seem a little unclear to me.
>
> *It would be kind if the mentors could guide me on where to refer for
> understanding the implementation.*
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/0a41e4b1-67be-444e-af9f-a441bc0652d7n%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AicNGrxaKzy6yPFhdU1ZrVi_RkOKVyFtcet72dTPyjZPQ%40mail.gmail.com.

Re: [sympy] Re: Classical Mechanics : Forces and Torques

[Jason Moore]

Praneeth,

We volunteer our time and will reply when and if we can.

Your list of forces looks interesting and useful. I recommend reading the
force related sections of Kane & Levinson 1985, as those would be obvious
places to take forces ideas from. I'm currently writing a force chapter in
my book that has some examples (these are still in draft form and likely
incorrect): https://github.com/moorepants/learn-multibody-dynamics/pull/57

There should be no need for a system or anything from pydy. We need valid
mathematical descriptions of a variety of common forces that will work
nicely with our code generators for efficient numerical implementations.

Jason
moorepants.info
+01 530-601-9791


On Tue, Apr 5, 2022 at 3:48 PM praneeth ratna 
wrote:

> Hi jason,
>
> Could you please provide your feedback on my previous two emails, So that
> I can start writing my proposal and since there isn't much time left for
> proposal deadline.
>
> Thanks,
> Praneeth
>
> On Monday, April 4, 2022 at 11:38:48 AM UTC+5:30 praneeth ratna wrote:
>
>> Jason,
>>
>> Regarding the implementation, do you suggest similar to pydy engine? So
>> we also need to  create a System
>> <https://pydy.readthedocs.io/en/stable/system.html> class similar to the
>> one pydy has? Also could you suggest any sources for some trivial cases of
>> muscle force, actuator force and aerodynamic force models, could you
>> provide feedback on whether the model specified in my previous mail are
>> useful or not, so that i can include them in my proposal.
>>
>> Thanks,
>> Praneeth
>> On Monday, March 28, 2022 at 4:22:26 PM UTC+5:30 praneeth ratna wrote:
>>
>>> Hi jason,
>>>
>>> I have at present written down the following models:
>>>
>>>1. Linear hooke contact model
>>>2. Non linear hertz model
>>>3. Linear Kelvin-Voigt Contact Model
>>>4. Nonlinear Hunt and Crossley Contact Model
>>>5. Nonlinear Hunt and Crossley Contact Model
>>>6. Nonlinear Flores et al. Contact Model
>>>7. multi_mass_spring_damper()
>>>
>>> <https://pydy.readthedocs.io/en/stable/models.html#pydy.models.multi_mass_spring_damper>
>>>8. n_link_pendulum_on_cart()
>>>
>>> <https://pydy.readthedocs.io/en/stable/models.html#pydy.models.n_link_pendulum_on_cart>
>>>
>>> 7 and 8 are taken from pydy, are they non trivial cases? Also could you
>>> suggest any resources for muscle force, actuator force and aerodynamic
>>> force models which are useful for the user?
>>> I have taken 1 to 6 from the here
>>> https://www.researchgate.net/publication/299604992_Contact_Force_Models_for_Multibody_Dynamics,
>>> are they useful cases?
>>>
>>> Thanks,
>>> Praneeth
>>>
>>> On Saturday, March 26, 2022 at 1:08:09 PM UTC+5:30 moore...@gmail.com
>>> wrote:
>>>
>>>> Praneeth,
>>>>
>>>> Yes we should have a linear spring and damper force that is premade,
>>>> but that is really just a trivial case. The GSoC project should be focused
>>>> primarily on adding non-trivial forces.
>>>>
>>>> Jason
>>>> moorepants.info
>>>> +01 530-601-9791 <(530)%20601-9791>
>>>>
>>>>
>>>> On Sat, Mar 26, 2022 at 7:29 AM praneeth ratna 
>>>> wrote:
>>>>
>>>>> Hi jason,
>>>>>
>>>>> I have gone through the examples of pydy and your courses that you
>>>>> have mentioned. For example: Here
>>>>> https://pydy.readthedocs.io/en/stable/examples/mass-spring-damper.html,
>>>>> the plan is to implement the same thing in a class so that user can call
>>>>> the linear spring damper object whenever it is required and use numerical
>>>>> methods that can operate on force objects, is it the right thing? Also is
>>>>> there any priority for forces that should be implemented first since there
>>>>> many kinds of forces to be implemented.
>>>>>
>>>>> Thanks,
>>>>> Praneeth
>>>>>
>>>>> On Friday, March 25, 2022 at 3:45:55 PM UTC+5:30 moore...@gmail.com
>>>>> wrote:
>>>>>
>>>>>> Praneeth,
>>>>>>
>>>>>> Checking out examples in pydy, sympy, and my various courses (MAE
>>>>>> 223, ENG122, ME41055) are also good locations.
>>>>>>
>>>>>>
>>>>>> Jason
>

Re: [sympy] Re: Physics : Improving Control Module GSOC'22

[Jason Moore]

Anurag,

My general advice is to fix what is there, make it robust (by demonstrating
on a large set of example problems), and document it extensively instead of
adding new features. To gain users, it is better to have a small number of
features that work really well over a larger number of features and a
buggy, ill-documented package. The only way to find out if the package is
useful is to solve controls problems with it. The more problems you solve
with it, the more deficiencies and bugs appear.

Jason
moorepants.info
+01 530-601-9791


On Mon, Apr 4, 2022 at 9:26 AM Anurag Surendra Bhat (B20CS097) <
bha...@iitj.ac.in> wrote:

> Dear Jason,
>
> I would request you and other mentors / maintainers of the physics module
> to have a look into it . I would be glad to have your reviews and
> suggestions.
>
> Thanking You,
> Anurag Bhat .
>
> On Monday, April 4, 2022 at 12:52:25 PM UTC+5:30 Anurag Surendra Bhat
> (B20CS097) wrote:
>
>> Hello SymPy community,
>> As I had mailed a few days ago that I have started to draft a proposal to
>> improve and expand the control module in SymPy . You can go through this
>> discussion for the ideas (
>> https://groups.google.com/u/1/g/sympy/c/WpODTnY7Fh8 ).
>> I have completed it upto a good extent, so I thought I should be sharing
>> it . The proposal needs work in the phase 4 part and some fine tuning in
>> content / dates / references .I will be making the ideas more concrete so
>> that I can cement the proposal soon. I have added the proposal here -
>> GSoC 2022 Current Applications · sympy/sympy Wiki (github.com)
>>  .
>> For easy access to mailing list members here is a link to my proposal -
>> SymPy GSOC'22 Proposal - Google Docs
>> 
>> I have provided comment access to everyone so that the community can
>> react to my proposal and give reviews / suggestions .
>>
>> Regards,
>> Anurag Bhat
>>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/4acee36c-2f8b-4814-9a57-a0b7fb818324n%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Ai_2uvVyioC3KyLtHS2E9F0uK7Cw94z5wXJeCV6rw8oxw%40mail.gmail.com.

Re: [sympy] Re: Classical Mechanics : Forces and Torques

[Jason Moore]

Praneeth,

Yes we should have a linear spring and damper force that is premade, but
that is really just a trivial case. The GSoC project should be focused
primarily on adding non-trivial forces.

Jason
moorepants.info
+01 530-601-9791


On Sat, Mar 26, 2022 at 7:29 AM praneeth ratna 
wrote:

> Hi jason,
>
> I have gone through the examples of pydy and your courses that you have
> mentioned. For example: Here
> https://pydy.readthedocs.io/en/stable/examples/mass-spring-damper.html,
> the plan is to implement the same thing in a class so that user can call
> the linear spring damper object whenever it is required and use numerical
> methods that can operate on force objects, is it the right thing? Also is
> there any priority for forces that should be implemented first since there
> many kinds of forces to be implemented.
>
> Thanks,
> Praneeth
>
> On Friday, March 25, 2022 at 3:45:55 PM UTC+5:30 moore...@gmail.com wrote:
>
>> Praneeth,
>>
>> Checking out examples in pydy, sympy, and my various courses (MAE 223,
>> ENG122, ME41055) are also good locations.
>>
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791 <(530)%20601-9791>
>>
>>
>> On Fri, Mar 25, 2022 at 9:00 AM Jason Moore  wrote:
>>
>>> Hi Praneeth,
>>>
>>> I recommend looking at force types in various physics engines to get
>>> ideas. The rest would really come from academic papers and text books.
>>>
>>> Jason
>>> moorepants.info
>>> +01 530-601-9791 <(530)%20601-9791>
>>>
>>>
>>> On Wed, Mar 23, 2022 at 5:31 AM praneeth ratna 
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I have already posted regarding my interest in the idea *Implementing
>>>> Specific Forces and Torque objects *but have not recieved any reply
>>>> yet,Could the potential mentor please guide me on what has to be done in
>>>> this project and some resources, so that I can start working on my proposal
>>>> since there isn't much time left.
>>>>
>>>> Thanks,
>>>> Praneeth
>>>>
>>>> On Friday, March 18, 2022 at 12:29:04 AM UTC+5:30 praneeth ratna wrote:
>>>>
>>>>> Hey!
>>>>>
>>>>> While going through the GSOC 2022 ideas I have come across the idea of
>>>>> Implementing Specific Forces and Torque objects which i found interesting.
>>>>> There are many possible examples mentioned by Jason K. Moore. And I'm able
>>>>> to find a resource for contact force models :
>>>>> https://www.researchgate.net/publication/299604992_Contact_Force_Models_for_Multibody_Dynamics
>>>>> which i found useful. Are there any resources for the examples mentioned 
>>>>> in
>>>>> issue which can helpful for understanding the implementation of concept
>>>>> other than contact force models?
>>>>>
>>>>> I'm thinking of adding different classes for different type of force
>>>>> models and torques and that can be used to create a force object or torque
>>>>> object of that type also numerical methods can be added to individual
>>>>> classes.
>>>>>
>>>>> I would request Jason K. Moore to guide me on how to move forward in
>>>>> this project, regarding the implementation and about what all kinds of
>>>>> forces and torques should be implemented so that i can start working on my
>>>>> proposal.
>>>>>
>>>>> Thanks,
>>>>> Praneeth
>>>>>
>>>>>
>>>>> --
>>>> 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/f010d4bf-5986-4ac2-946f-0d306697a36cn%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/sympy/f010d4bf-5986-4ac2-946f-0d306697a36cn%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/d61600ae-f566-44c5-9548-ef79b5e2c423n%40googlegroups.com
> <https://groups.google.com/d/msgid/sympy/d61600ae-f566-44c5-9548-ef79b5e2c423n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AiYJmCBk7b5U%2BrNb7WPYd7U1%2BThbJqQ_We6Uczf4d77YA%40mail.gmail.com.

Re: [sympy] Results of the SymPy Documentation Theme Survey

[Jason Moore]

> All three of these just build on top of Furo in supported ways.

Great. I just guessed wrongly, thinking the changes you were making were
not supported.

Jason
moorepants.info
+01 530-601-9791


On Fri, Mar 25, 2022 at 9:31 PM Aaron Meurer  wrote:

> I'm not sure I'm following you exactly. We are not forking Furo. My
> pull request only does three things:
>
> - Modifies some of the CSS variables provided by Furo (the changes in
> conf.py).
> - Adds a custom.css to make some more complicated changes which Furo
> does not provide as CSS variables (e.g., tweaking the size of the
> "examples" headers).
> - Adding a versions.html to the sidebar, with some custom Javascript
> to make the "latest" and "dev" versions links (see
> https://pradyunsg.me/furo/customisation/sidebar/).
>
> All three of these just build on top of Furo in supported ways.
>
> The only possible concern is that while the custom.css modifications
> are supported, they are considered "unstable" (see
> https://pradyunsg.me/furo/customisation/injecting/). That means they
> could break if a future version of Furo changes how the classes in the
> HTML are laid out. If this is a concern we can pin the Furo version
> (also recommended by the Furo docs, see
> https://pradyunsg.me/furo/stability/). However, if this happens we can
> also just fix the CSS for the newer version.
>
> Are you asking if we can turn our modifications into an actual Sphinx
> theme, so that it is maintained separately from the repo? I believe
> this is possible, although I'm not really sure what benefit it would
> bring. At present the Sphinx docs site is the only site that uses this
> theme, so there would be no reuse. If we ever had another SymPy
> project that wanted to reuse the same theme with the same styling, it
> might make sense to do this. For projects that are not directly part
> of the SymPy organization I would prefer if they don't use the same
> styling, so that the "SymPy green" branding stays unique to the SymPy
> documentation.
>
> Aaron Meurer
>
> On Fri, Mar 25, 2022 at 1:59 AM Jason Moore  wrote:
> >
> > Can you make a sphinx theme be a child of a parent theme, such that we
> can easily update furo without having to fork and customize furo? If all we
> are doing is css overrides, I suspect that is possible.
> >
> > Jason
> > moorepants.info
> > +01 530-601-9791
> >
> >
> > On Thu, Mar 24, 2022 at 3:24 PM Nicolas Guarin 
> wrote:
> >>
> >> I agree that the demo site is looking great. Although, I think that
> sharing a theme with other projects might be something desirable.
> >>
> >> On Tuesday, March 22, 2022 at 3:46:02 PM UTC-5 moore...@gmail.com
> wrote:
> >>>
> >>> Aaron,
> >>>
> >>> I browsed around the demo site. It is looking quite nice! Great job.
> >>>
> >>> Jason
> >>> moorepants.info
> >>> +01 530-601-9791
> >>>
> >>>
> >>> On Tue, Mar 22, 2022 at 8:59 PM Aaron Meurer 
> wrote:
> >>>>
> >>>> An update on this: the Furo theme pull request is now ready for a
> >>>> final review. The demo site is at
> >>>> https://www.asmeurer.com/sympy-furo-demo/dev/index.html. I've done
> >>>> several modifications to the base Furo theme, mostly changing colors
> >>>> and a few small font tweaks, so please let me know if you see anything
> >>>> that should be improved style-wise. If you can, please also test the
> >>>> dark mode (click the sun icon at the top), and on mobile, and try to
> >>>> look at different types of documentation pages. If something looks
> >>>> off, there's a good chance I messed up the CSS for it somehow or just
> >>>> didn't notice it, so please let me know.
> >>>>
> >>>> The pull request is https://github.com/sympy/sympy/pull/23159/. Also
> >>>> if any frontend experts can critique my terrible CSS/Javascript
> >>>> skills, that would be helpful.
> >>>>
> >>>> Note that this does remove the SymPy Live extension from the
> >>>> documentation, as it's not compatible with Furo. If we can get a
> >>>> similar extension implemented that uses pyiodide, preferably one that
> >>>> is maintained by the broader community, that would be great.
> >>>>
> >>>> Aaron Meurer
> >>>>
> >>>> On Tue, Mar 1, 2022 at 11:37 AM Chris Smith  wrote:
> >>>> >
> >>>> > For anyon

Re: [sympy] Release 0.9.1 of Algebra-with-Sympy package...

[Jason Moore]

Jonathan,

Ok, that's clear. Thanks. A sympep probably is the best bet then.

Jason
moorepants.info
+01 530-601-9791


On Fri, Mar 25, 2022 at 1:22 PM gu...@uwosh.edu  wrote:

> Jason,
>
> The reason for the SymPEP is that the PR's for this functionality
> engendered a lot of discussion, with no final resolution. Part of the issue
> is that the functionality does require making some of the base classes
> (e.g. `class Function()`) equation aware. I do that in my package by
> extending the function class and then rerunning the `class funcX()`
> statements for all functions in `function._all_`. This is a bit sketchy,
> but works. Additionally, there is disagreement on how some of the calculus
> operations should behave.
>
> Anyway, I would be happy to get this functionality into sympy proper, but
> the community needs to come to a consensus on what functionality to include
> and how. I have not yet been able to generate that consensus.
>
> Thanks for the encouragement.
>
> Jonathan
>
> On Friday, March 25, 2022 at 2:58:05 AM UTC-5 moore...@gmail.com wrote:
>
>> Jonathan,
>>
>> I am not up-to-date on the discussions about contributing this to sympy,
>> but why is there a sympep? If you are proposing adding a new module that
>> solves equations, it seems that would only require a pull request and
>> discussion there to refine.
>>
>> If you are, on the other hand, planning to change core functionality in
>> sympy, then I can see the need for a sympep.
>>
>> I'm only mentioning this to suggest that going for a PR would likely be a
>> faster track to getting this great functionality into sympy.
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791 <(530)%20601-9791>
>>
>>
>> On Fri, Mar 25, 2022 at 1:42 AM gu...@uwosh.edu  wrote:
>>
>>> I would like to make everyone aware of an update to the
>>> Algebra-with-Sympy 
>>> package. This is a working implementation of algebraic manipulation of
>>> equations with the relational operator "=". This implements a superset of
>>> the functionality proposed in this PR21333
>>>  and this SymPEP
>>> .
>>>
>>> Updates since the last release include:
>>>
>>>- Equations labeled with their python name, if they have one.
>>>- Added flags to adjust human readable output and equation labeling.
>>>- Accept equation as function argument in any position.
>>>- First pass at solve() accepting equations.
>>>- Added override of root() to avoid warning messages.
>>>- More unit tests.
>>>- First pass at documentation.
>>>
>>> Hope people find this useful. I have primarily been using it for
>>> producing answer keys for physical chemistry classes and for development of
>>> expressions for data analysis.
>>>
>>> Regards,
>>> Jonathan
>>>
>>> --
>>> 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/cfb0a4b9-eb74-427c-82f0-ef320784cee5n%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 sympy+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/7aabb854-b06f-4e10-8653-1c0f2d1e35fcn%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Aj0cYOboi%3Dgd0YA3bYvVTjacoqg6qde6AkAzXB-%3DF2s_A%40mail.gmail.com.

Re: [sympy] Re: Classical Mechanics : Forces and Torques

[Jason Moore]

Peter,

Yes a force is a force and a torque is a torque, but there are specific
mathematical descriptions of specific forces and torques. For example, what
is the mathematical (analytic and computational) representation of two
forces that contact each other. There are many models of contact forces and
if we provide popular implementations in sympy mechanics, then it will save
users time on defining these from scratch (which can be very tedious).
Newton's law of gravitation is another simple force that we could encode or
even a simple spring (or a complex nonlinear spring).

Jason
moorepants.info
+01 530-601-9791


On Fri, Mar 25, 2022 at 9:59 AM Peter Stahlecker 
wrote:

> Stupid question from me:
> I thought a force was a force and a torque was a torque.
> Are there differentforces?
>
> On Fri 25. Mar 2022 at 14:01 Jason Moore  wrote:
>
>> Hi Praneeth,
>>
>> I recommend looking at force types in various physics engines to get
>> ideas. The rest would really come from academic papers and text books.
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791
>>
>>
>> On Wed, Mar 23, 2022 at 5:31 AM praneeth ratna 
>> wrote:
>>
>>> Hi all,
>>>
>>> I have already posted regarding my interest in the idea *Implementing
>>> Specific Forces and Torque objects *but have not recieved any reply
>>> yet,Could the potential mentor please guide me on what has to be done in
>>> this project and some resources, so that I can start working on my proposal
>>> since there isn't much time left.
>>>
>>> Thanks,
>>> Praneeth
>>>
>>> On Friday, March 18, 2022 at 12:29:04 AM UTC+5:30 praneeth ratna wrote:
>>>
>>>> Hey!
>>>>
>>>> While going through the GSOC 2022 ideas I have come across the idea of
>>>> Implementing Specific Forces and Torque objects which i found interesting.
>>>> There are many possible examples mentioned by Jason K. Moore. And I'm able
>>>> to find a resource for contact force models :
>>>> https://www.researchgate.net/publication/299604992_Contact_Force_Models_for_Multibody_Dynamics
>>>> which i found useful. Are there any resources for the examples mentioned in
>>>> issue which can helpful for understanding the implementation of concept
>>>> other than contact force models?
>>>>
>>>> I'm thinking of adding different classes for different type of force
>>>> models and torques and that can be used to create a force object or torque
>>>> object of that type also numerical methods can be added to individual
>>>> classes.
>>>>
>>>> I would request Jason K. Moore to guide me on how to move forward in
>>>> this project, regarding the implementation and about what all kinds of
>>>> forces and torques should be implemented so that i can start working on my
>>>> proposal.
>>>>
>>>> Thanks,
>>>> Praneeth
>>>>
>>>>
>>>> --
>>> 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 discussion on the web visit
>>> https://groups.google.com/d/msgid/sympy/f010d4bf-5986-4ac2-946f-0d306697a36cn%40googlegroups.com
>>> <https://groups.google.com/d/msgid/sympy/f010d4bf-5986-4ac2-946f-0d306697a36cn%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> 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 discussion on the web visit
>> https://groups.google.com/d/msgid/sympy/CAP7f1Aj%3DkaK5_W4L_%2BKn3%2BfNvhhP6iErshJ4kRVeryPP1Fb8fg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/sympy/CAP7f1Aj%3DkaK5_W4L_%2BKn3%2BfNvhhP6iErshJ4kRVeryPP1Fb8fg%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> Best regards,
>
> Peter Stahlecker
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CABKqA0YXofGvjm%3DJgN19GR%2B_emS_iRvhCWbisQXJ6KE3VENQug%40mail.gmail.com
> <https://groups.google.com/d/msgid/sympy/CABKqA0YXofGvjm%3DJgN19GR%2B_emS_iRvhCWbisQXJ6KE3VENQug%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AhR-3bxKnSiw4obTW8ZH9MvG2cmM6nc3_0a1gEu7cu-qg%40mail.gmail.com.

Re: [sympy] Re: Classical Mechanics : Forces and Torques

[Jason Moore]

Praneeth,

Checking out examples in pydy, sympy, and my various courses (MAE 223,
ENG122, ME41055) are also good locations.


Jason
moorepants.info
+01 530-601-9791


On Fri, Mar 25, 2022 at 9:00 AM Jason Moore  wrote:

> Hi Praneeth,
>
> I recommend looking at force types in various physics engines to get
> ideas. The rest would really come from academic papers and text books.
>
> Jason
> moorepants.info
> +01 530-601-9791
>
>
> On Wed, Mar 23, 2022 at 5:31 AM praneeth ratna 
> wrote:
>
>> Hi all,
>>
>> I have already posted regarding my interest in the idea *Implementing
>> Specific Forces and Torque objects *but have not recieved any reply
>> yet,Could the potential mentor please guide me on what has to be done in
>> this project and some resources, so that I can start working on my proposal
>> since there isn't much time left.
>>
>> Thanks,
>> Praneeth
>>
>> On Friday, March 18, 2022 at 12:29:04 AM UTC+5:30 praneeth ratna wrote:
>>
>>> Hey!
>>>
>>> While going through the GSOC 2022 ideas I have come across the idea of
>>> Implementing Specific Forces and Torque objects which i found interesting.
>>> There are many possible examples mentioned by Jason K. Moore. And I'm able
>>> to find a resource for contact force models :
>>> https://www.researchgate.net/publication/299604992_Contact_Force_Models_for_Multibody_Dynamics
>>> which i found useful. Are there any resources for the examples mentioned in
>>> issue which can helpful for understanding the implementation of concept
>>> other than contact force models?
>>>
>>> I'm thinking of adding different classes for different type of force
>>> models and torques and that can be used to create a force object or torque
>>> object of that type also numerical methods can be added to individual
>>> classes.
>>>
>>> I would request Jason K. Moore to guide me on how to move forward in
>>> this project, regarding the implementation and about what all kinds of
>>> forces and torques should be implemented so that i can start working on my
>>> proposal.
>>>
>>> Thanks,
>>> Praneeth
>>>
>>>
>>> --
>> 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 discussion on the web visit
>> https://groups.google.com/d/msgid/sympy/f010d4bf-5986-4ac2-946f-0d306697a36cn%40googlegroups.com
>> <https://groups.google.com/d/msgid/sympy/f010d4bf-5986-4ac2-946f-0d306697a36cn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AiomY%2BT%2ByEAEth_-%3DtqeHQHSd_L3Q1-qmMoi6njFEcqXA%40mail.gmail.com.

Re: [sympy] Re: Classical Mechanics : Forces and Torques

[Jason Moore]

Hi Praneeth,

I recommend looking at force types in various physics engines to get ideas.
The rest would really come from academic papers and text books.

Jason
moorepants.info
+01 530-601-9791


On Wed, Mar 23, 2022 at 5:31 AM praneeth ratna 
wrote:

> Hi all,
>
> I have already posted regarding my interest in the idea *Implementing
> Specific Forces and Torque objects *but have not recieved any reply
> yet,Could the potential mentor please guide me on what has to be done in
> this project and some resources, so that I can start working on my proposal
> since there isn't much time left.
>
> Thanks,
> Praneeth
>
> On Friday, March 18, 2022 at 12:29:04 AM UTC+5:30 praneeth ratna wrote:
>
>> Hey!
>>
>> While going through the GSOC 2022 ideas I have come across the idea of
>> Implementing Specific Forces and Torque objects which i found interesting.
>> There are many possible examples mentioned by Jason K. Moore. And I'm able
>> to find a resource for contact force models :
>> https://www.researchgate.net/publication/299604992_Contact_Force_Models_for_Multibody_Dynamics
>> which i found useful. Are there any resources for the examples mentioned in
>> issue which can helpful for understanding the implementation of concept
>> other than contact force models?
>>
>> I'm thinking of adding different classes for different type of force
>> models and torques and that can be used to create a force object or torque
>> object of that type also numerical methods can be added to individual
>> classes.
>>
>> I would request Jason K. Moore to guide me on how to move forward in this
>> project, regarding the implementation and about what all kinds of forces
>> and torques should be implemented so that i can start working on my
>> proposal.
>>
>> Thanks,
>> Praneeth
>>
>>
>> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/f010d4bf-5986-4ac2-946f-0d306697a36cn%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Aj%3DkaK5_W4L_%2BKn3%2BfNvhhP6iErshJ4kRVeryPP1Fb8fg%40mail.gmail.com.

Re: [sympy] Results of the SymPy Documentation Theme Survey

[Jason Moore]

Can you make a sphinx theme be a child of a parent theme, such that we can
easily update furo without having to fork and customize furo? If all we are
doing is css overrides, I suspect that is possible.

Jason
moorepants.info
+01 530-601-9791


On Thu, Mar 24, 2022 at 3:24 PM Nicolas Guarin  wrote:

> I agree that the demo site is looking great. Although, I think that
> sharing a theme with other projects might be something desirable.
>
> On Tuesday, March 22, 2022 at 3:46:02 PM UTC-5 moore...@gmail.com wrote:
>
>> Aaron,
>>
>> I browsed around the demo site. It is looking quite nice! Great job.
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791 <(530)%20601-9791>
>>
>>
>> On Tue, Mar 22, 2022 at 8:59 PM Aaron Meurer  wrote:
>>
>>> An update on this: the Furo theme pull request is now ready for a
>>> final review. The demo site is at
>>> https://www.asmeurer.com/sympy-furo-demo/dev/index.html. I've done
>>> several modifications to the base Furo theme, mostly changing colors
>>> and a few small font tweaks, so please let me know if you see anything
>>> that should be improved style-wise. If you can, please also test the
>>> dark mode (click the sun icon at the top), and on mobile, and try to
>>> look at different types of documentation pages. If something looks
>>> off, there's a good chance I messed up the CSS for it somehow or just
>>> didn't notice it, so please let me know.
>>>
>>> The pull request is https://github.com/sympy/sympy/pull/23159/. Also
>>> if any frontend experts can critique my terrible CSS/Javascript
>>> skills, that would be helpful.
>>>
>>> Note that this does remove the SymPy Live extension from the
>>> documentation, as it's not compatible with Furo. If we can get a
>>> similar extension implemented that uses pyiodide, preferably one that
>>> is maintained by the broader community, that would be great.
>>>
>>> Aaron Meurer
>>>
>>> On Tue, Mar 1, 2022 at 11:37 AM Chris Smith  wrote:
>>> >
>>> > For anyone else not familiar yet with the "bus factor", I learned from
>>> wikipedia that "The bus factor is a measurement of the risk resulting from
>>> information and capabilities not being shared among team members, derived
>>> from the phrase "in case they get hit by a bus."
>>> >
>>> > /c
>>> > On Tuesday, March 1, 2022 at 2:49:12 AM UTC-6 moore...@gmail.com
>>> wrote:
>>> >>
>>> >> Furo looks good. If you think the bus factor is not a big deal,
>>> that's fine then. It's not as important as an actual dependency of sympy.
>>> >>
>>> >> > The decision to use Furo isn't completely final yet. So if you want
>>> to make the case for one of the other themes, you still can.
>>> >>
>>> >> My vote in the survey was RTD. I explained it in the survey my
>>> reasoning. But that's all I have to offer for the case.
>>> >>
>>> >> Jason
>>> >> moorepants.info
>>> >> +01 530-601-9791 <(530)%20601-9791>
>>> >>
>>> >>
>>> >> On Tue, Mar 1, 2022 at 12:50 AM Aaron Meurer 
>>> wrote:
>>> >>>
>>> >>> On Sat, Feb 26, 2022 at 1:11 AM Jason Moore 
>>> wrote:
>>> >>> >
>>> >>> > Thanks for doing this! I read through all the comments.
>>> >>> >
>>> >>> > Couple of points:
>>> >>> >
>>> >>> > - With 22 respondents and large standard deviation, the numbers
>>> don't really mean anything. Basically all themes are rated the same.
>>> >>> > - The written comments are most useful and I get the impression
>>> that almost any of the themes could work, but each requires some tweaking
>>> to fit for SymPy.
>>> >>> >
>>> >>> > I would recommend choosing based on which theme has the most
>>> configuration options and energy behind it because we want to easily tweak
>>> things and we automatically benefit from upstream improvements. If we do
>>> pydata, we join with our counterparts Numpy, scipy, pandas, etc. and it
>>> keeps us connected nicely to that community and when people jump around the
>>> scipy ecosystem docs they get the same (or similar) experience. RTD theme,
>>> by far, is the most used because it is the default theme on their service
>>> and there is 

Re: [sympy] Release 0.9.1 of Algebra-with-Sympy package...

[Jason Moore]

Jonathan,

I am not up-to-date on the discussions about contributing this to sympy,
but why is there a sympep? If you are proposing adding a new module that
solves equations, it seems that would only require a pull request and
discussion there to refine.

If you are, on the other hand, planning to change core functionality in
sympy, then I can see the need for a sympep.

I'm only mentioning this to suggest that going for a PR would likely be a
faster track to getting this great functionality into sympy.

Jason
moorepants.info
+01 530-601-9791


On Fri, Mar 25, 2022 at 1:42 AM gu...@uwosh.edu  wrote:

> I would like to make everyone aware of an update to the Algebra-with-Sympy
>  package. This is a working
> implementation of algebraic manipulation of equations with the relational
> operator "=". This implements a superset of the functionality proposed in
> this PR21333  and this SymPEP
> .
>
> Updates since the last release include:
>
>- Equations labeled with their python name, if they have one.
>- Added flags to adjust human readable output and equation labeling.
>- Accept equation as function argument in any position.
>- First pass at solve() accepting equations.
>- Added override of root() to avoid warning messages.
>- More unit tests.
>- First pass at documentation.
>
> Hope people find this useful. I have primarily been using it for producing
> answer keys for physical chemistry classes and for development of
> expressions for data analysis.
>
> Regards,
> Jonathan
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/cfb0a4b9-eb74-427c-82f0-ef320784cee5n%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AhWFOpH65eo8wC6kwfkrfo8exPBD3BEo%3DZ_EBRKc%2Bbd1Q%40mail.gmail.com.

Re: [sympy] Results of the SymPy Documentation Theme Survey

[Jason Moore]

Aaron,

I browsed around the demo site. It is looking quite nice! Great job.

Jason
moorepants.info
+01 530-601-9791


On Tue, Mar 22, 2022 at 8:59 PM Aaron Meurer  wrote:

> An update on this: the Furo theme pull request is now ready for a
> final review. The demo site is at
> https://www.asmeurer.com/sympy-furo-demo/dev/index.html. I've done
> several modifications to the base Furo theme, mostly changing colors
> and a few small font tweaks, so please let me know if you see anything
> that should be improved style-wise. If you can, please also test the
> dark mode (click the sun icon at the top), and on mobile, and try to
> look at different types of documentation pages. If something looks
> off, there's a good chance I messed up the CSS for it somehow or just
> didn't notice it, so please let me know.
>
> The pull request is https://github.com/sympy/sympy/pull/23159/. Also
> if any frontend experts can critique my terrible CSS/Javascript
> skills, that would be helpful.
>
> Note that this does remove the SymPy Live extension from the
> documentation, as it's not compatible with Furo. If we can get a
> similar extension implemented that uses pyiodide, preferably one that
> is maintained by the broader community, that would be great.
>
> Aaron Meurer
>
> On Tue, Mar 1, 2022 at 11:37 AM Chris Smith  wrote:
> >
> > For anyone else not familiar yet with the "bus factor", I learned from
> wikipedia that "The bus factor is a measurement of the risk resulting from
> information and capabilities not being shared among team members, derived
> from the phrase "in case they get hit by a bus."
> >
> > /c
> > On Tuesday, March 1, 2022 at 2:49:12 AM UTC-6 moore...@gmail.com wrote:
> >>
> >> Furo looks good. If you think the bus factor is not a big deal, that's
> fine then. It's not as important as an actual dependency of sympy.
> >>
> >> > The decision to use Furo isn't completely final yet. So if you want
> to make the case for one of the other themes, you still can.
> >>
> >> My vote in the survey was RTD. I explained it in the survey my
> reasoning. But that's all I have to offer for the case.
> >>
> >> Jason
> >> moorepants.info
> >> +01 530-601-9791
> >>
> >>
> >> On Tue, Mar 1, 2022 at 12:50 AM Aaron Meurer  wrote:
> >>>
> >>> On Sat, Feb 26, 2022 at 1:11 AM Jason Moore 
> wrote:
> >>> >
> >>> > Thanks for doing this! I read through all the comments.
> >>> >
> >>> > Couple of points:
> >>> >
> >>> > - With 22 respondents and large standard deviation, the numbers
> don't really mean anything. Basically all themes are rated the same.
> >>> > - The written comments are most useful and I get the impression that
> almost any of the themes could work, but each requires some tweaking to fit
> for SymPy.
> >>> >
> >>> > I would recommend choosing based on which theme has the most
> configuration options and energy behind it because we want to easily tweak
> things and we automatically benefit from upstream improvements. If we do
> pydata, we join with our counterparts Numpy, scipy, pandas, etc. and it
> keeps us connected nicely to that community and when people jump around the
> scipy ecosystem docs they get the same (or similar) experience. RTD theme,
> by far, is the most used because it is the default theme on their service
> and there is a company that spends a lot of dev time on it. RTD is quite
> valuable and gives a uniform experience across a large set of python
> projects. Furo and book are likely used the least and have the smallest dev
> communities. Furo, as I understand, is essentially a one man show. It looks
> nice now, but may not be a good long term solution.
> >>>
> >>> I agree that the bus factor is a downside to Furo. However, I'm not
> >>> too worried about it given that it's not all that hard to change the
> >>> Sphinx theme. Any customizations would have to be redone, but it took
> >>> me about a day of work to restyle Furo (and honestly someone more
> >>> familiar with CSS could have done it much faster). And there are ways
> >>> that Furo could have made restyling easier than it was, so potentially
> >>> restyling a hypothetical future theme could be done even easier.
> >>>
> >>> The styling (colors, font choices, very basic CSS changes) are easy to
> >>> make. What's hard to do is to change how the theme works at a
> >>> fundamental level. That's why one of the primary things we looked at

Re: [sympy] Replacing terms / sympy.physics.mechanics

[Jason Moore]

The sympy.srepr() function can help debug things, as it shows the "true"
form of the expression. Maybe a variable is printing differently than what
it  is.

Jason
moorepants.info
+01 530-601-9791


On Mon, Mar 7, 2022 at 1:23 PM Peter Stahlecker 
wrote:

> I tried on a 'small' example, and N_y.suns({sm.Derivative(q1, t): u1})
> worked just fine !!
> No idea, what is going on.
>
> Am So., 6. März 2022 um 15:18 Uhr schrieb Peter Stahlecker <
> peter.stahlec...@gmail.com>:
>
>> I am playing around with an ellipse, which rotates in 3D.
>> In its own coordinate system A, its equation of course is
>>
>> x**2/a**2 + y**2/b**2 + z**2/c**2 = 1
>>
>> A rotates relative to N, the generalized coordinates are q1, q2, q3,
>>  dq1/dt = u1, etc.
>> I express the rotated ellipse in N, by using A.variable_map(N), now the
>> coordinates are, say, N_x, N_y, N_z.
>> Using sympy.solve I solve the ellipse equation for N_y,  I get two
>> solutions, of which I take the one I need, so, say, I get
>> N_y = f(N_x, N_z, q1, d2, d3, a, b, c,…)
>> I want the speed of N_y, so I write:
>>
>> Speed_N_y = f(…..).diff(t)
>>
>> Now my problem starts:
>> In Speed_N_y,  there are terms like Derivative(q1(t), t), and same for
>> q2, q3.
>> Of course, these terms are u1, u2, u3, but I cannot find a way to replace
>> Derivative(q1(t), t) with u1, etc.
>> I tried Speed_N_y.subs({Derivative(q1(t), t): u2})  but this did not
>> work.
>> I tried Speed_N_y.subs({q1.diff(t): u1}) also this did not work.
>> I also tried to get rid of these Derivative terms by writing
>> NY_lam = lambdify( …, Speed_N_y, {‚Derivative(q1(t), t)‘: u1})
>> This did not give an error - but also did not accomplish anything.
>>
>> Of course, when I try to lambdify my Speed_N_y and then try to evaluate
>> it numerically the problems come up, as this Derivative(q1(t), t) is
>> unknown.
>>
>> Any help is GREATLY appreciated! Thanks!
>>
>>
>>
>>
>> --
>> 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 discussion on the web visit
>> https://groups.google.com/d/msgid/sympy/243c5c3b-0896-4814-8198-953b001ff950n%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 sympy+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CABKqA0aM60dpNsmJHn70Qsb8BMTceoeVz0ysSS09HTwgnTuMbQ%40mail.gmail.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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Ah5A_T1uZE5ECGo0eecEsSURd5o7Wr9c23QLDqROXipUA%40mail.gmail.com.

Re: [sympy] Replacing terms / sympy.physics.mechanics

[Jason Moore]

I typically use `.xreplace()` if I'm simply swapping one variable for
another. But subs or replace should work. Sympy mechanics uses t =
me.dynamicsymbols._t internally. Are you using your own defined t that
different? If soe the derivative terms could print the same but aren't
actually the same symbols.

You'll need to share some code that reproduces the substitution error so we
can run it and try it.

Jason
moorepants.info
+01 530-601-9791


On Sun, Mar 6, 2022 at 3:18 PM Peter Stahlecker 
wrote:

> I am playing around with an ellipse, which rotates in 3D.
> In its own coordinate system A, its equation of course is
>
> x**2/a**2 + y**2/b**2 + z**2/c**2 = 1
>
> A rotates relative to N, the generalized coordinates are q1, q2, q3,
>  dq1/dt = u1, etc.
> I express the rotated ellipse in N, by using A.variable_map(N), now the
> coordinates are, say, N_x, N_y, N_z.
> Using sympy.solve I solve the ellipse equation for N_y,  I get two
> solutions, of which I take the one I need, so, say, I get
> N_y = f(N_x, N_z, q1, d2, d3, a, b, c,…)
> I want the speed of N_y, so I write:
>
> Speed_N_y = f(…..).diff(t)
>
> Now my problem starts:
> In Speed_N_y,  there are terms like Derivative(q1(t), t), and same for q2,
> q3.
> Of course, these terms are u1, u2, u3, but I cannot find a way to replace
> Derivative(q1(t), t) with u1, etc.
> I tried Speed_N_y.subs({Derivative(q1(t), t): u2})  but this did not work.
> I tried Speed_N_y.subs({q1.diff(t): u1}) also this did not work.
> I also tried to get rid of these Derivative terms by writing
> NY_lam = lambdify( …, Speed_N_y, {‚Derivative(q1(t), t)‘: u1})
> This did not give an error - but also did not accomplish anything.
>
> Of course, when I try to lambdify my Speed_N_y and then try to evaluate it
> numerically the problems come up, as this Derivative(q1(t), t) is unknown.
>
> Any help is GREATLY appreciated! Thanks!
>
>
>
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/243c5c3b-0896-4814-8198-953b001ff950n%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Ajr1NVDJWWuLRdTpz-2xA-_NTEJrVJCxPk2Y2zoJiqL-Q%40mail.gmail.com.

Re: [sympy] more unified (and usable) solve output

[Jason Moore]

I think changing this will break tons of code in the wild. Isnt it best
make a new "solve_new" and then leave solve be (maybe with a deprecation
warning. You could call it `solve_equations` or something.

Jason
moorepants.info
+01 530-601-9791


On Thu, Mar 3, 2022 at 11:45 PM Oscar Benjamin 
wrote:

> On Thu, 3 Mar 2022 at 20:28, Aaron Meurer  wrote:
> > On Thu, Mar 3, 2022 at 8:28 AM Chris Smith  wrote:
> > >
> > > Although the dict=True or set=True will give a standard output, can we
> at least unify the case for when variables are given so we always get a
> list of one or more dictionaries? So the above would be `[{x: -sqrt(y)},
> {x: sqrt(y)}]` and `[{x: y}]`, respectively. This would then make `solve`
> always give a list of a) values for a univariate expression, b) a list of
> one or more dictionaries for every other case.  (Case (a) will give a list
> of dictionaries if `dict=True`.)
> >
> > Changing the output type could break code that solves a specific
> > equation. I am doubtful whether any users actually understand the
> > output type behavior of solve without the dict=True flag. So
> > personally I think we should clean it up. We already recommend using
> > dict=True to get consistent output types, and this would only affect
> > users who aren't doing that.
>
> It would be much better if solve always worked like that but obviously
> that's not a backwards compatible change and I'm not sure what would
> break. I don't think that the type of the output should depend on the
> number of solutions although it could depend on the type of the
> arguments (e.g a single equation vs a list of equations). At the
> moment the type of the output can depend on the equations themselves
> which is wildly awkward:
>
> In [3]: solve([x-1], [x])
> Out[3]: {x: 1}
>
> In [4]: solve([x**2-1], [x])
> Out[4]: [(-1,), (1,)]
>
> The ideal output for solve is absolutely a list of dicts though and it
> would be good to make that the default at least when given a list of
> equations. I guarantee that a lot of notebooks or other little bits of
> code will depend on each of these random special cases though.
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAHVvXxROqs0CpGmSX2%3Dk8xJgTos9FPpP1x0GYP0aHCdiYErDnA%40mail.gmail.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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AhaE9Z1H9GUo1M2Ag5yb0v28uG-wUGRGA%3DuC2TTR%2BycNA%40mail.gmail.com.

Re: [sympy] Results of the SymPy Documentation Theme Survey

[Jason Moore]

Furo looks good. If you think the bus factor is not a big deal, that's fine
then. It's not as important as an actual dependency of sympy.

> The decision to use Furo isn't completely final yet. So if you want to
make the case for one of the other themes, you still can.

My vote in the survey was RTD. I explained it in the survey my reasoning.
But that's all I have to offer for the case.

Jason
moorepants.info
+01 530-601-9791


On Tue, Mar 1, 2022 at 12:50 AM Aaron Meurer  wrote:

> On Sat, Feb 26, 2022 at 1:11 AM Jason Moore  wrote:
> >
> > Thanks for doing this! I read through all the comments.
> >
> > Couple of points:
> >
> > - With 22 respondents and large standard deviation, the numbers don't
> really mean anything. Basically all themes are rated the same.
> > - The written comments are most useful and I get the impression that
> almost any of the themes could work, but each requires some tweaking to fit
> for SymPy.
> >
> > I would recommend choosing based on which theme has the most
> configuration options and energy behind it because we want to easily tweak
> things and we automatically benefit from upstream improvements. If we do
> pydata, we join with our counterparts Numpy, scipy, pandas, etc. and it
> keeps us connected nicely to that community and when people jump around the
> scipy ecosystem docs they get the same (or similar) experience. RTD theme,
> by far, is the most used because it is the default theme on their service
> and there is a company that spends a lot of dev time on it. RTD is quite
> valuable and gives a uniform experience across a large set of python
> projects. Furo and book are likely used the least and have the smallest dev
> communities. Furo, as I understand, is essentially a one man show. It looks
> nice now, but may not be a good long term solution.
>
> I agree that the bus factor is a downside to Furo. However, I'm not
> too worried about it given that it's not all that hard to change the
> Sphinx theme. Any customizations would have to be redone, but it took
> me about a day of work to restyle Furo (and honestly someone more
> familiar with CSS could have done it much faster). And there are ways
> that Furo could have made restyling easier than it was, so potentially
> restyling a hypothetical future theme could be done even easier.
>
> The styling (colors, font choices, very basic CSS changes) are easy to
> make. What's hard to do is to change how the theme works at a
> fundamental level. That's why one of the primary things we looked at
> was the behavior of the sidebars in the different themes. This is not
> something we can "fix" ourselves with some CSS. We are really just
> stuck with however the theme handles things. Here Furo had the best
> behavior: for instance, the right sidebar always being expanded, which
> was noted in the survey as a plus. I would like to avoid things like
> custom Javascript on the docs site, as it becomes unmaintainable given
> that most SymPy developers are not frontend developers.
>
> In general, the Furo theme seems to have had a finer attention to
> detail than the other themes. We have a lot of docs and they exercise
> a lot of corner cases that the other themes don't seem to have been
> designed around, but Furo handles them correctly. As an example, look
> at how the different themes' sidebars handle the very long section
> names on the active deprecations page. Book and Pydata add a
> horizontal scrollbar to the sidebar:
>
>
> https://bertiewooster.github.io/sympy-doc/book/explanation/active-deprecations.html#sympy-stats-discretemarkovchain-absorbing-probabilites
>
> https://bertiewooster.github.io/sympy-doc/pydata/explanation/active-deprecations.html#sympy-stats-discretemarkovchain-absorbing-probabilites
>
> Readthedocs just truncates the long names:
>
>
> https://bertiewooster.github.io/sympy-doc/rtd/explanation/active-deprecations.html#sympy-stats-discretemarkovchain-absorbing-probabilites
>
> Furo word wraps the text:
>
>
> https://bertiewooster.github.io/sympy-doc/furo/explanation/active-deprecations.html#sympy-stats-discretemarkovchain-absorbing-probabilites
>
> The Furo behavior is clearly the best, and it suggests to me that the
> other themes were not ever tested on this sort of thing.
>
> >
> > Jermey and Aaron concluded that Furo was the best choice, but I hope
> these other aspects are considered too. We're a big project and even if
> Furo currently has the best looking design of the four, there are other
> non-design factors that are also quite important and, IMO, outweigh the 0.1
> point rating differences in the comparison of the designs.
>
> The decision to use Furo isn't completely final yet. So if you want to
> make the case f

Re: [sympy] Results of the SymPy Documentation Theme Survey

[Jason Moore]

I also just realized that the book theme is the pydata theme with some
tweaks.

Jason
moorepants.info
+01 530-601-9791


On Sat, Feb 26, 2022 at 9:11 AM Jason Moore  wrote:

> Thanks for doing this! I read through all the comments.
>
> Couple of points:
>
> - With 22 respondents and large standard deviation, the numbers don't
> really mean anything. Basically all themes are rated the same.
> - The written comments are most useful and I get the impression that
> almost any of the themes could work, but each requires some tweaking to fit
> for SymPy.
>
> I would recommend choosing based on which theme has the most configuration
> options and energy behind it because we want to easily tweak things and we
> automatically benefit from upstream improvements. If we do pydata, we join
> with our counterparts Numpy, scipy, pandas, etc. and it keeps us connected
> nicely to that community and when people jump around the scipy ecosystem
> docs they get the same (or similar) experience. RTD theme, by far, is the
> most used because it is the default theme on their service and there is a
> company that spends a lot of dev time on it. RTD is quite valuable and
> gives a uniform experience across a large set of python projects. Furo and
> book are likely used the least and have the smallest dev communities. Furo,
> as I understand, is essentially a one man show. It looks nice now, but may
> not be a good long term solution.
>
> Jermey and Aaron concluded that Furo was the best choice, but I hope these
> other aspects are considered too. We're a big project and even if Furo
> currently has the best looking design of the four, there are other
> non-design factors that are also quite important and, IMO, outweigh the 0.1
> point rating differences in the comparison of the designs.
>
> Jason
> moorepants.info
> +01 530-601-9791
>
>
> On Sat, Feb 26, 2022 at 1:24 AM Jeremy Monat  wrote:
>
>> Hello SymPy community,
>>
>> SymPy ran a user survey about its documentation theme from February 5-19,
>> 2022. The primary purpose of the survey was to guide the selection of a
>> Sphinx theme for the SymPy Documentation at https://docs.sympy.org. We
>> thank everyone who took and shared the survey.
>> Even though the survey is no longer open, we still welcome feedback on
>> SymPy's documentation. Feel free to reach out to us on the mailing list, or
>> in the Github issue to change the Sphinx theme
>> <https://github.com/sympy/sympy/issues/22716>.
>>
>> I have written up an analysis of the results at
>> https://www.sympy.org/sympy-docs-survey/2022-theme-survey.html (thanks
>> to Aaron Meurer for some analysis code, and posting the analysis there).
>> The source code for the
>> Jupyter notebook can be found at
>> https://github.com/sympy/sympy-docs-survey. I
>> have included a summary of this analysis here.
>>
>> A total of 22 people responded. The survey was done on Google Surveys and
>> was shared on the SymPy public mailing list, the @SymPy
>> <https://twitter.com/SymPy> Twitter account, and a SymPy discussion on
>> GitHub <https://github.com/sympy/sympy/discussions/23055>. The survey
>> consisted of 14 questions, all of which were optional. The results of these
>> responses are summarized here. We would like to thank everyone who took and
>> shared the survey.
>>
>> At a high level, there are three main takeaways from the results.
>>
>>1.
>>
>>The themes can be divided into three ratings categories, where the
>>rating scale was 1 (Not very useful) to 4 (Very useful):
>>1. Highest: Furo <https://bertiewooster.github.io/sympy-doc/furo> at
>>   2.95.
>>   2. Middle: PyData
>>   <https://bertiewooster.github.io/sympy-doc/pydata> and Book
>>   <https://bertiewooster.github.io/sympy-doc/book>, nearly tied at
>>   2.85 and 2.86, respectively.
>>   3. Lowest: Read the Docs (RTD)
>>   <https://bertiewooster.github.io/sympy-doc/rtd> at 2.47.
>>2.
>>
>>Most comments about themes, both likes and dislikes, were about
>>formatting, look and feel, and navigation.
>>3.
>>
>>We should proceed with the Furo theme, customizing it to address
>>respondents' dislikes about its formatting. We can keep the PyData and 
>> Book
>>themes in mind as backup options.
>>
>> Again, I would like to thank everyone who took the time to fill out this
>> survey. It really helps us to have your feedback.
>>
>> Jeremy Monat
>>
>> --
>> You received this message because you are subscribed to the Google Grou

Re: [sympy] Results of the SymPy Documentation Theme Survey

[Jason Moore]

Thanks for doing this! I read through all the comments.

Couple of points:

- With 22 respondents and large standard deviation, the numbers don't
really mean anything. Basically all themes are rated the same.
- The written comments are most useful and I get the impression that almost
any of the themes could work, but each requires some tweaking to fit for
SymPy.

I would recommend choosing based on which theme has the most configuration
options and energy behind it because we want to easily tweak things and we
automatically benefit from upstream improvements. If we do pydata, we join
with our counterparts Numpy, scipy, pandas, etc. and it keeps us connected
nicely to that community and when people jump around the scipy ecosystem
docs they get the same (or similar) experience. RTD theme, by far, is the
most used because it is the default theme on their service and there is a
company that spends a lot of dev time on it. RTD is quite valuable and
gives a uniform experience across a large set of python projects. Furo and
book are likely used the least and have the smallest dev communities. Furo,
as I understand, is essentially a one man show. It looks nice now, but may
not be a good long term solution.

Jermey and Aaron concluded that Furo was the best choice, but I hope these
other aspects are considered too. We're a big project and even if Furo
currently has the best looking design of the four, there are other
non-design factors that are also quite important and, IMO, outweigh the 0.1
point rating differences in the comparison of the designs.

Jason
moorepants.info
+01 530-601-9791


On Sat, Feb 26, 2022 at 1:24 AM Jeremy Monat  wrote:

> Hello SymPy community,
>
> SymPy ran a user survey about its documentation theme from February 5-19,
> 2022. The primary purpose of the survey was to guide the selection of a
> Sphinx theme for the SymPy Documentation at https://docs.sympy.org. We
> thank everyone who took and shared the survey.
> Even though the survey is no longer open, we still welcome feedback on
> SymPy's documentation. Feel free to reach out to us on the mailing list, or
> in the Github issue to change the Sphinx theme
> .
>
> I have written up an analysis of the results at
> https://www.sympy.org/sympy-docs-survey/2022-theme-survey.html (thanks to
> Aaron Meurer for some analysis code, and posting the analysis there). The
> source code for the
> Jupyter notebook can be found at
> https://github.com/sympy/sympy-docs-survey. I
> have included a summary of this analysis here.
>
> A total of 22 people responded. The survey was done on Google Surveys and
> was shared on the SymPy public mailing list, the @SymPy
>  Twitter account, and a SymPy discussion on
> GitHub . The survey
> consisted of 14 questions, all of which were optional. The results of these
> responses are summarized here. We would like to thank everyone who took and
> shared the survey.
>
> At a high level, there are three main takeaways from the results.
>
>1.
>
>The themes can be divided into three ratings categories, where the
>rating scale was 1 (Not very useful) to 4 (Very useful):
>1. Highest: Furo  at
>   2.95.
>   2. Middle: PyData 
>   and Book , nearly
>   tied at 2.85 and 2.86, respectively.
>   3. Lowest: Read the Docs (RTD)
>    at 2.47.
>2.
>
>Most comments about themes, both likes and dislikes, were about
>formatting, look and feel, and navigation.
>3.
>
>We should proceed with the Furo theme, customizing it to address
>respondents' dislikes about its formatting. We can keep the PyData and Book
>themes in mind as backup options.
>
> Again, I would like to thank everyone who took the time to fill out this
> survey. It really helps us to have your feedback.
>
> Jeremy Monat
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/ae6935a1-d638-4265-a094-bd59f1dfc643n%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Aidk%3DK_hNciDukWPUM4V6hUNxZXDMkQm-%3DMnR5WcnNspA%40mail.gmail.com.

[sympy] Re: Postdoctoral Researcher Opening: Advancing Biomechanical Modeling By Improving SymPy Code Generation (x/f/m)

[Jason Moore]

Hi everyone,

Just a reminder that applications for this are due in 4 days!

Please spread the word.

Jason
moorepants.info
+01 530-601-9791


On Wed, Feb 2, 2022 at 3:51 AM Jason Moore  wrote:

> Hi,
>
> We are hiring a postdoctoral researcher at TU Delft as part of SymPy's
> recent CZI grant.
>
> *Applications are due February 28, 2022*
>
> Info @ https://mechmotum.github.io/blog/sympy-czi-postdoc.html
>
> Please spread the word!
>
> Jason
> moorepants.info
> +01 530-601-9791
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AgKjecty47X6BoZX2E%3DLis3tXfJMpCPsRaEyCzTm%2B3FLA%40mail.gmail.com.

Re: [sympy] SymPy 1.10rc1 released

[Jason Moore]

HI,

I really like the bot and it forces you to at least think about the release
notes (even if all you do is write NO ENTRY). Yes, our review culture
should be that we don't let NO ENTRY through as much, but that is a culture
change. The bot could say, "are you really really sure this only needs a no
entry??"

I also think the release notes should be part of the repo, part of the
docs, and packaged in the released source tarball.

Having the best of both worlds would be nice. I think scipy or some of the
other big python projects do things as Oscar suggests, have a single file
per PR that is merged together.

Jason
moorepants.info
+01 530-601-9791


On Tue, Feb 22, 2022 at 1:27 AM Aaron Meurer  wrote:

>
>
> On Fri, Feb 18, 2022 at 6:49 PM Oscar Benjamin 
> wrote:
>
>> On Sat, 19 Feb 2022 at 01:28, Aaron Meurer  wrote:
>> >
>> > On Fri, Feb 18, 2022 at 3:38 PM Oscar Benjamin <
>> oscar.j.benja...@gmail.com> wrote:
>> >>
>> >> On Fri, 18 Feb 2022 at 22:30, Aaron Meurer  wrote:
>> >> >
>> >> > On Fri, Feb 18, 2022 at 3:24 PM Oscar Benjamin <
>> oscar.j.benja...@gmail.com> wrote:
>> >> >>
>> >> >> On Fri, 18 Feb 2022 at 20:58, Aaron Meurer 
>> wrote:
>> >> >> >
>> >> >> > On Fri, Feb 18, 2022 at 12:59 PM Oscar Benjamin <
>> oscar.j.benja...@gmail.com> wrote:
>> >> >> >>
>> >> >> >> Hi all,
>> >> >> >>
>> >> >> >> I've just released the release candidate SymPy 1.10rc1. If no
>> issues
>> >> >> >> are reported then this will be released as SymPy 1.10 in around 1
>> >> >> >> week's time. Please test this out with your code and downstream
>> >> >> >> libraries because it's best if any new bugs can be fixed before
>> the
>> >> >> >> final release of 1.10.
>> >> >> >>
>> >> >> >> The release notes are here:
>> >> >> >> https://github.com/sympy/sympy/wiki/Release-Notes-for-1.10
>> >> >
>> >> > By the way, a minor note, I had to update the supported Python
>> versions in the header for the 1.10 and 1.11 release notes pages. Whatever
>> process you are using to create the new pages is based on an old version of
>> the release notes.
>> >>
>> >> The process is just copying the contents of the old page to the new
>> one :)
>> >>
>> >> That's why I'd rather have the release notes in the repo itself. Much
>> >> easier to automate things there and it means that these updates can
>> >> happen at the same time that support for new/old versions of Python is
>> >> added/removed.
>> >
>> > How would you envision the release notes process looking with the notes
>> living in the repo itself?
>>
>> Currently the release note is made as an edit to the OP of a PR which
>> is not intuitive and doesn't match the workflow for everything else
>> where all changes are in the diff. I would like a workflow where the
>> release note is part of the diff and is clearly visible to the
>> reviewer who looks at the diff.
>>
>> There would essentially be something like a release-notes-1.10.md file
>> for each release but contributors would not edit the file directly.
>> Instead they add a file somewhere called something like news-12345.md
>> where 12345 is the PR number. Then at release time all of those files
>> are compiled into the release-notes-1.10.md file.
>>
>> The important change from a contributors perspective is that the
>> release note is added in a file in the diff rather than in the OP of
>> the PR. From a reviewers perspective the difference is that the
>> release note should be reviewed as part of the diff rather than
>> separately (personally I would find it easier to remember to review it
>> that way).
>>
>> There would still be a need to have a way to say "no release note"
>> which should be required explicitly because otherwise most
>> contributors won't write release notes at all.
>>
>
> I guess I'd like to hear from contributors what they feel about the
> current way with the PR description + the bot vs. this proposed way. I've
> contributed to projects that use a system like this, and the SymPy system
> feels a lot easier to use. You just write the note in the PR description,
> which is where you should already be writing a summary of what changed.
>
> I agree the reviewing aspect of our current system should be improved. A
> lot of people just don't review the release notes at all, and people use
> "NO ENTRY" more often than they should and no one calls them out on it,
> even when the change is significant. I'm not sure if that would change with
> your proposed system. It seems to me that we just need for reviewers to
> explicitly make this something that they care about when reviewing. The
> current system is also designed so that a reviewer can add a note themself
> if they want to (I do this sometimes, but I don't know if anyone else ever
> does).
>
> Having the notes in the docs would indeed probably be better. The main
> downside is you have to do a PR to make any kind of edit.  However, I think
> it might be possible to do this even with the current system, e.g., by
> copying them from the wiki at release time, or 

Re: [sympy] Shutting down SymPy Gamma

[Jason Moore]

One free way to run an app like this is to run it on Heruko's free tier
(maybe appengine has that too). It will have limits on # users and resource
use, but at least it will run.

Jason
moorepants.info
+01 530-601-9791


On Tue, Feb 15, 2022 at 11:36 PM Aaron Meurer  wrote:

> Hi all.
>
> As you may know, SymPy Gamma (https://sympygamma.com/) is a site that
> works similar to Wolfram Alpha, but using SymPy under the hood. SymPy Gamma
> runs on the Google App Engine.
>
> Currently our Google App Engine bills are over $100 a month, with about
> 3/4 going to SymPy Gamma and the rest going to SymPy Live. These bills are
> paid from our SymPy NumFOCUS account, which is funded from donations.
>
> This is all money that would be better spent on the SymPy community.
>
> Additionally, SymPy Gamma is currently very under-maintained.  As you can
> see from https://github.com/sympy/sympy_gamma, the most recent commit was
> from April of last year.  These changes are mostly maintenance changes. No
> major features have been added to the site since 2014. Furthermore, the
> site runs SymPy 1.6.2, which was released in 2020. The primary issue is
> that none of us on the SymPy development team are web developers, so are
> not really able to do much with the site.
>
> What I would like to see is for someone to convert SymPy Gamma  to
> something that uses pyiodide so that it runs entirely in the browser and
> does not require any hosting costs.  However, this would require someone to
> step up and volunteer to do this. It would also be good to do something
> similar for SymPy Live (live.sympy.org and the extension in docs.sympy.org),
> although this is lower priority right now because SymPy Live is only
> costing a third of what SymPy Gamma is.
>
> By the way, if you are interested in doing this, it might be possible to
> get paid to do it via a NumFOCUS small development grant. See
> https://groups.google.com/g/sympy/c/VI1BJiWH_aY. Reach out to me if you
> are interested.
>
> Barring this, I suggest we shut down SymPy Gamma entirely. We will leave
> the source code up if anyone wants to run it themselves on the App Engine.
>
> Aaron Meurer
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2B2FHaYPSmHv%3DYp6NkkxF0w%3DY4eUQsn58aUULxJF4nMHA%40mail.gmail.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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AhcMH8RDN3yYX79STMr4OSzjP2zqYWXkEek7PEnmZOBbA%40mail.gmail.com.

Re: [sympy] Sympy.physics.mechanics / dynamicsymbols

[Jason Moore]

Peter,

I opened this issue: https://github.com/sympy/sympy/issues/23075

Jason
moorepants.info
+01 530-601-9791


On Mon, Feb 14, 2022 at 7:28 PM Jason Moore  wrote:

> Peter,
>
> If orient_body_fixed produces longer equations of motion than chaining
> orient_axis (or the older orient() and orientnew()), then we should figure
> out what the problem is with orient_body_fixed.  orient_body_fixed should
> produce shorter equations of motion because the angular velocities are
> supposed to be in the simplest form.
>
> Jason
> moorepants.info
> +01 530-601-9791
>
>
> On Mon, Feb 14, 2022 at 6:41 PM Peter Stahlecker <
> peter.stahlec...@gmail.com> wrote:
>
>> Dear Jason,
>>
>> As to the speed of the new terms, I simply tried it, using the equations
>> of motion of a one body pendulum.
>> There is no difference to the older terms:
>>
>> with the *body* version the the rhs has 863, 824 operations.
>> with the axis version, 2 intermediate frames, the rhs has 43,722
>> operations.
>>
>> The operations count was *exactly* the same with older and newer terms.
>>
>> Take care, Peter
>>
>> On Mon 14. Feb 2022 at 18:04 Peter Stahlecker 
>> wrote:
>>
>>> Dear Jason,
>>>
>>> Just read you latest addition about vectors and reference frames.
>>> Small question:
>>> In order to rotate a frame relative to another one, you use these terms
>>> *A.orient_axis(N, ..)*
>>> *A.orient_body_fixed(N, …)*
>>>
>>> I assume, these are the new versions for
>>> A.orientnew(N, ‚Axis‘, …)
>>> A.orientnew(N, ‚Body, …)
>>>
>>> You might recall, that I ‚empirically‘ found that the *Body* version
>>> created much larger equations of motion compared to using ‚intermediate ‚
>>> *Axis*‘ versions.
>>>
>>> Is it better to use *orient_body_fixed,* to avoid this issue of larger
>>> equations of motion?
>>>
>>> Thanks & take care!
>>> Peter
>>>
>>>
>>>
>>> On Sun 6. Feb 2022 at 08:19 Peter Stahlecker 
>>> wrote:
>>>
>>>> Dear Jason,
>>>>
>>>> Thanks a lot for your explanation! Clear!
>>>> I checked on metaclasses, but I must admit I mostly understood, that a
>>>> simple user like me should not mess with them!  :-))
>>>>
>>>> Peter
>>>>
>>>> On Sun 6. Feb 2022 at 07:49 Jason Moore  wrote:
>>>>
>>>>> Peter,
>>>>>
>>>>> All `dynamicsymbols` is, is:
>>>>>
>>>>> f = Function('f')
>>>>> t = symbols('t')
>>>>> f_of_t = f(t)
>>>>>
>>>>> The last line `f(t)` is generating a new class of type f, instead of
>>>>> using a predefined class (look up metaclasses). So the user, typically not
>>>>> aware of this element in Python, is confused about what they are working
>>>>> with in the last line. It is just the way SymPy Function works. There are
>>>>> open issues about trying to change it to something more sensible for the
>>>>> user to understand.
>>>>>
>>>>> Jason
>>>>> moorepants.info
>>>>> +01 530-601-9791
>>>>>
>>>>>
>>>>> On Sun, Feb 6, 2022 at 7:39 AM Peter Stahlecker <
>>>>> peter.stahlec...@gmail.com> wrote:
>>>>>
>>>>>> My question is more for my ‚general education‘ in sympy.
>>>>>>
>>>>>> I write this little program
>>>>>>
>>>>>> *from sympy.physics.mechanics import **
>>>>>> *import sympy as sm*
>>>>>> *a = dynamicsymbols(‚a‘)*
>>>>>> *b = sm.symbols(‚b‘)*
>>>>>>
>>>>>> *print(‚type of a:‘,  type(a))*
>>>>>> *print(‚type of b:‘, type(b))*
>>>>>>
>>>>>> I get this result:
>>>>>>
>>>>>> *type of a:  a*
>>>>>> *type of b: class sympy.core.symbols.Symbols*
>>>>>>
>>>>>> Is seems that *a* does not have a type. How can that be? I thought
>>>>>> in python ‚everything‘ has a type.
>>>>>>
>>>>>> Thanks!
>>>>>> Any explanation is highly appreciated!
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> You received t

Re: [sympy] Sympy.physics.mechanics / dynamicsymbols

[Jason Moore]

Alan,

Thanks for the tip. There are lots of mechanics notations and methods, but
I'm not sure I'd use many of them for teaching mechanics because the more
advanced math principles often hide the forest for the trees for
engineering students. These newer methods based on Geometric and Clifford
algebra are good for computational efficiency and succinctness of notation
but that's more useful for people that already understand the principles of
mechanics.

Jason
moorepants.info
+01 530-601-9791


On Mon, Feb 14, 2022 at 7:26 PM Alan Bromborsky 
wrote:

> For the people developing and maintaining the mechanics modules, you may
> want to look at the following book which treats mechanics problems with
> some new methods.  Describing rotations is greatly simplified -
>
> https://link.springer.com/book/10.1007/0-306-47122-1
> On 2/14/22 12:40 PM, Peter Stahlecker wrote:
>
> Dear Jason,
>
> As to the speed of the new terms, I simply tried it, using the equations
> of motion of a one body pendulum.
> There is no difference to the older terms:
>
> with the *body* version the the rhs has 863, 824 operations.
> with the axis version, 2 intermediate frames, the rhs has 43,722
> operations.
>
> The operations count was *exactly* the same with older and newer terms.
>
> Take care, Peter
>
> On Mon 14. Feb 2022 at 18:04 Peter Stahlecker 
> wrote:
>
>> Dear Jason,
>>
>> Just read you latest addition about vectors and reference frames.
>> Small question:
>> In order to rotate a frame relative to another one, you use these terms
>> *A.orient_axis(N, ..)*
>> *A.orient_body_fixed(N, …)*
>>
>> I assume, these are the new versions for
>> A.orientnew(N, ‚Axis‘, …)
>> A.orientnew(N, ‚Body, …)
>>
>> You might recall, that I ‚empirically‘ found that the *Body* version
>> created much larger equations of motion compared to using ‚intermediate ‚
>> *Axis*‘ versions.
>>
>> Is it better to use *orient_body_fixed,* to avoid this issue of larger
>> equations of motion?
>>
>> Thanks & take care!
>> Peter
>>
>>
>>
>> On Sun 6. Feb 2022 at 08:19 Peter Stahlecker 
>> wrote:
>>
>>> Dear Jason,
>>>
>>> Thanks a lot for your explanation! Clear!
>>> I checked on metaclasses, but I must admit I mostly understood, that a
>>> simple user like me should not mess with them!  :-))
>>>
>>> Peter
>>>
>>> On Sun 6. Feb 2022 at 07:49 Jason Moore  wrote:
>>>
>>>> Peter,
>>>>
>>>> All `dynamicsymbols` is, is:
>>>>
>>>> f = Function('f')
>>>> t = symbols('t')
>>>> f_of_t = f(t)
>>>>
>>>> The last line `f(t)` is generating a new class of type f, instead of
>>>> using a predefined class (look up metaclasses). So the user, typically not
>>>> aware of this element in Python, is confused about what they are working
>>>> with in the last line. It is just the way SymPy Function works. There are
>>>> open issues about trying to change it to something more sensible for the
>>>> user to understand.
>>>>
>>>> Jason
>>>> moorepants.info
>>>> +01 530-601-9791
>>>>
>>>>
>>>> On Sun, Feb 6, 2022 at 7:39 AM Peter Stahlecker <
>>>> peter.stahlec...@gmail.com> wrote:
>>>>
>>>>> My question is more for my ‚general education‘ in sympy.
>>>>>
>>>>> I write this little program
>>>>>
>>>>> *from sympy.physics.mechanics import **
>>>>> *import sympy as sm*
>>>>> *a = dynamicsymbols(‚a‘)*
>>>>> *b = sm.symbols(‚b‘)*
>>>>>
>>>>> *print(‚type of a:‘,  type(a))*
>>>>> *print(‚type of b:‘, type(b))*
>>>>>
>>>>> I get this result:
>>>>>
>>>>> *type of a:  a*
>>>>> *type of b: class sympy.core.symbols.Symbols*
>>>>>
>>>>> Is seems that *a* does not have a type. How can that be? I thought in
>>>>> python ‚everything‘ has a type.
>>>>>
>>>>> Thanks!
>>>>> Any explanation is highly appreciated!
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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...@

Re: [sympy] Sympy.physics.mechanics / dynamicsymbols

[Jason Moore]

Peter,

If orient_body_fixed produces longer equations of motion than chaining
orient_axis (or the older orient() and orientnew()), then we should figure
out what the problem is with orient_body_fixed.  orient_body_fixed should
produce shorter equations of motion because the angular velocities are
supposed to be in the simplest form.

Jason
moorepants.info
+01 530-601-9791


On Mon, Feb 14, 2022 at 6:41 PM Peter Stahlecker 
wrote:

> Dear Jason,
>
> As to the speed of the new terms, I simply tried it, using the equations
> of motion of a one body pendulum.
> There is no difference to the older terms:
>
> with the *body* version the the rhs has 863, 824 operations.
> with the axis version, 2 intermediate frames, the rhs has 43,722
> operations.
>
> The operations count was *exactly* the same with older and newer terms.
>
> Take care, Peter
>
> On Mon 14. Feb 2022 at 18:04 Peter Stahlecker 
> wrote:
>
>> Dear Jason,
>>
>> Just read you latest addition about vectors and reference frames.
>> Small question:
>> In order to rotate a frame relative to another one, you use these terms
>> *A.orient_axis(N, ..)*
>> *A.orient_body_fixed(N, …)*
>>
>> I assume, these are the new versions for
>> A.orientnew(N, ‚Axis‘, …)
>> A.orientnew(N, ‚Body, …)
>>
>> You might recall, that I ‚empirically‘ found that the *Body* version
>> created much larger equations of motion compared to using ‚intermediate ‚
>> *Axis*‘ versions.
>>
>> Is it better to use *orient_body_fixed,* to avoid this issue of larger
>> equations of motion?
>>
>> Thanks & take care!
>> Peter
>>
>>
>>
>> On Sun 6. Feb 2022 at 08:19 Peter Stahlecker 
>> wrote:
>>
>>> Dear Jason,
>>>
>>> Thanks a lot for your explanation! Clear!
>>> I checked on metaclasses, but I must admit I mostly understood, that a
>>> simple user like me should not mess with them!  :-))
>>>
>>> Peter
>>>
>>> On Sun 6. Feb 2022 at 07:49 Jason Moore  wrote:
>>>
>>>> Peter,
>>>>
>>>> All `dynamicsymbols` is, is:
>>>>
>>>> f = Function('f')
>>>> t = symbols('t')
>>>> f_of_t = f(t)
>>>>
>>>> The last line `f(t)` is generating a new class of type f, instead of
>>>> using a predefined class (look up metaclasses). So the user, typically not
>>>> aware of this element in Python, is confused about what they are working
>>>> with in the last line. It is just the way SymPy Function works. There are
>>>> open issues about trying to change it to something more sensible for the
>>>> user to understand.
>>>>
>>>> Jason
>>>> moorepants.info
>>>> +01 530-601-9791
>>>>
>>>>
>>>> On Sun, Feb 6, 2022 at 7:39 AM Peter Stahlecker <
>>>> peter.stahlec...@gmail.com> wrote:
>>>>
>>>>> My question is more for my ‚general education‘ in sympy.
>>>>>
>>>>> I write this little program
>>>>>
>>>>> *from sympy.physics.mechanics import **
>>>>> *import sympy as sm*
>>>>> *a = dynamicsymbols(‚a‘)*
>>>>> *b = sm.symbols(‚b‘)*
>>>>>
>>>>> *print(‚type of a:‘,  type(a))*
>>>>> *print(‚type of b:‘, type(b))*
>>>>>
>>>>> I get this result:
>>>>>
>>>>> *type of a:  a*
>>>>> *type of b: class sympy.core.symbols.Symbols*
>>>>>
>>>>> Is seems that *a* does not have a type. How can that be? I thought in
>>>>> python ‚everything‘ has a type.
>>>>>
>>>>> Thanks!
>>>>> Any explanation is highly appreciated!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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 discussion on the web visit
>>>>> https://groups.google.com/d/msgid/sympy/5db2836e-44a8-428f-8b82-c56b2b2b5b20n%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/sympy/5db2836e-44a8-428f-8b82-c56b2b2b5b20n%40googlegroups.com?utm_medium=email_source=footer>
>>>>> .
>>>>>
>>>> --
>>>> You received t

Re: [sympy] Sympy.physics.mechanics / dynamicsymbols

[Jason Moore]

Peter,

All `dynamicsymbols` is, is:

f = Function('f')
t = symbols('t')
f_of_t = f(t)

The last line `f(t)` is generating a new class of type f, instead of using
a predefined class (look up metaclasses). So the user, typically not aware
of this element in Python, is confused about what they are working with in
the last line. It is just the way SymPy Function works. There are open
issues about trying to change it to something more sensible for the user to
understand.

Jason
moorepants.info
+01 530-601-9791


On Sun, Feb 6, 2022 at 7:39 AM Peter Stahlecker 
wrote:

> My question is more for my ‚general education‘ in sympy.
>
> I write this little program
>
> *from sympy.physics.mechanics import **
> *import sympy as sm*
> *a = dynamicsymbols(‚a‘)*
> *b = sm.symbols(‚b‘)*
>
> *print(‚type of a:‘,  type(a))*
> *print(‚type of b:‘, type(b))*
>
> I get this result:
>
> *type of a:  a*
> *type of b: class sympy.core.symbols.Symbols*
>
> Is seems that *a* does not have a type. How can that be? I thought in
> python ‚everything‘ has a type.
>
> Thanks!
> Any explanation is highly appreciated!
>
>
>
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/5db2836e-44a8-428f-8b82-c56b2b2b5b20n%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Ajkjs%3DNhJOhrFXmEpLJ6nv0TM9FgHXg%3DS1kSCF-6Cw5zw%40mail.gmail.com.

Re: [sympy] sympy.physcis.mechanics // reaction force

[Jason Moore]

Peter,

Yes, the velocity constraints work the same way. There are reaction forces
that constrain the velocities.

Jason
moorepants.info
+01 530-601-9791


On Thu, Feb 3, 2022 at 10:37 AM Peter Stahlecker 
wrote:

> Dear Jason,
>
> Thanks!
> If I understood correctly, if I use velocity constraints, I do not use the
> minimal number of generalized coordinates, hence these reaction forces and
> 'virtual' speeds appear in my force term of the equations of motion. As
> they are normal to the motion of the particle(s), I simply set them to zero
> in the force term.
>
> Peter
>
> moore...@gmail.com schrieb am Donnerstag, 3. Februar 2022 um 10:20:46
> UTC+1:
>
>> Peter,
>>
>> If you have a particle that is forced to move along a path (typically be
>> a configuration constraint), then there exists reaction forces normal to
>> the path that keep it on the path. These forces are not present in the
>> equations of motion when they are formed with minimal coordinates. But you
>> can expose the forces by introducing fictitious (auxiliary) generalized
>> speeds normal to the path and a variable for the forces. This will result
>> in the minimal equations of motion and some algebraic equations for the
>> forces. All of these equations will have the aux speeds, which then must be
>> set to zero because they are fictitious. This should then leave you with
>> the equations of motion plus some equations that can be solved for the
>> forces.
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791 <(530)%20601-9791>
>>
>>
>> On Thu, Feb 3, 2022 at 10:03 AM Peter Stahlecker 
>> wrote:
>>
>>> Thanks! Would I also set the 'reaction forces' appearing in the force
>>> term equal to zero?
>>> As per my understanding of mechanics, they also should have no influence
>>> on the equations of motion (?)
>>>
>>> moore...@gmail.com schrieb am Donnerstag, 3. Februar 2022 um 09:59:53
>>> UTC+1:
>>>
 The virtual speeds will appear in the force equations, but you then
 just set them to zero because they are fictitious. You force equation
 should then be correct.

 Jason
 moorepants.info
 +01 530-601-9791 <(530)%20601-9791>


 On Thu, Feb 3, 2022 at 9:58 AM Peter Stahlecker 
 wrote:

> When I use a velocity constraint to force a particle not to move in a
> certain direction, there must be a 'reaction force' on the particle.
> I use KM.auxiliary_eqs to find reaction forces, which works very well
> in general!
>
> However,  if I try to find the reaction force due to a velocity
> constraint, it does no seem to work:
> The force term of the equations of motion contains the 'virtual
> speed', its time derivative and the reaction force.
>
> Am I doing something wrong, or do velocity_constraints and
> KM.auxiliary_eqs just not work together?
> I attach some code, showing my problem.
>
> *Any help is greatly appreciated!*
>
> --
> 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/e8091bb4-9730-4dc2-8e31-59662ef09e56n%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 sympy+un...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/sympy/5b2301f3-8dc7-4e69-9a52-31f5d235daban%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 sympy+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/aa252785-8644-40a6-afe9-c7a817388500n%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AiNUGcpQx-8X4xoZp0ezT7%2Bgm_q8ZZpKmTwTGYix9qiGA%40mail.gmail.com.

Re: [sympy] sympy.physcis.mechanics // reaction force

[Jason Moore]

Peter,

If you have a particle that is forced to move along a path (typically be a
configuration constraint), then there exists reaction forces normal to the
path that keep it on the path. These forces are not present in the
equations of motion when they are formed with minimal coordinates. But you
can expose the forces by introducing fictitious (auxiliary) generalized
speeds normal to the path and a variable for the forces. This will result
in the minimal equations of motion and some algebraic equations for the
forces. All of these equations will have the aux speeds, which then must be
set to zero because they are fictitious. This should then leave you with
the equations of motion plus some equations that can be solved for the
forces.

Jason
moorepants.info
+01 530-601-9791


On Thu, Feb 3, 2022 at 10:03 AM Peter Stahlecker 
wrote:

> Thanks! Would I also set the 'reaction forces' appearing in the force term
> equal to zero?
> As per my understanding of mechanics, they also should have no influence
> on the equations of motion (?)
>
> moore...@gmail.com schrieb am Donnerstag, 3. Februar 2022 um 09:59:53
> UTC+1:
>
>> The virtual speeds will appear in the force equations, but you then just
>> set them to zero because they are fictitious. You force equation should
>> then be correct.
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791 <(530)%20601-9791>
>>
>>
>> On Thu, Feb 3, 2022 at 9:58 AM Peter Stahlecker 
>> wrote:
>>
>>> When I use a velocity constraint to force a particle not to move in a
>>> certain direction, there must be a 'reaction force' on the particle.
>>> I use KM.auxiliary_eqs to find reaction forces, which works very well in
>>> general!
>>>
>>> However,  if I try to find the reaction force due to a velocity
>>> constraint, it does no seem to work:
>>> The force term of the equations of motion contains the 'virtual speed',
>>> its time derivative and the reaction force.
>>>
>>> Am I doing something wrong, or do velocity_constraints and
>>> KM.auxiliary_eqs just not work together?
>>> I attach some code, showing my problem.
>>>
>>> *Any help is greatly appreciated!*
>>>
>>> --
>>> 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/e8091bb4-9730-4dc2-8e31-59662ef09e56n%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 sympy+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/5b2301f3-8dc7-4e69-9a52-31f5d235daban%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AiA-TgERBjfQiEqtZuneSB0r_NmzaYH19t8Y14nAQqOYA%40mail.gmail.com.

Re: [sympy] sympy.physcis.mechanics // reaction force

[Jason Moore]

The virtual speeds will appear in the force equations, but you then just
set them to zero because they are fictitious. You force equation should
then be correct.

Jason
moorepants.info
+01 530-601-9791


On Thu, Feb 3, 2022 at 9:58 AM Peter Stahlecker 
wrote:

> When I use a velocity constraint to force a particle not to move in a
> certain direction, there must be a 'reaction force' on the particle.
> I use KM.auxiliary_eqs to find reaction forces, which works very well in
> general!
>
> However,  if I try to find the reaction force due to a velocity
> constraint, it does no seem to work:
> The force term of the equations of motion contains the 'virtual speed',
> its time derivative and the reaction force.
>
> Am I doing something wrong, or do velocity_constraints and
> KM.auxiliary_eqs just not work together?
> I attach some code, showing my problem.
>
> *Any help is greatly appreciated!*
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/e8091bb4-9730-4dc2-8e31-59662ef09e56n%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AhH-qNnwFcYELWJyrEMJ4V0np5-KixUgnQ8GJSicujnwA%40mail.gmail.com.

[sympy] Postdoctoral Researcher Opening: Advancing Biomechanical Modeling By Improving SymPy Code Generation (x/f/m)

[Jason Moore]

Hi,

We are hiring a postdoctoral researcher at TU Delft as part of SymPy's
recent CZI grant.

*Applications are due February 28, 2022*

Info @ https://mechmotum.github.io/blog/sympy-czi-postdoc.html

Please spread the word!

Jason
moorepants.info
+01 530-601-9791

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AhqMRyP%3DLymdT-ebAW4dPh8u0cBXaLQ7D9Jn9Cm3-U5dQ%40mail.gmail.com.

Re: [sympy] Sympy physics mechanics

[Jason Moore]

Peter,

The ideal way to do this is to paste the code into the email or in a Github
discussion. Making the code as short as possible to demonstrate the issues
is also helpful.

Here is a good example: https://github.com/sympy/sympy/discussions/22848

Jason
moorepants.info
+01 530-601-9791


On Sat, Jan 29, 2022 at 11:07 AM Peter Stahlecker <
peter.stahlec...@gmail.com> wrote:

> Dear Jason,
> I had to send it by separate mail, as I di not know how to attach a file
> to gmail.
> Thanks, Peter
>
> On Sat 29. Jan 2022 at 15:48, Jason Moore  wrote:
>
>> Peter,
>>
>> You'll have to share your code for us to help, as this isn't enough
>> information.
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791
>>
>>
>> On Sat, Jan 29, 2022 at 9:50 AM Peter Stahlecker <
>> peter.stahlec...@gmail.com> wrote:
>>
>>> I try to model a simple one mass point pendulum in 3D, the mass point is
>>> located on the y - axis, at a distance d. Rotations around the y-axis do
>>> not make physical sense, hence, I use only qx, qz to describe the angles of
>>> rotation of the frame of m.
>>>
>>> If MM is the mass matrix, I get determinant(M) = 0.
>>> As this pendulum is so simple, I do not think I made a mistake modeling
>>> it.
>>> What could be the problem?
>>>
>>> Thanks for any help!
>>>
>> --
>>> 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 discussion on the web visit
>>> https://groups.google.com/d/msgid/sympy/44eb551f-453a-47a6-ba23-335b32fd15e9n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/sympy/44eb551f-453a-47a6-ba23-335b32fd15e9n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> 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 discussion on the web visit
>> https://groups.google.com/d/msgid/sympy/CAP7f1AhLe%2Bz2%3DH-0oEt%3DOeKYrjf%2B4LWN_zArxPc1sF2yu7jypg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/sympy/CAP7f1AhLe%2Bz2%3DH-0oEt%3DOeKYrjf%2B4LWN_zArxPc1sF2yu7jypg%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> Best regards,
>
> Peter Stahlecker
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CABKqA0YJ9Oa6TQy%2BMDuBGP6FqduhRjfGJKDkz7czMRKz1qrDTQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/sympy/CABKqA0YJ9Oa6TQy%2BMDuBGP6FqduhRjfGJKDkz7czMRKz1qrDTQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Ai_8qmJjpUTp%3DYrD6_cii4veTm6uC7kr05BMQxva-grqQ%40mail.gmail.com.

Re: [sympy] Sympy physics mechanics

[Jason Moore]

Peter,

You'll have to share your code for us to help, as this isn't enough
information.

Jason
moorepants.info
+01 530-601-9791


On Sat, Jan 29, 2022 at 9:50 AM Peter Stahlecker 
wrote:

> I try to model a simple one mass point pendulum in 3D, the mass point is
> located on the y - axis, at a distance d. Rotations around the y-axis do
> not make physical sense, hence, I use only qx, qz to describe the angles of
> rotation of the frame of m.
>
> If MM is the mass matrix, I get determinant(M) = 0.
> As this pendulum is so simple, I do not think I made a mistake modeling it.
> What could be the problem?
>
> Thanks for any help!
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/44eb551f-453a-47a6-ba23-335b32fd15e9n%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AhLe%2Bz2%3DH-0oEt%3DOeKYrjf%2B4LWN_zArxPc1sF2yu7jypg%40mail.gmail.com.

Re: [sympy] Buggy kinematics for serial chain manipulators

[Jason Moore]

Ashwin,

The Joints module was added recently and may very well have bugs. The Joint
formulation should produce the same results as
https://pydy.readthedocs.io/en/latest/examples/multidof-holonomic.html. I
don't remember precisely but it should have generated the same results when
we merged in the new functionality.

The calls to v2pt_theory() in PinJoint should be applied on any points that
are moving in the frame/body. Please open an issue on Github and report a
reproducible example there that demonstrates the bug.

Thanks,

Jason
moorepants.info
+01 530-601-9791


On Fri, Jan 21, 2022 at 3:45 PM Ashwin Khadke  wrote:

> I am trying out the serial chain manipulator example
> 
> in the sympy mechanics docs but am finding out that the kinematics sympy
> computes in the backend are buggy. I am attaching the file I use to test
> it. In the example
> ,
> the velocity of the center of mass of the simple pendulum *should be :
> u1(t)*N_frame.x + l*u2(t)*B_frame.x + l*(u2(t) + u3(t))*C_frame.x*.
> However, *sympy returns : u1(t)*N_frame.x + l*u3(t)/3*B_frame.x +
> l*u3(t)*C_frame.x*.
>
> I tried to investigate this by looking at the definition of a PinJoint in
> sympy. It turns out every joint, when initialized calls the
> *_set_linear_velocity* function. In case of the PinJoint the
> *_set_linear_velocity* function calls 
> *child.masscenter.v2pt_theory(parent.masscenter,
> parent.frame, child.frame)* to impose velocity constraints between the
> child and parent link mass centers. The v2pt_theory function operates under
> the assumption that child and parent mass centers are fixed in the child
> frame (frame attached to the center of mass of the child). This would hold
> true if the parent link has mass concentrated at one end (or at the joint
> i.e. COM and joint location coincide) but not if the joint location is
> anywhere other than the COM of the parent link.
>
> Is there a way to define a serial chain manipulator in sympy without
> making such assumptions about the mass distribution of the links?
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/c4d9c1aa-49b3-44b5-81a9-d794e26e2c86n%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Ag3dOzUoqL4_FDzYF0y9A86cWvhy5Q79scrn5RmkSBU1Q%40mail.gmail.com.

Re: [sympy] How to get started with contributions?

[Jason Moore]

David,

Here is our introductory information:
https://github.com/sympy/sympy/wiki/introduction-to-contributing

Jason
moorepants.info
+01 530-601-9791


On Thu, Jan 6, 2022 at 8:48 PM David Dai  wrote:

> Hi everyone,
> My name is Jingze Dai and I am a CS student from McMaster University,
> Canada. I want to be a developer in the sympy group. But I do not know
> after learning, where should I get started? Can anyone give me some
> suggestions?
> Thank you so much
>
> Sincerely
> David
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/ec39468a-7d9c-4ea6-8d2c-fdc3be0ec1f2n%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AifpboGVfsesFaLJ7rEhVLVXPpUrJz_SMJG-jPG2bYKdw%40mail.gmail.com.

Re: [sympy] SymPEP: make MatchPy a SymPy dependency

[Jason Moore]

I think we should relax our stringent no dependency stance for pure python
dependencies. Pure python dependency management is essentially solved now
for the python ecosystem with the various package managers. This dependency
would also be pulled into the sympy organization, so we will have just as
much control to maintain it as code in sympy's codebase.

Francesco is a long time valued contributor and if he wants/needs matchpy
to help him make sympy better, then we should enable him to do that.
Putting up a wall here likely only creates frustration and demotivation.
There is likely more value in unleashing Francesco's matchpy improvements
to sympy than any devalue adding a dependency to sympy creates.

Jason
moorepants.info
+01 530-601-9791


On Wed, Oct 6, 2021 at 9:38 AM Francesco Bonazzi 
wrote:

>
>
> On Tuesday, October 5, 2021 at 2:07:06 p.m. UTC+2 Oscar wrote:
>
>>
>> I agree that pattern matching is a crucial part of a CAS and should
>> really be the core of SymPy. If I was redesigning SymPy from scratch then
>> everything would be built on top of a pattern-matching engine and almost
>> all of the logic from the myriad Basic subclasses would just be written as
>> pattern rules. My equivalent of SymEngine would just be a C implementation
>> of the pattern-matching engine rather than a repeat of the object-oriented
>> design of SymPy.
>>
>
> SymPy can still be modified in order to use a pattern matcher.
>
> Also, MatchPy has been partly translated into C++ inside the SymEngine
> project:
>
> https://github.com/symengine/symengine/tree/329a04be017daff0362b9177da2ef5b7e5d605f7/symengine/utilities/matchpycpp
>
>
>>
>> I also agree that matchpy looks like a good implementation of
>> pattern-matching and it makes sense for it to be usable with SymPy. What
>> the SymPEP does not address though is what benefit is gained for users by
>> making matchpy a non-optional dependency. The examples shown look like
>> somewhat specialised usage for which an interested user could just choose
>> to install matchpy.
>>
>
> The benefits are mostly for SymPy development. You can start defining
> replacement rules to implement new algorithms.
>
>
>> RUBI would be a good motivation but as far as I can tell RUBI does not
>> yet work. Actually I would prefer it if RUBI was already in a separate
>> package from SymPy - it should not have been merged until it was at least
>> partially working. The rubi_tests folder is included for all users and
>> includes e.g. the sympy/integrals/rubi/rubi_tests/tests/test_trinomials.py
>> file which wastes at least 1.5MB disk space for every single SymPy user for
>> precisely zero benefit (these tests should clearly be in a separate repo).
>> I don't see how making matchpy a non-optional dependency would make it any
>> easier to improve RUBI since anyone who wants to work on it can just
>> install matchpy. In fact if RUBI was not in the main SymPy repo then it
>> could have a hard dependency on matchpy.
>>
>
> This can be done.
>
>
>> The cost of making matchpy a non-optional dependency would be felt by
>> downstream distributors of SymPy who would then have an additional
>> dependency to include. It would also be felt by all users of SymPy with
>> longer install time, more disk space etc. If a user does not use any of
>> it's features then this cost comes with no benefit.
>>
>
> Consider that it's pretty common now for libraries to depend on other
> libraries. An alternative would be to copy the MatchPy project as a
> subfolder inside SymPy (as it has been done for the *multipledispatch*
>  module).
>
>
>> I am not saying this to disagree with the proposal but that there needs
>> to be a clear rationale for making matchpy a hard dependency and the SymPEP
>> does not address this at all. The SymPEP should also clearly spell out what
>> the downsides of the proposal are.
>>
>
> The major downside is probably that MatchPy has not been extensively
> tested with SymPy. There is a risk factor in relying on a new library.
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/003f5fd9-8137-40eb-a8a6-ca2378a08ccan%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AhfqzVwWoqbZosP_uXoM%2BJkw9z5LuvAtXKi0feb5zg8vQ%40mail.gmail.com.

Re: [sympy] A Taylor integrator compatible with SymPy

[Jason Moore]

Francesco,

I'm prepping a new course I teach at TU Delft in multibody dynamics and one
week is about numerical integration. I'll try things out when I'm working
on those lessons.

Jason
moorepants.info
+01 530-601-9791


On Fri, Oct 1, 2021 at 9:29 AM Francesco Biscani 
wrote:

> Hi Jason,
>
> cheers! The interoperability with SymPy and its mechanics module is a work
> in progress, so please let me know what you think we could improve on.
>
> Kind regards,
>
>   Francesco.
>
> On Fri, 1 Oct 2021 at 09:12, Jason Moore  wrote:
>
>> Hi,
>>
>> Thanks for sharing. I'll try it out with some other mechanics problems.
>> Looks nice!
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791
>>
>>
>> On Wed, Sep 29, 2021 at 11:23 PM Francesco Biscani 
>> wrote:
>>
>>> Hello,
>>>
>>> we just released the latest version of our Taylor integrator heyoka.py:
>>>
>>> https://github.com/bluescarni/heyoka.py
>>>
>>> heyoka.py is an implementation of Taylor's method for the numerical
>>> integration of systems of ODEs based on automatic differentiation and
>>> just-in-time compilation via LLVM.
>>>
>>> Current features include:
>>>
>>> - support for both double-precision and extended-precision
>>> floating-point types,
>>> - the ability to maintain machine precision accuracy over tens of
>>> billions of timesteps,
>>> - high-precision zero-cost dense output,
>>> - accurate and reliable event detection,
>>> - excellent performance,
>>> - batch mode integration to harness the power of modern SIMD instruction
>>> sets.
>>>
>>> heyoka.py needs to represent the ODEs symbolically in order to apply the
>>> automatic differentiation rules necessary for an efficient implementation
>>> of Taylor's method. For this purpose, heyoka.py uses its own expression
>>> system, but in recent versions we added the ability to convert heyoka.py's
>>> symbolic expressions to/from SymPy. Here's a simple example of
>>> interoperability between heyoka.py and SymPy:
>>>
>>> https://bluescarni.github.io/heyoka.py/notebooks/sympy_interop.html
>>>
>>> Here instead is a non-trivial example where the equations of motion are
>>> formulated via SymPy's classical mechanics module and then integrated via
>>> heyoka.py:
>>>
>>> https://bluescarni.github.io/heyoka.py/notebooks/tides_spokes.html
>>>
>>> This second example also shows how the common subexpression elimination
>>> capabilities of heyoka.py were able to drastically simplify highly-complex
>>> Lagrangian equations.
>>>
>>> As a long-time observer/user of SymPy, I thought that other SymPy users
>>> might find this project interesting. I am also looking for feedback on our
>>> SymPy conversions facilities, as this is my first time digging into the
>>> SymPy expression system internals.
>>>
>>> Thanks and kind regards,
>>>
>>>   Francesco
>>>
>>> --
>>> 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 discussion on the web visit
>>> https://groups.google.com/d/msgid/sympy/CAHExjCv%3DwxH6ZRpkkMqJDMmXg-h1Q43Q5dZq4ahYcGE8MGfFHA%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/sympy/CAHExjCv%3DwxH6ZRpkkMqJDMmXg-h1Q43Q5dZq4ahYcGE8MGfFHA%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> 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 discussion on the web visit
>> https://groups.google.com/d/msgid/sympy/CAP7f1Aj2cFtgQBS_5oqPoEq9DCyF%2BJfZRr-W3UaLi_WfBaPNag%40mail.gmail.com
>> <https://groups.google.com/d/msgid/sympy/CAP7f1Aj2cFtgQBS_5oqPoEq9DCyF%2BJfZRr-W3UaLi_WfBaPNag%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAHExjCuG0Z_nP-7Q3Tba%2B_3KfB2K%2B1TJQZOZoSNB3mtxdw498A%40mail.gmail.com
> <https://groups.google.com/d/msgid/sympy/CAHExjCuG0Z_nP-7Q3Tba%2B_3KfB2K%2B1TJQZOZoSNB3mtxdw498A%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AjAukR1k1jGucmULgbzDjvcZFFuvqHxbHxCMHnp3Z7boA%40mail.gmail.com.

Re: [sympy] A Taylor integrator compatible with SymPy

[Jason Moore]

Hi,

Thanks for sharing. I'll try it out with some other mechanics problems.
Looks nice!

Jason
moorepants.info
+01 530-601-9791


On Wed, Sep 29, 2021 at 11:23 PM Francesco Biscani 
wrote:

> Hello,
>
> we just released the latest version of our Taylor integrator heyoka.py:
>
> https://github.com/bluescarni/heyoka.py
>
> heyoka.py is an implementation of Taylor's method for the numerical
> integration of systems of ODEs based on automatic differentiation and
> just-in-time compilation via LLVM.
>
> Current features include:
>
> - support for both double-precision and extended-precision floating-point
> types,
> - the ability to maintain machine precision accuracy over tens of billions
> of timesteps,
> - high-precision zero-cost dense output,
> - accurate and reliable event detection,
> - excellent performance,
> - batch mode integration to harness the power of modern SIMD instruction
> sets.
>
> heyoka.py needs to represent the ODEs symbolically in order to apply the
> automatic differentiation rules necessary for an efficient implementation
> of Taylor's method. For this purpose, heyoka.py uses its own expression
> system, but in recent versions we added the ability to convert heyoka.py's
> symbolic expressions to/from SymPy. Here's a simple example of
> interoperability between heyoka.py and SymPy:
>
> https://bluescarni.github.io/heyoka.py/notebooks/sympy_interop.html
>
> Here instead is a non-trivial example where the equations of motion are
> formulated via SymPy's classical mechanics module and then integrated via
> heyoka.py:
>
> https://bluescarni.github.io/heyoka.py/notebooks/tides_spokes.html
>
> This second example also shows how the common subexpression elimination
> capabilities of heyoka.py were able to drastically simplify highly-complex
> Lagrangian equations.
>
> As a long-time observer/user of SymPy, I thought that other SymPy users
> might find this project interesting. I am also looking for feedback on our
> SymPy conversions facilities, as this is my first time digging into the
> SymPy expression system internals.
>
> Thanks and kind regards,
>
>   Francesco
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAHExjCv%3DwxH6ZRpkkMqJDMmXg-h1Q43Q5dZq4ahYcGE8MGfFHA%40mail.gmail.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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Aj2cFtgQBS_5oqPoEq9DCyF%2BJfZRr-W3UaLi_WfBaPNag%40mail.gmail.com.

Re: [sympy] Adding functions in sympy.physics.quantum

[Jason Moore]

Prathamesh,

No one is currently maintaining the quantum code in sympy. I'm sure
everyone would welcome some attention to it. Feel free to submit a PR.

Jason
moorepants.info
+01 530-601-9791


On Tue, Jul 27, 2021 at 2:55 PM prathamesh bhole <
prathameshbhol...@gmail.com> wrote:

> My name is Prathamesh Bhole, I am currently pursuing my master's degree in
> Quantum Computing.
> I found that there's todo list in sympy.physics.quantum.qubit.py
> regarding implementation of measurement logic. Well I have created a code
> that can do measure_all function and I have also created an qiskit like
> interface to perform different quantum gate operations which is purely
> based on sympy. If sympy group is interested in adding it to sympy library,
> kindly let me know by replying to this email. Thanks and regards.
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAEiKfHkTkezxnBcVJkjRsLu-Ksvr-domTUrnorUbq3UDVXPOvQ%40mail.gmail.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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AgmMFndUhgkvFFvv_SaZ5yO0CAMLdzjaUZd_J2SShQgMg%40mail.gmail.com.

Re: [sympy] Common shape with lambdify on Matrix expression

[Jason Moore]

Hanno,

Yes, you are right, I didn't look closely at your example. I'm not sure of
the fix off the top of my head.

Jason
moorepants.info
+01 530-601-9791


On Mon, Jul 19, 2021 at 1:07 PM Hanno Klemm  wrote:

> Hi Jason,
> thanks for your reply.
>
> I don’t understand how squeeze could help me here.
>
> I want both results coming from sympy to be of shape (n,), so that the
> overall result is (2,n) in the example. I don’t think that can be
> accomplished with squeeze.
>
> Best,
> Hanno
>
> On 19. Jul 2021, at 13:02, Jason Moore  wrote:
>
> 
> Numpy's squeeze function/method is often helpful for this:
> https://numpy.org/doc/stable/reference/generated/numpy.squeeze.html
>
> Jason
> moorepants.info
> +01 530-601-9791
>
>
> On Mon, Jul 19, 2021 at 12:15 PM h.k...@gmx.de  wrote:
>
>> Hi,
>>
>> I am a new user of sympy, and my question might be obvious, but I haven't
>> found anything on the docs or on stackoverflow:
>>
>> I try to use sympy to create some algebraic matrix expressions, that I
>> want to lambdify at the end to evaluate on numerical arrays. The issue that
>> I am currently running into is that some elements of the matrix might be
>> exactly zero.
>>
>> If I know want to evaluate this lmabdified expression over a numpy array
>> of shape (m,n), the resulting expression has two different shapes, namely
>> (m,n) wherever there was an expression to evaluate and (1,), where there
>> was zero.
>>
>> Is it possible to "force" a common shape when returning the lamdified
>> results of a Matrix expression?
>>
>> For example:
>>
>> import numpy as np
>> import sympy as sym
>> from sympy.abc import k
>>
>> matrix_expr = sym.Matrix((1-sym.exp(-k), 0))
>> expr = sym.lambdify(k, matrix_expr)
>> print(expr(np.linspace(0,1,11)))
>>
>> gives me:
>>
>> :2: VisibleDeprecationWarning: Creating an ndarray
>> from ragged nested sequences (which is a list-or-tuple of
>> lists-or-tuples-or ndarrays with different lengths or shapes) is
>> deprecated. If you meant to do this, you must specify 'dtype=object' when
>> creating the ndarray
>>   return (array([[1 - exp(-k)], [0]]))
>> Out[4]:
>> array([[array([0., 0.09516258, 0.18126925, 0.25918178, 0.32967995,
>>0.39346934, 0.45118836, 0.5034147 , 0.55067104, 0.59343034,
>>0.63212056])],
>>[0]], dtype=object)
>>
>> Is it possible to "force" the second component to have the same shape as
>> the first?
>>
>> Thanks,
>> Hanno
>>
>> --
>> 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 discussion on the web visit
>> https://groups.google.com/d/msgid/sympy/599b7aff-a7fc-45cf-b134-6f06cf566706n%40googlegroups.com
>> <https://groups.google.com/d/msgid/sympy/599b7aff-a7fc-45cf-b134-6f06cf566706n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAP7f1AiX%3D9qf5fpbG-c%3DGfnF71f%3DUGrmH1V-qaptG4c7sNg7tg%40mail.gmail.com
> <https://groups.google.com/d/msgid/sympy/CAP7f1AiX%3D9qf5fpbG-c%3DGfnF71f%3DUGrmH1V-qaptG4c7sNg7tg%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/45BECF92-DC5F-4EF3-958B-A02E4D0E4FE5%40gmx.de
> <https://groups.google.com/d/msgid/sympy/45BECF92-DC5F-4EF3-958B-A02E4D0E4FE5%40gmx.de?utm_medium=email_source=footer>
> .
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AgQzvVVbeEd12Gow9B43p%3DF0RMTrJFFNgc01XpeSO3u7A%40mail.gmail.com.

Re: [sympy] Common shape with lambdify on Matrix expression

[Jason Moore]

Numpy's squeeze function/method is often helpful for this:
https://numpy.org/doc/stable/reference/generated/numpy.squeeze.html

Jason
moorepants.info
+01 530-601-9791


On Mon, Jul 19, 2021 at 12:15 PM h.k...@gmx.de  wrote:

> Hi,
>
> I am a new user of sympy, and my question might be obvious, but I haven't
> found anything on the docs or on stackoverflow:
>
> I try to use sympy to create some algebraic matrix expressions, that I
> want to lambdify at the end to evaluate on numerical arrays. The issue that
> I am currently running into is that some elements of the matrix might be
> exactly zero.
>
> If I know want to evaluate this lmabdified expression over a numpy array
> of shape (m,n), the resulting expression has two different shapes, namely
> (m,n) wherever there was an expression to evaluate and (1,), where there
> was zero.
>
> Is it possible to "force" a common shape when returning the lamdified
> results of a Matrix expression?
>
> For example:
>
> import numpy as np
> import sympy as sym
> from sympy.abc import k
>
> matrix_expr = sym.Matrix((1-sym.exp(-k), 0))
> expr = sym.lambdify(k, matrix_expr)
> print(expr(np.linspace(0,1,11)))
>
> gives me:
>
> :2: VisibleDeprecationWarning: Creating an ndarray
> from ragged nested sequences (which is a list-or-tuple of
> lists-or-tuples-or ndarrays with different lengths or shapes) is
> deprecated. If you meant to do this, you must specify 'dtype=object' when
> creating the ndarray
>   return (array([[1 - exp(-k)], [0]]))
> Out[4]:
> array([[array([0., 0.09516258, 0.18126925, 0.25918178, 0.32967995,
>0.39346934, 0.45118836, 0.5034147 , 0.55067104, 0.59343034,
>0.63212056])],
>[0]], dtype=object)
>
> Is it possible to "force" the second component to have the same shape as
> the first?
>
> Thanks,
> Hanno
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/599b7aff-a7fc-45cf-b134-6f06cf566706n%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AiX%3D9qf5fpbG-c%3DGfnF71f%3DUGrmH1V-qaptG4c7sNg7tg%40mail.gmail.com.

Re: [sympy] Rotating a body in 3D

[Jason Moore]

Peter,

Feel free to open an issue on the sympy github repository with precise
instructions on reproducing this and we can look into it.

Jason
moorepants.info
+01 530-601-9791


On Tue, Jun 29, 2021 at 2:45 PM Peter Stahlecker 
wrote:

> Dear Jason,
>
> Maybe it is not 'Body' vs. 'Axis', but my clumpsy programming!
> The results look reasonable, but maybe my kinematic equatios are clumsy
> or?
>
> Take care!
>
> Peter
>
> On Tue 29. Jun 2021 at 15:24, Jason Moore  wrote:
>
>> Peter,
>>
>> Sounds like that could use some improvements. I'm not sure why the body
>> fixed rotations are so much worse.
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791
>>
>>
>> On Tue, Jun 29, 2021 at 1:00 PM Peter Stahlecker <
>> peter.stahlec...@gmail.com> wrote:
>>
>>> Dear Jason,
>>>
>>> Thanks!
>>> I tested it right away, and I counted the operations of an entry of rhs
>>> = KM.rhs()
>>>
>>> For ‚Body‘ I got the count 245,633
>>> With the auxiliary frames the count was 13,235
>>>
>>> Thanks again and stay healthy!
>>>
>>> I will keep on testing this.
>>>
>>> Peter
>>>
>>>
>>>
>>>
>>> On Tue 29. Jun 2021 at 12:32 Jason Moore  wrote:
>>>
>>>> Peter,
>>>>
>>>> THey are equivalent other than one may provide a simpler set of
>>>> direction cosine matrices and angular velocity definitions. The "Body"
>>>> method should give simpler equations of motion in the end because we try to
>>>> use pre-simplified forms of the equations. I don't know why you'd see
>>>> faster with the intermediate frame method.
>>>>
>>>> You can use sympy's count_ops() function to see how many operations
>>>> each symbolic form gives. The one with more operations should ultimately be
>>>> slower when lambdified().
>>>>
>>>> Jason
>>>> moorepants.info
>>>> +01 530-601-9791
>>>>
>>>>
>>>> On Tue, Jun 29, 2021 at 5:09 AM Peter Stahlecker <
>>>> peter.stahlec...@gmail.com> wrote:
>>>>
>>>>> When I want to do this, it seems to me there are these possibilities:
>>>>>
>>>>> 1.
>>>>> A = N.orientnew(‚A‘, ‚Body‘, [q1, q2, q3], ‚123‘)
>>>>> This does it in one step
>>>>>
>>>>> 2.
>>>>> I use two intermediate frames and use the word ‚Axis‘ instead of ‚Body‘
>>>>>
>>>>> Geometrically, this should be the same, but it seems to me, that with
>>>>> the intermediate frames establishing Kane‘s equations, lambdifying them 
>>>>> and
>>>>> doing the numerical integration is MUCH faster.
>>>>>
>>>>> Are methods 1 and 2 not equivalent, as I assumed, or am I doing
>>>>> something wrong?
>>>>>
>>>>> Thanks for any explanation!
>>>>>
>>>>> --
>>>>> 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 discussion on the web visit
>>>>> https://groups.google.com/d/msgid/sympy/d1597154-f8a8-42fa-b29b-6e8f57062441n%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/sympy/d1597154-f8a8-42fa-b29b-6e8f57062441n%40googlegroups.com?utm_medium=email_source=footer>
>>>>> .
>>>>>
>>>> --
>>>> 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 discussion on the web visit
>>>> https://groups.google.com/d/msgid/sympy/CAP7f1AhvTHkfn8_Wc7L9i7em3QvDHn6MPBHoWwqvK9qOUw3QfA%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/sympy/CAP7f1AhvTHkfn8_Wc7L9i7em3QvDHn6MPBHoWwqvK9qOUw3QfA%40mail.gmail.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> --
>>> Best regards,
>>>
>>> Peter Stahlecker
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "sympy" group.
&

Re: [sympy] Rotating a body in 3D

[Jason Moore]

Oscar,

There are essentially two approaches in computational multibody dynamics to
arrive at the equations of motion: symbolic first (what SymPy does) or
fully numeric (tools like Simbody, Bullet, etc.). You have to calculate
derivatives with respect to the coordinates of the system to get Newton and
Euler's dynamical equations, thus having the symbolic expressions is one
way to calculate those derivatives. The rotations have to be parameterized
symbolically for this approach. This is how sympy.physics.mechanics works.
The rotations can be designed as quaternions, Euler angles, Rodriguez
parameters, Euler parameters, or many other ways, but you still have to
compute the derivatives of these symbolically parameterized rotations.

Peter's number of operations is very small compared to many other more
complicated multibody problems.

Jason
moorepants.info
+01 530-601-9791


On Tue, Jun 29, 2021 at 1:09 PM Oscar Benjamin 
wrote:

> How do the op counts get into the tens or hundreds of thousands?
>
> When the expressions are that complicated I would have thought that it
> was faster and more numerically accurate to perform whatever symbolic
> operations are used to obtain those expressions using numerical
> routines. For example if a matrix is inverted symbolically it would be
> better to substitute your values and invert the matrix numerically
> etc. A 3D rotation can be computed very cheaply in floating point with
> quaternions.
>
> --
> Oscar
>
> On Tue, 29 Jun 2021 at 12:00, Peter Stahlecker
>  wrote:
> >
> > Dear Jason,
> >
> > Thanks!
> > I tested it right away, and I counted the operations of an entry of rhs
> = KM.rhs()
> >
> > For ‚Body‘ I got the count 245,633
> > With the auxiliary frames the count was 13,235
> >
> > Thanks again and stay healthy!
> >
> > I will keep on testing this.
> >
> > Peter
> >
> >
> >
> >
> > On Tue 29. Jun 2021 at 12:32 Jason Moore  wrote:
> >>
> >> Peter,
> >>
> >> THey are equivalent other than one may provide a simpler set of
> direction cosine matrices and angular velocity definitions. The "Body"
> method should give simpler equations of motion in the end because we try to
> use pre-simplified forms of the equations. I don't know why you'd see
> faster with the intermediate frame method.
> >>
> >> You can use sympy's count_ops() function to see how many operations
> each symbolic form gives. The one with more operations should ultimately be
> slower when lambdified().
> >>
> >> Jason
> >> moorepants.info
> >> +01 530-601-9791
> >>
> >>
> >> On Tue, Jun 29, 2021 at 5:09 AM Peter Stahlecker <
> peter.stahlec...@gmail.com> wrote:
> >>>
> >>> When I want to do this, it seems to me there are these possibilities:
> >>>
> >>> 1.
> >>> A = N.orientnew(‚A‘, ‚Body‘, [q1, q2, q3], ‚123‘)
> >>> This does it in one step
> >>>
> >>> 2.
> >>> I use two intermediate frames and use the word ‚Axis‘ instead of ‚Body‘
> >>>
> >>> Geometrically, this should be the same, but it seems to me, that with
> the intermediate frames establishing Kane‘s equations, lambdifying them and
> doing the numerical integration is MUCH faster.
> >>>
> >>> Are methods 1 and 2 not equivalent, as I assumed, or am I doing
> something wrong?
> >>>
> >>> Thanks for any explanation!
> >>>
> >>> --
> >>> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/d1597154-f8a8-42fa-b29b-6e8f57062441n%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 sympy+unsubscr...@googlegroups.com.
> >> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAP7f1AhvTHkfn8_Wc7L9i7em3QvDHn6MPBHoWwqvK9qOUw3QfA%40mail.gmail.com
> .
> >
> > --
> > Best regards,
> >
> > Peter Stahlecker
> >
> > --
> > 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+

Re: [sympy] Rotating a body in 3D

[Jason Moore]

Peter,

Sounds like that could use some improvements. I'm not sure why the body
fixed rotations are so much worse.

Jason
moorepants.info
+01 530-601-9791


On Tue, Jun 29, 2021 at 1:00 PM Peter Stahlecker 
wrote:

> Dear Jason,
>
> Thanks!
> I tested it right away, and I counted the operations of an entry of rhs =
> KM.rhs()
>
> For ‚Body‘ I got the count 245,633
> With the auxiliary frames the count was 13,235
>
> Thanks again and stay healthy!
>
> I will keep on testing this.
>
> Peter
>
>
>
>
> On Tue 29. Jun 2021 at 12:32 Jason Moore  wrote:
>
>> Peter,
>>
>> THey are equivalent other than one may provide a simpler set of direction
>> cosine matrices and angular velocity definitions. The "Body" method should
>> give simpler equations of motion in the end because we try to use
>> pre-simplified forms of the equations. I don't know why you'd see faster
>> with the intermediate frame method.
>>
>> You can use sympy's count_ops() function to see how many operations each
>> symbolic form gives. The one with more operations should ultimately be
>> slower when lambdified().
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791
>>
>>
>> On Tue, Jun 29, 2021 at 5:09 AM Peter Stahlecker <
>> peter.stahlec...@gmail.com> wrote:
>>
>>> When I want to do this, it seems to me there are these possibilities:
>>>
>>> 1.
>>> A = N.orientnew(‚A‘, ‚Body‘, [q1, q2, q3], ‚123‘)
>>> This does it in one step
>>>
>>> 2.
>>> I use two intermediate frames and use the word ‚Axis‘ instead of ‚Body‘
>>>
>>> Geometrically, this should be the same, but it seems to me, that with
>>> the intermediate frames establishing Kane‘s equations, lambdifying them and
>>> doing the numerical integration is MUCH faster.
>>>
>>> Are methods 1 and 2 not equivalent, as I assumed, or am I doing
>>> something wrong?
>>>
>>> Thanks for any explanation!
>>>
>>> --
>>> 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 discussion on the web visit
>>> https://groups.google.com/d/msgid/sympy/d1597154-f8a8-42fa-b29b-6e8f57062441n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/sympy/d1597154-f8a8-42fa-b29b-6e8f57062441n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> 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 discussion on the web visit
>> https://groups.google.com/d/msgid/sympy/CAP7f1AhvTHkfn8_Wc7L9i7em3QvDHn6MPBHoWwqvK9qOUw3QfA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/sympy/CAP7f1AhvTHkfn8_Wc7L9i7em3QvDHn6MPBHoWwqvK9qOUw3QfA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> Best regards,
>
> Peter Stahlecker
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CABKqA0bdrLLiCY7w3yG_3sPTmx7O4Z00tn-mLSssj0rvT4m9QA%40mail.gmail.com
> <https://groups.google.com/d/msgid/sympy/CABKqA0bdrLLiCY7w3yG_3sPTmx7O4Z00tn-mLSssj0rvT4m9QA%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Agxr30mQjCXBF31uH1qxr6OTJx2dL%2B6SkzNAyfNnytQEQ%40mail.gmail.com.

Re: [sympy] Rotating a body in 3D

[Jason Moore]

Peter,

THey are equivalent other than one may provide a simpler set of direction
cosine matrices and angular velocity definitions. The "Body" method should
give simpler equations of motion in the end because we try to use
pre-simplified forms of the equations. I don't know why you'd see faster
with the intermediate frame method.

You can use sympy's count_ops() function to see how many operations each
symbolic form gives. The one with more operations should ultimately be
slower when lambdified().

Jason
moorepants.info
+01 530-601-9791


On Tue, Jun 29, 2021 at 5:09 AM Peter Stahlecker 
wrote:

> When I want to do this, it seems to me there are these possibilities:
>
> 1.
> A = N.orientnew(‚A‘, ‚Body‘, [q1, q2, q3], ‚123‘)
> This does it in one step
>
> 2.
> I use two intermediate frames and use the word ‚Axis‘ instead of ‚Body‘
>
> Geometrically, this should be the same, but it seems to me, that with the
> intermediate frames establishing Kane‘s equations, lambdifying them and
> doing the numerical integration is MUCH faster.
>
> Are methods 1 and 2 not equivalent, as I assumed, or am I doing something
> wrong?
>
> Thanks for any explanation!
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/d1597154-f8a8-42fa-b29b-6e8f57062441n%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AhvTHkfn8_Wc7L9i7em3QvDHn6MPBHoWwqvK9qOUw3QfA%40mail.gmail.com.

Re: [sympy] KM.auxiliary_eqs

[Jason Moore]

Here is an example I worked on getting the contact forces for a bicycle
tires using the aux equations:

https://github.com/moorepants/pydy/blob/bicycle-tire-constraint-forces/examples/bicycle_wheel_contact_constraint_forces/whipple.py

Here is a manual method of doing aux equations too:
https://nbviewer.jupyter.org/github/moorepants/mae223/blob/master/content/lecture-notebooks/mae223-l19-01.ipynb,
KanesMethod should make the same result.

Jason
moorepants.info
+01 530-601-9791


On Sat, Jun 19, 2021 at 9:33 AM Peter Stahlecker 
wrote:

> I am playing around with this feature to get the forces acting on some
> point.
> The result of KM.auxiliary_eqs contains (also) generalized accelerations.
> I replace them with the relevant entries of KM.rhs().
> This seems to work, but it gives BIG equations for even small problems.
> Is this the correct way of doing it?
> Is there a smarter way?
>
> Thanks for any help!
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/8fa7d9a7-635b-49e1-b45b-d09aa6a10645n%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Ah4mCVQRUP8UcZkYy4tmq-M%3D_%3D2qDExROedGSMtpcLR4g%40mail.gmail.com.

Re: [sympy] Using the mechanics API

[Jason Moore]

Peter,

If you add the differential equations that describe the yaw rate,
longitudinal rate, and lateral rate to the equations found in this example,
then you can solve for the complete motion. The coordinates associated with
those equations are ignorable (from the dynamics perspective).

Jason
moorepants.info
+01 530-601-9791


On Wed, Jun 16, 2021 at 11:52 AM Peter Stahlecker <
peter.stahlec...@gmail.com> wrote:

> I have a question concerning the example 'rolling disc' in sympy-
> physics.mechanics.
> It seems to me, this is really a pendulum totation around the fixed
> contact pount C. I understand that rolling means: contact point has zero
> speed in N, but unclear to me how to get from the 'pendulum to the rolling
> disc.
> When I integrate the example numerically, it seems to confirm my feel that
> this is really a pendulum
> Thanks for any help!
>
>
>
>
> a
>
>
> I have a que
>
>
> Oscar schrieb am Mittwoch, 15. Mai 2019 um 01:29:50 UTC+2:
>
>> Hi Vishesh,
>>
>> I have no plans to work on anything here but of course you can feel
>> free to contribute. Take a look at the module and see if there is
>> something that you think can be improved. There's always something
>> that can be improved so it's just a question of finding something that
>> is worth doing and that you can do yourself.
>>
>> --
>> Oscar
>>
>> On Mon, 13 May 2019 at 21:48, Vishesh Mangla 
>> wrote:
>> >
>> > Hey,I also love physics and math and would like to work on the changes
>> which you want to include.Can I get included in this?I ‘ve chemistry as my
>> subject in university but that too deals with a lot of physics Hermitian
>> mostly but I know lagrangian too.So please let me make it. If you remember
>> you helped me merge my first pull request but still one was not enough to
>> get me enough experience to get good with it and I require help to get a
>> few more merged.
>> >
>> >
>> >
>> > Sent from Mail for Windows 10
>> >
>> >
>> >
>> > From: Oscar Benjamin
>> > Sent: 14 May 2019 02:12
>> > To: sympy
>> > Subject: [sympy] Using the mechanics API
>> >
>> >
>> >
>> > Hi all,
>> >
>> >
>> >
>> > I haven't really looked much at SymPy's mechanics module even though
>> >
>> > mechanics is very much one of my interests and something that I like
>> >
>> > to think I know a bit about. Today I finally took a look at it and I
>> >
>> > found the whole API surprisingly complicated. I teach mechanics to
>> >
>> > undergraduate students but I'm not sure if I would know how to teach
>> >
>> > my students to use the mechanics module as it is now...
>> >
>> >
>> >
>> > Firstly I looked through the documentation here:
>> >
>> > https://docs.sympy.org/latest/modules/physics/mechanics/index.html
>> >
>> > Is there any other guide/documentation that explains the general ideas
>> >
>> > more simply with examples?
>> >
>> >
>> >
>> > Suppose that I want to think about a simple 2D problem with a disc
>> >
>> > rolling down a surface inclined at angle beta with (Coulomb) friction
>> >
>> > coefficient mu. I want to know when/whether the disc will stick or
>> >
>> > slip and get the equations of motion for each case. How would I go
>> >
>> > about doing that using the mechanics module?
>> >
>> >
>> >
>> > --
>> >
>> > 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 post to this group, send email to sy...@googlegroups.com.
>> >
>> > Visit this group at https://groups.google.com/group/sympy.
>> >
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/sympy/CAHVvXxQXtAd_HGwTqaKrpDqQC_mNcyZAFgPrVe8Sq_hPwT6H0w%40mail.gmail.com.
>>
>> >
>> > For more options, visit https://groups.google.com/d/optout.
>> >
>> >
>> >
>> > --
>> > 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 post to this group, send email to sy...@googlegroups.com.
>> > Visit this group at https://groups.google.com/group/sympy.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/sympy/5cd9d817.1c69fb81.1bcd0.8bad%40mx.google.com.
>>
>> > For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/55807590-992a-41fe-b36e-0f50e3b1f415n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are 

Re: [sympy] SymPy 1.8 released

[Jason Moore]

Congrats!

Thanks to all the contributors and to Oscar for making the release!

Jason
moorepants.info
+01 530-601-9791


On Sat, Apr 10, 2021 at 1:16 AM Oscar Benjamin 
wrote:

> Hi all,
>
> It is my pleasure to announce the final release of SymPy 1.8. The
> wheel and sdist files for this release are already uploaded to pypi.
> You can install sympy 1.8 with:
>
> $ pip install -U sympy
>
> There are a lot of changes since 1.7.1. The full release notes are here:
> https://github.com/sympy/sympy/wiki/Release-Notes-for-1.8
>
> The release files are also on GitHub:
> https://github.com/sympy/sympy/releases/tag/sympy-1.8
>
> The supported Python versions for SymPy 1.8 are 3.6-3.9.
>
> Please report any issues with the release on github:
> https://github.com/sympy/sympy/issues
>
> ## Authors
>
> The following people contributed at least one patch to this release. A
> total of 152 people
> contributed to this release. People with a * by their names contributed a
> patch for the first time for this release; 102 people contributed
> for the first time for this release.
>
> Thanks to everyone who contributed to this release!
>
> - 彭于斌*
>
> - Thomas Aarholt*
> - Abhay_Dhiman*
> - Sachin Agarwal
> - Shubham Agrawal*
> - Sakirul Alam*
> - AlexCQY*
> - Abhinav Anand
> - Mohit Balwani
> - Soumi Bardhan*
> - Elias Basler*
> - Nijso Beishuizen*
> - Mark Bell*
> - Oscar Benjamin
> - Vaibhav Bhat*
> - Akshansh Bhatt*
> - Mohammed Bilal*
> - Ayush Bisht*
> - Francesco Bonazzi
> - Peter Brady
> - Kristian Brünn*
> - Ondřej Čertík
> - Hiren Chalodiya*
> - Nisarg Chaudhari*
> - Kaustubh Chaudhari*
> - Yukai Chou*
> - Peter Cock*
> - Coder-RG*
> - Lorenzo Contento*
> - Björn Dahlgren
> - Vaishnav Damani*
> - Brandon David*
> - Aaryan Dewan*
> - Roland Dixon*
> - Amanda Dsouza*
> - Shivang Dubey*
> - Harold Erbin
> - noam simcha finkelstein*
> - Micah Fitch
> - foice*
> - Garrett Folbe*
> - Fabian Froehlich*
> - Smit Gajjar
> - Wes Galbraith*
> - Mauro Garavello
> - Naman Gera
> - Sneha Goddu*
> - goddus*
> - Jose M. Gomez*
> - Nikhil Gopalam*
> - Neel Gorasiya*
> - Michael Greminger*
> - Prince Gupta*
> - Oscar Gustafsson
> - Marco Antônio Habitzreuter*
> - Sayandip Halder*
> - Achal Jain*
> - Jerry James
> - Aditya Jindal*
> - Milan Jolly
> - Yathartha Joshi
> - Ishan Joshi
> - Bhaskar Joshi*
> - Suryam Arnav Kalra*
> - KaustubhDamania*
> - Tasha Kim*
> - Sergey B Kirpichev
> - Jan Kruse*
> - Amit Kumar
> - Muskan Kumar*
> - Oliver Lee
> - S.Y. Lee
> - Qijia Liu*
> - Mathias Louboutin*
> - Rodrigo Luger*
> - Smit Lunagariya
> - Nikhil Maan
> - Mario Maio*
> - Ayush Malik*
> - Alex Malins*
> - Paul Mandel*
> - Islam Mansour*
> - Constantin Mateescu*
> - Willem Melching*
> - Dhruv Mendiratta
> - Ehren Metcalfe
> - Aaron Meurer
> - Ansh Mishra*
> - mohit
> - Markus Mohrhard*
> - Jason Moore
> - Dave Witte Morris*
> - Shital Mule*
> - Sidharth Mundhra*
> - numbermaniac*
> - Muhammed Abdul Quadir Owais*
> - Ben Payne*
> - Ilya Pchelintsev
> - Wyatt Peak*
> - Stefan Petrea*
> - Benedikt Placke*
> - Chris du Plessis*
> - Psycho-Pirate
> - Tomasz Pytel
> - Moses Paul R
> - Mayank Raj*
> - Akhil Rajput*
> - Priyansh Rathi*
> - rationa-kunal
> - Timothy Reluga
> - Faisal Riyaz
> - Praveen Sahu*
> - Naveen Sai*
> - Devesh Sawant*
> - Gilles Schintgen
> - Stan Schymanski
> - seadavis*
> - Stephan Seitz
> - Kartik Sethi*
> - Mohit Shah*
> - Sudeep Sidhu*
> - Gagandeep Singh
> - Kunal Singh*
> - Saket Kumar Singh*
> - Aditya Kumar Sinha*
> - Marijan Smetko*
> - Chris Smith
> - Jisoo Song
> - Akshat Sood*
> - soumi7*
> - Dominik Stańczak*
> - Lagaras Stelios*
> - Aaron Stiff*
> - Wolfgang Stöcher*
> - Kalevi Suominen
> - Nathan Taylor*
> - Martin Thoma
> - Rudr Tiwari*
> - Eva Tiwari*
> - Seth Troisi
> - Saanidhya vats
> - w495*
> - Ethan Ward
> - Erik Welch
> - Eric Wieser
> - Brandon T. Willard*
> - Benjamin Wolba*
> - wuyudi
> - Harshit Yadav*
> - Felix Yan*
> - Harry Zheng*
>
>
> The SHA256 hashes for the release are:
>
> 1ca588a9f6ce6a323c5592f9635159c2093572826668a1022c75c75bdf0297cb
> sympy-1.8.tar.gz
> 3b0b3776e357f789951bb14776c6a841f931680f20d5f8fe55977885657c9b7a
> sympy-1.8-py3-none-any.whl
> bb32a36da79eba72fae2705fe8a9d33ac6a6ef85dcf546e2a9ddf033c49858d6
> sympy-docs-html-1.8.zip
> 4751e449f536498b69db429ec13837472a50bb682cba54e72d4d40ee70892298
> sympy-docs-pdf-1.8.pdf(38venv)
>
>
> Oscar
>
> --
> You received this message because you a

Re: [sympy] SymPy in 10 minutes

[Jason Moore]

Some CI to ensure the notebooks run is rather important, otherwise we'll
end up with a bunch of broken notebooks over time.

That's what happened with the pydy/examples folder. Lots of stuff was
dumped in there over the years, but no CI to double check it actually runs.
Setting up at least CI in the sympy-notebooks repo would make it a
relevant, sustained, and useful resource.

Jason
moorepants.info
+01 530-601-9791


On Thu, Apr 8, 2021 at 10:27 AM Aaron Meurer  wrote:

> One of the benefits of having sympy-notebooks as a separate repository
> is that we don't necessarily need to worry about those things. I would
> be in favor of just merging things into sympy-notebooks as long as
> they look OK. We don't need to apply the same standards as the main
> repo, or at least that shouldn't block things being merged presently..
>
> Aaron Meurer
>
> On Thu, Apr 8, 2021 at 1:10 AM S.Y. Lee  wrote:
> >
> > I don't think that we can utilize sympy-notebooks repository properly
> unless we figure out how to test out the notebook outputs, integrate with
> sympy releases, matching version compatibility, and link with
> documentations.
> > Setting up this workflow is important, and once this workflow is set, I
> think that we should have a place to allow many people to collaborate
> tutorials.
> > On Wednesday, April 7, 2021 at 6:02:03 AM UTC+9 nicog...@gmail.com
> wrote:
> >>
> >> > If anyone wants to take on the work of improving the sympy-notebooks
> >> repo or adding notebooks to it, please do so.
> >>
> >> I started this with the notebook that I mentioned before. I also
> created a CSS
> >> style file.
> >>
> >> You can check the static version here:
> https://nbviewer.jupyter.org/github/nicoguaro/sympy-notebooks/blob/master/beginner/sympy_in_10_minutes.ipynb
> >>
> >> And the Binder version here:
> https://mybinder.org/v2/gh/nicoguaro/sympy-notebooks/HEAD?filepath=beginner%2Fsympy_in_10_minutes.ipynb
> >>
> >> Right now the updated version is in my fork, but I could make a PR and
> start adding the other
> >> notebooks mentioned in the thread.
> >>
> >> Nicolás
> >>
> >> On Thursday, July 2, 2020 at 2:55:52 PM UTC-5 asme...@gmail.com wrote:
> >>>
> >>> There's also https://github.com/sympy/quantum_notebooks. Those should
> >>> perhaps be moved to the sympy-notebooks repo so that we have
> >>> everything in one place.
> >>>
> >>> We might also consider moving the example notebooks in the sympy repo
> >>> over to sympy-notebooks. That would let us include the outputs as I
> >>> described, and to have them in a more standard place. We can also set
> >>> up CI on that repo so that the outputs are tested. I had thought that
> >>> the example notebooks were included with the release tarball, but
> >>> apparently they are not, so there is not a big issue with moving them,
> >>> I think.
> >>>
> >>> If anyone wants to take on the work of improving the sympy-notebooks
> >>> repo or adding notebooks to it, please do so.
> >>>
> >>> Aaron Meurer
> >>>
> >>> On Thu, Jul 2, 2020 at 1:14 PM Aaron Meurer  wrote:
> >>> >
> >>> > We also have https://github.com/sympy/sympy-notebooks, which has
> never
> >>> > really been used, but it would be nice to set it up as an example
> repo
> >>> > with notebooks, a binder link, and so on. Having it in a separate
> repo
> >>> > also means we can have notebooks that have the outputs included
> >>> > without having to worry about taking up a bunch of space in the main
> >>> > repo.
> >>> >
> >>> > Aaron Meurer
> >>> >
> >>> > On Wed, Jul 1, 2020 at 3:23 AM Oscar Benjamin
> >>> >  wrote:
> >>> > >
> >>> > > Hi Nicolás,
> >>> > >
> >>> > > This looks nice. Maybe it should go in the example notebooks:
> >>> > > https://github.com/sympy/sympy/tree/master/examples/notebooks
> >>> > >
> >>> > > I don't know if those are hosted on the website rather than just
> github.
> >>> > >
> >>> > > Oscar
> >>> > >
> >>> > > On Tue, 30 Jun 2020 at 22:11, Nicolas Guarin 
> wrote:
> >>> > > >
> >>> > > > I adapted Maxima's tutorial "Maxima in 10 minutes" to SymPy for
> one of my courses. I would like to know if you consider useful to share it
> somewhere. This is an nbviewer link:
> >>> > > >
> >>> > > >
> https://nbviewer.jupyter.org/github/nicoguaro/AdvancedMath/blob/master/notebooks/sympy/sympy_in_10_minutes.ipynb
> >>> > > >
> >>> > > > Best,
> >>> > > > Nicolás
> >>> > > >
> >>> > > > --
> >>> > > > 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/6a311d80-b7f6-4f70-a601-091e7b3a3aa5o%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 

Re: [sympy] SymPy in 10 minutes

[Jason Moore]

Using one of the jupyter<->sphinx tools is really nice for this. I've been
moving the pydy examples to work with jupyter-sphinx and you get these
results:
https://pydy.readthedocs.io/en/latest/examples/carvallo-whipple.html
(people can look at the rst source, download a notebook, or a py file and
the notebook renders with the powers of jupyter).

Ideally we add some tooling to sympy's docs so that notebooks can be
included.

Jason
moorepants.info
+01 530-601-9791


On Thu, Apr 8, 2021 at 9:10 AM S.Y. Lee  wrote:

> I don't think that we can utilize sympy-notebooks repository properly
> unless we figure out how to test out the notebook outputs, integrate with
> sympy releases, matching version compatibility, and link with
> documentations.
> Setting up this workflow is important, and once this workflow is set, I
> think that we should have a place to allow many people to collaborate
> tutorials.
> On Wednesday, April 7, 2021 at 6:02:03 AM UTC+9 nicog...@gmail.com wrote:
>
>> > If anyone wants to take on the work of improving the sympy-notebooks
>> repo or adding notebooks to it, please do so.
>>
>> I started this with the notebook that I mentioned before. I also created
>> a CSS
>> style file.
>>
>> You can check the static version here:
>> https://nbviewer.jupyter.org/github/nicoguaro/sympy-notebooks/blob/master/beginner/sympy_in_10_minutes.ipynb
>>
>> And the Binder version here:
>> https://mybinder.org/v2/gh/nicoguaro/sympy-notebooks/HEAD?filepath=beginner%2Fsympy_in_10_minutes.ipynb
>>
>> Right now the updated version is in my fork, but I could make a PR and
>> start adding the other
>> notebooks mentioned in the thread.
>>
>> Nicolás
>>
>> On Thursday, July 2, 2020 at 2:55:52 PM UTC-5 asme...@gmail.com wrote:
>>
>>> There's also https://github.com/sympy/quantum_notebooks. Those should
>>> perhaps be moved to the sympy-notebooks repo so that we have
>>> everything in one place.
>>>
>>> We might also consider moving the example notebooks in the sympy repo
>>> over to sympy-notebooks. That would let us include the outputs as I
>>> described, and to have them in a more standard place. We can also set
>>> up CI on that repo so that the outputs are tested. I had thought that
>>> the example notebooks were included with the release tarball, but
>>> apparently they are not, so there is not a big issue with moving them,
>>> I think.
>>>
>>> If anyone wants to take on the work of improving the sympy-notebooks
>>> repo or adding notebooks to it, please do so.
>>>
>>> Aaron Meurer
>>>
>>> On Thu, Jul 2, 2020 at 1:14 PM Aaron Meurer  wrote:
>>> >
>>> > We also have https://github.com/sympy/sympy-notebooks, which has
>>> never
>>> > really been used, but it would be nice to set it up as an example repo
>>> > with notebooks, a binder link, and so on. Having it in a separate repo
>>> > also means we can have notebooks that have the outputs included
>>> > without having to worry about taking up a bunch of space in the main
>>> > repo.
>>> >
>>> > Aaron Meurer
>>> >
>>> > On Wed, Jul 1, 2020 at 3:23 AM Oscar Benjamin
>>> >  wrote:
>>> > >
>>> > > Hi Nicolás,
>>> > >
>>> > > This looks nice. Maybe it should go in the example notebooks:
>>> > > https://github.com/sympy/sympy/tree/master/examples/notebooks
>>> > >
>>> > > I don't know if those are hosted on the website rather than just
>>> github.
>>> > >
>>> > > Oscar
>>> > >
>>> > > On Tue, 30 Jun 2020 at 22:11, Nicolas Guarin 
>>> wrote:
>>> > > >
>>> > > > I adapted Maxima's tutorial "Maxima in 10 minutes" to SymPy for
>>> one of my courses. I would like to know if you consider useful to share it
>>> somewhere. This is an nbviewer link:
>>> > > >
>>> > > >
>>> https://nbviewer.jupyter.org/github/nicoguaro/AdvancedMath/blob/master/notebooks/sympy/sympy_in_10_minutes.ipynb
>>> > > >
>>> > > > Best,
>>> > > > Nicolás
>>> > > >
>>> > > > --
>>> > > > 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/6a311d80-b7f6-4f70-a601-091e7b3a3aa5o%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 sympy+un...@googlegroups.com.
>>> > > To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/sympy/CAHVvXxT808Gp0yWFrmZwPgneETJC%2BSo57aAi1x2cc4SpEiR6-Q%40mail.gmail.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 sympy+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> 

Re: [sympy] GSoC Idea discussion

[Jason Moore]

Sudeep,

I do not plan to review any GSoC proposals until we are in the actual
review process. If you have specific questions you can ask on the mailing
list and we all well answer as we have time.

Jason
moorepants.info
+01 530-601-9791


On Thu, Apr 1, 2021 at 8:56 AM Sudeep Sidhu 
wrote:

> Jason,
>
> I had submitted my GSoC draft proposal a few days back on official GSoC
> page, since I'm left with just 12 days to submit the final proposal's pdf I
> was really hoping you could review my proposal so that I can submit the
> final proposal comfortably before the deadline.
> Sudeep Sidhu GSoC Proposal
> 
>
> Sudeep Sidhu
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAJUjCN%3D2tJ35-q8TDtP9ynuOL12veroncDqXgX4rrq1d_nP4dw%40mail.gmail.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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Ai3fZp6V%2BrZHqG%2B9kGHAJ_sTy9f1QmZDF8Vik5bBbXv_g%40mail.gmail.com.

Re: [sympy] PhD Looking for ideas to collaborate with Sympy.

[Jason Moore]

Patricio,

Here's our starting point for new contributors:
https://github.com/sympy/sympy/wiki/introduction-to-contributing

It sounds like you have in-depth knowledge so I'm sure you'll find nice
holes you can fill and grow.

Jason
moorepants.info
+01 530-601-9791


On Wed, Mar 31, 2021 at 3:42 PM JOSÉ PATRICIO SÁNCHEZ HERNÁNDEZ <
e.jpsanch...@go.ugr.es> wrote:

> I'm Patricio. I want to participate with the main goal of Sympy. So I want
> to collaborate to the implementation Computation of Galois groups for a
> given polynomial or I can collaborate with something else closed to my
> background. Then I'm here  looking for ideas.
>
> I have a PhD in Mathematics, specialized in modern algebra, ring theory,
> lattice theory and finite fields, a Bachelor’s degree in Applied
> Mathematics, and a Master’s degree in Science. Now I’m finishing a Master
> in Data Science. Before that, I was working as a postdoctoral researcher
> for two years in the Department of Algebra at the University of Granada.
> The project of the postdoctoral research was building Algebraic
> Error-Correcting Codes. I implemented in Python the codes and the
> algorithms that we builded. During this period I collaborated in writing 3
> papers, in relevant journals, as Mathematische Zeitschrift, which published
> our paper Biseparable extensions are not necessarily Frobenius, where we
> answered a 20-Year open algebra’s problem. And most important, I wrote a
> paper on my own, On natural sets on an idiom, which is a hard and relevant
> task in pure maths, published in Communications in Algebra.
> I have been working with python for about 2 years.
> I have used  SymPy before but I'm more familiar with sagemath.
>
> Thanks in advance,
>
> Patricio
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/b5c9ed6d-c7d7-4df6-8d4b-f88bffd6a7c8n%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AheQ-bBKQiqrzwR3sTYYN68MjXNjnpF%3DJY3%3DRW6SK02Tg%40mail.gmail.com.

Re: [sympy] Sympy

[Jason Moore]

I think it's best if you work with one of the ideas on the GSoC ideas list.

Jason
moorepants.info
+01 530-601-9791


On Wed, Mar 17, 2021 at 10:16 AM ARUN V  wrote:

> Really thank u for replying me jason
>
> So according to your link
> I can think about different topics for project
> Like, ray optics
>  Sounds and vibration
>   Pressure
> Am i right?
> I have big interest in physics
> So before march 31 i must start working on my project
> And ask any doubts on it
> Is that what you mean? Sir
>
> So from above three topics i can choose anyone right ?
>
> And please say weather the topic choosen is right to go with a project
>
>
>
> On Wed, 17 Mar 2021, 1:33 pm Jason Moore,  wrote:
>
>> Arun,
>>
>> Start here and follow the instructions:
>> https://github.com/sympy/sympy/wiki/GSoC-Student-Instructions
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791
>>
>>
>> On Wed, Mar 17, 2021 at 8:30 AM ARUN V  wrote:
>>
>>> Hi i am ARUN.V;
>>>  I like to work in sympy and i have gone through the documentation
>>> sir
>>> I have 3 years experience in python
>>> I currently studying second year(CSE) in sri Krishna college of
>>> technology
>>>
>>> I have some questions to ask u
>>> 1. What should I start with?
>>> 2.should build a library with python with any topic in physics?
>>> 3.should i check the code in the git and modify the code at which i know?
>>> Example: i like to work on logic in sympy so i see the code and check
>>> any bug or change a code to a really effective ways
>>> 4.can i build a new library ?
>>> 5.what are u expecting me to do in this project?
>>>
>>>
>>> Sincerely from ARUN.V;
>>>
>>> --
>>> 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 discussion on the web visit
>>> https://groups.google.com/d/msgid/sympy/9119c49b-a007-4a80-8057-a49da63ffdcen%40googlegroups.com
>>> <https://groups.google.com/d/msgid/sympy/9119c49b-a007-4a80-8057-a49da63ffdcen%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> 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 discussion on the web visit
>> https://groups.google.com/d/msgid/sympy/CAP7f1AhSRJnuRdCzgt8PW8Y2f6Zjc%2B_eVF3fJ4bMissP2Z7_KA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/sympy/CAP7f1AhSRJnuRdCzgt8PW8Y2f6Zjc%2B_eVF3fJ4bMissP2Z7_KA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAMHZyN80%2Bvs4%3DxgszAUWOCcGSYpdeSTfkNOVHA4ffWOahn3dPw%40mail.gmail.com
> <https://groups.google.com/d/msgid/sympy/CAMHZyN80%2Bvs4%3DxgszAUWOCcGSYpdeSTfkNOVHA4ffWOahn3dPw%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AgbnRZVZh8rR9bV0z-emL_79z3%2BX2dr%2BPdiSNwVFWquSw%40mail.gmail.com.

Re: [sympy] Sympy

[Jason Moore]

Arun,

Start here and follow the instructions:
https://github.com/sympy/sympy/wiki/GSoC-Student-Instructions

Jason
moorepants.info
+01 530-601-9791


On Wed, Mar 17, 2021 at 8:30 AM ARUN V  wrote:

> Hi i am ARUN.V;
>  I like to work in sympy and i have gone through the documentation sir
> I have 3 years experience in python
> I currently studying second year(CSE) in sri Krishna college of technology
>
> I have some questions to ask u
> 1. What should I start with?
> 2.should build a library with python with any topic in physics?
> 3.should i check the code in the git and modify the code at which i know?
> Example: i like to work on logic in sympy so i see the code and check any
> bug or change a code to a really effective ways
> 4.can i build a new library ?
> 5.what are u expecting me to do in this project?
>
>
> Sincerely from ARUN.V;
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/9119c49b-a007-4a80-8057-a49da63ffdcen%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AhSRJnuRdCzgt8PW8Y2f6Zjc%2B_eVF3fJ4bMissP2Z7_KA%40mail.gmail.com.

Re: [sympy] GSoC Idea discussion

[Jason Moore]

Sudeep,

Please see the GSoC instructions:
https://github.com/sympy/sympy/wiki/GSoC-Student-Instructions. We recommend
the wiki.

Jason
moorepants.info
+01 530-601-9791


On Fri, Mar 12, 2021 at 1:39 PM Sudeep Sidhu 
wrote:

> Jason,
>
> I have prepared my draft proposal for GSoC'21. Where shall I share it so
> that you and others can review it.
>
> Sudeep Sidhu
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAJUjCN%3DNo%2BonpynE4PqsL%3Dk_%2BZF1e9-_kWr%3Do9ivgf%2B8xr17qg%40mail.gmail.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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AirRMUN%3DYbdbjtTiuvwg3isUSSP28ziywQ6toLc_YZt-Q%40mail.gmail.com.

Re: [sympy] SymPy has been accepted into GSoC

[Jason Moore]

Congrats!

Thanks Aaron for pushing the application through again.

Jason
moorepants.info
+01 530-601-9791


On Tue, Mar 9, 2021 at 9:17 PM Aaron Meurer  wrote:

> SymPy has once again been accepted into Google Summer of Code (GSoC).
> Students who are interested in applying, start with our student
> instructions https://github.com/sympy/sympy/wiki/GSoC-Student-Instructions
> .
> You should look over our ideas list and discuss any ideas you are
> interested in with us.
>
> Mentors, if you haven't already, please add yourself to the list at
> https://github.com/sympy/sympy/wiki/GSoC-Ideas#potential-mentors so I
> can add you on the Google site. Also, please feel free to update the
> ideas page if you see something is missing or out of date.
>
> A reminder that this year, the number of hours expected from GSoC has
> been reduced to 175 hours over the summer (previously it was 350
> hours). Please take this into consideration when writing and reviewing
> proposals.
>
> I look forward to working with you all and having another productive
> year for GSoC.
>
> Aaron Meurer
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAKgW%3D6KHK6W-UYuS60bwbg_%3DjoVg8KihMkec7id6K5n101ekVw%40mail.gmail.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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Aj8xk4agJQvgwtUUNvgYbkBhR6fKkNPZN6p8VO5-TVG_Q%40mail.gmail.com.

Re: [sympy] GSoC Idea discussion

[Jason Moore]

Sudeep,

We don't tell you what is "good to go". Every applicant can propose
whatever they want. The applications are judged on the scope, the
likelihood of success, the writer's communication, alignment with sympy's
roadmap, and their applicant's interaction with the community.

Jason
moorepants.info
+01 530-601-9791


On Wed, Feb 10, 2021 at 4:07 PM Sudeep Sidhu 
wrote:

> Jason,
>
> I'll surely look into it.
>
> So is JointsMethod good to go as GSoC project?
>
> On Wed, 10 Feb 2021, 19:15 Jason Moore,  wrote:
>
>> Sudeep,
>>
>> The only thing I can think of to look it is how people do this in other
>> dynamics software. Many of them let the user define a system based on
>> descriptions of rigid bodies and different joint types. That description is
>> the used to define the mathematics of the kinematics. The software Simbody
>> does it, for example: https://github.com/simbody/simbody You can see
>> that the concept of a "mobilizer" is used.
>>
>> Jason
>> moorepants.info
>> +01 530-601-979
>>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAJUjCNmYppkxNO91SpEuMBXhbbHx26bnWF8-ioxA5NiECuWtFg%40mail.gmail.com
> <https://groups.google.com/d/msgid/sympy/CAJUjCNmYppkxNO91SpEuMBXhbbHx26bnWF8-ioxA5NiECuWtFg%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1AhSTDWC2n-z5h-jCLugdrvqPNMMWa96ck27E2Y-ttbJjQ%40mail.gmail.com.

Re: [sympy] GSoC Idea discussion

[Jason Moore]

Sudeep,

The only thing I can think of to look it is how people do this in other
dynamics software. Many of them let the user define a system based on
descriptions of rigid bodies and different joint types. That description is
the used to define the mathematics of the kinematics. The software Simbody
does it, for example: https://github.com/simbody/simbody You can see that
the concept of a "mobilizer" is used.

Jason
moorepants.info
+01 530-601-9791


On Wed, Feb 10, 2021 at 1:51 PM Sudeep Sidhu 
wrote:

> Jason,
>
> I went through the previous JointsMethod work, I think it would be wise to
> complete the previous 2 PRs of Joint Methods because it contains some good
> work and completing them would take less time rather than starting from
> scratch.
> Please refer a source to read more about Joints and JointsMethod.
>
> Sudeep Sidhu
>
>
>
>
> On Tue, 9 Feb 2021, 18:19 Sudeep Sidhu, 
> wrote:
>
>> Jason,
>>
>> I'm comfortable in implementing JointsMethod and it has some previous
>> work done too (unmerged GSoC work). All I would need is some guidance with
>> concepts if I get stuck somewhere and a good source to read about
>> JointsMethod. I have some knowledge of dynamics too so I think I can
>> implement it.
>>
>> Sudeep Sidhu
>>
>> On Tue, 9 Feb 2021, 15:28 Jason Moore,  wrote:
>>
>>> I personally think completing the JointsMethod is of higher priority
>>> than the FeatherStone method. The JointsMethod would open up the use of the
>>> library to a much wider set of users because they will be able to construct
>>> models with less knowledge of the underlying mathematics. For example, a
>>> double compound pendulum could be created like this:
>>>
>>> ground = RigidBody(...)
>>> upper_link = RigidBody(...)
>>> lower_link = RigidBody(...)
>>>
>>> base_joint = PinJoin(ground, lower_link, ...)
>>> intermediate_joint = PinJoint(lower_link, upper_link, ...)
>>>
>>> joint_method = JointMethod((base_joint, intermediate_joint), ...)
>>>
>>> equations_of_motion = joint_method.generate_eoms(...)
>>>
>>> Jason
>>> moorepants.info
>>> +01 530-601-9791
>>>
>> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAJUjCNnYjAqYz6z_sSum_-WLAGwP0FNotfSQvwxotNKcqqqs_A%40mail.gmail.com
> <https://groups.google.com/d/msgid/sympy/CAJUjCNnYjAqYz6z_sSum_-WLAGwP0FNotfSQvwxotNKcqqqs_A%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Aj2h_Q0%2BbP2HvpON3VaqctVjiuAXdO2YZJs_bWd%3D6iHDw%40mail.gmail.com.