Re: [sympy] Gsoc Project idea " Efficient Equation ofMotionGenerationwith Python" discussion.

[Oscar Benjamin]

On Thu, 14 Mar 2019 at 21:19, Aaron Meurer  wrote:
>
> I agree. The biggest challenge with symbolic matrices is expression
> blow up. In some cases it is unavoidable, for instance, symbolic
> eigenvalues/eigenvectors use the symbolic solutions to polynomials,
> which are complicated in the general case for n > 2.
>
> One thing I meant by "overhead" is that if the type of a matrix's
> entries is known to all be rational numbers, for instance, we can
> operate directly on those numbers, ideally using fast number types
> like gmpy.mpq. If they are all rational functions, we can use
> polynomial algorithms that operate on rational functions. These always
> keep rational functions in canonical form, and the zero equivalence
> testing becomes literally "expr == 0" (no simplification required).
> These can be more efficient than general symbolic manipulation.
>
> This is how the polys module is structured. See
> https://docs.sympy.org/latest/modules/polys/internals.html. It would
> be nice to have a similar structure in the matrices, where a matrix
> can have a ground domain (or type) associated with its underlying
> data.

There is an example of this here:
https://github.com/sympy/sympy/issues/16823

The matrix is all numbers of the form q1+I*q2 for rational q1 and q2
and the expressions blow up leading to terrible asymptotic
performance. It could probably be made a lot faster with judicious use
of expand but actually having a fast only complex number matrix
routine would speed that up massively.

--
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 post to this group, send email to sympy@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/CAHVvXxSTPcKsQY4E%2BS046LyDMhKYvKgFF97xVqT_oSmWY7F1zA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Gsoc Project idea " Efficient Equation ofMotionGenerationwith Python" discussion.

[Shiksha Rawat]

I have added case study for the performance issue i am working on.
https://github.com/sympy/sympy/wiki/GSoC-2019-Application-SHIKSHA-RAWAT-:-Benchmarks-and-performance

Please review the proposal and suggest changes.
I have not completed the implementation plans. But i will add that part too
by tonight.

On Mon, Apr 1, 2019 at 7:55 PM Shiksha Rawat 
wrote:

>  I am currently trying to improve the performance in the PR
> https://github.com/sympy/sympy/pull/16509
> To complete my gsoc proposal should i write the way i am trying to improve
> the performance and how i have planned to proceed ?
>
> Because the idea of benchmarking and performance mainly involves trying to
> find suitable substitute for a bottleneck.
>
> On Sat, Mar 30, 2019 at 1:29 AM Shiksha Rawat 
> wrote:
>
>> Okay, i have continued the discussion on the issue itself.
>>
>> On Sat, Mar 30, 2019 at 12:06 AM Aaron Meurer  wrote:
>>
>>> On Fri, Mar 29, 2019 at 12:07 PM Shiksha Rawat 
>>> wrote:
>>> >
>>> > Thank you for the replies.
>>> >
>>> > As suggested by Aaron , I figured out ways to fix the performance of
>>> https://github.com/sympy/sympy/issues/16249.
>>> > One of the easy way is to disable _find_localzeros
>>> > The function is creating a set of non-minimal(non-maximal) numbers and
>>> to identify these it is making comparison between every two possible
>>> combination of numbers.
>>> > But these non-minimal values can be computed by sorting the values in
>>> ascending or descending order.
>>> > This sorting can be done by using algorithms like merge-sort with
>>> complexity (nlogn) which is much better than currently used n**2.
>>> > So second option is to use better algorithms.
>>> >
>>> > Which would be better or which one should i use to fix this issue?
>>> >  Please suggest.
>>>
>>> It depends on what the performance is like, and what the tradeoffs
>>> are. Often when trying to make something faster you may think that
>>> something will improve performance, but after implementing it you'll
>>> find that it doesn't change it at all, or it even makes it worse. So
>>> you always have to try it out and profile it.
>>>
>>> It would be better to move the discussion of this specific issue to
>>> the issue itself.
>>>
>>> Aaron Meurer
>>>
>>> >
>>> > I am also trying to find regressions on which i could work in
>>> https://github.com/sympy/sympy_benchmarks.
>>> >
>>> > On Thu, Mar 28, 2019 at 9:38 PM Jason Moore 
>>> wrote:
>>> >>
>>> >> We have a benchmark repository that is run periodically:
>>> https://github.com/sympy/sympy_benchmarks
>>> >>
>>> >> I recommend starting there. You can find a number of regressions that
>>> can be investigated.
>>> >>
>>> >> Jason
>>> >> moorepants.info
>>> >> +01 530-601-9791
>>> >>
>>> >>
>>> >> On Wed, Mar 27, 2019 at 5:17 PM Aaron Meurer 
>>> wrote:
>>> >>>
>>> >>> I agree with Oscar. I would also add that it's usually not trivial to
>>> >>> determine where the bottlenecks are in SymPy. So I would write more
>>> >>> about how you intend to profile the code.
>>> >>>
>>> >>> Perhaps it would be useful to take an existing thing that is slow in
>>> >>> SymPy (you can use the performance issue label as a guide, or find
>>> >>> something yourself,
>>> >>>
>>> https://github.com/sympy/sympy/issues?q=is%3Aopen+is%3Aissue+label%3APerformance
>>> ),
>>> >>> and try to fix the performance, documenting how you went about
>>> finding
>>> >>> the bottleneck and fixing it. This can be used as a case study in
>>> your
>>> >>> application.
>>> >>>
>>> >>> Also I would note that currently the benchmarking infrastructure for
>>> >>> SymPy is quite bad (basically nonexistent). See
>>> >>>
>>> https://github.com/sympy/sympy/wiki/GSoC-2019-Ideas#benchmarks-and-performance
>>> .
>>> >>> It's fine if you do not want to work on that specifically, but you
>>> >>> should note that you will be running the benchmarks on your own
>>> >>> computer to find performance regressions. Not all performance issues
>>> >>> are regressions either (some things have always been slow), so you
>>> >>> should consider absolute numbers as well as relative numbers.
>>> >>>
>>> >>> Aaron Meurer
>>> >>>
>>> >>> On Wed, Mar 27, 2019 at 5:11 PM Oscar Benjamin
>>> >>>  wrote:
>>> >>> >
>>> >>> > This looks like good work to do. I don't know how these
>>> applications
>>> >>> > are evaluated but my thought if I was reviewing this would be that
>>> it
>>> >>> > seems quite vague. This would probably be a more enticing proposal
>>> if
>>> >>> > it had some specific suggestions of changes that would speed things
>>> >>> > up.
>>> >>> >
>>> >>> > I can tell you now what is slow in the ODE module: currently even
>>> for
>>> >>> > the simplest ODEs all matching code is run for all the possible
>>> >>> > methods even after a suitable method has been found. It would be
>>> much
>>> >>> > better to identify the most immediately usable solver and then use
>>> >>> > that without matching all the others. This needs a refactor of the
>>> >>> > module though and a 

Re: [sympy] Gsoc Project idea " Efficient Equation ofMotionGenerationwith Python" discussion.

[Shiksha Rawat]

 I am currently trying to improve the performance in the PR
https://github.com/sympy/sympy/pull/16509
To complete my gsoc proposal should i write the way i am trying to improve
the performance and how i have planned to proceed ?

Because the idea of benchmarking and performance mainly involves trying to
find suitable substitute for a bottleneck.

On Sat, Mar 30, 2019 at 1:29 AM Shiksha Rawat 
wrote:

> Okay, i have continued the discussion on the issue itself.
>
> On Sat, Mar 30, 2019 at 12:06 AM Aaron Meurer  wrote:
>
>> On Fri, Mar 29, 2019 at 12:07 PM Shiksha Rawat 
>> wrote:
>> >
>> > Thank you for the replies.
>> >
>> > As suggested by Aaron , I figured out ways to fix the performance of
>> https://github.com/sympy/sympy/issues/16249.
>> > One of the easy way is to disable _find_localzeros
>> > The function is creating a set of non-minimal(non-maximal) numbers and
>> to identify these it is making comparison between every two possible
>> combination of numbers.
>> > But these non-minimal values can be computed by sorting the values in
>> ascending or descending order.
>> > This sorting can be done by using algorithms like merge-sort with
>> complexity (nlogn) which is much better than currently used n**2.
>> > So second option is to use better algorithms.
>> >
>> > Which would be better or which one should i use to fix this issue?
>> >  Please suggest.
>>
>> It depends on what the performance is like, and what the tradeoffs
>> are. Often when trying to make something faster you may think that
>> something will improve performance, but after implementing it you'll
>> find that it doesn't change it at all, or it even makes it worse. So
>> you always have to try it out and profile it.
>>
>> It would be better to move the discussion of this specific issue to
>> the issue itself.
>>
>> Aaron Meurer
>>
>> >
>> > I am also trying to find regressions on which i could work in
>> https://github.com/sympy/sympy_benchmarks.
>> >
>> > On Thu, Mar 28, 2019 at 9:38 PM Jason Moore 
>> wrote:
>> >>
>> >> We have a benchmark repository that is run periodically:
>> https://github.com/sympy/sympy_benchmarks
>> >>
>> >> I recommend starting there. You can find a number of regressions that
>> can be investigated.
>> >>
>> >> Jason
>> >> moorepants.info
>> >> +01 530-601-9791
>> >>
>> >>
>> >> On Wed, Mar 27, 2019 at 5:17 PM Aaron Meurer 
>> wrote:
>> >>>
>> >>> I agree with Oscar. I would also add that it's usually not trivial to
>> >>> determine where the bottlenecks are in SymPy. So I would write more
>> >>> about how you intend to profile the code.
>> >>>
>> >>> Perhaps it would be useful to take an existing thing that is slow in
>> >>> SymPy (you can use the performance issue label as a guide, or find
>> >>> something yourself,
>> >>>
>> https://github.com/sympy/sympy/issues?q=is%3Aopen+is%3Aissue+label%3APerformance
>> ),
>> >>> and try to fix the performance, documenting how you went about finding
>> >>> the bottleneck and fixing it. This can be used as a case study in your
>> >>> application.
>> >>>
>> >>> Also I would note that currently the benchmarking infrastructure for
>> >>> SymPy is quite bad (basically nonexistent). See
>> >>>
>> https://github.com/sympy/sympy/wiki/GSoC-2019-Ideas#benchmarks-and-performance
>> .
>> >>> It's fine if you do not want to work on that specifically, but you
>> >>> should note that you will be running the benchmarks on your own
>> >>> computer to find performance regressions. Not all performance issues
>> >>> are regressions either (some things have always been slow), so you
>> >>> should consider absolute numbers as well as relative numbers.
>> >>>
>> >>> Aaron Meurer
>> >>>
>> >>> On Wed, Mar 27, 2019 at 5:11 PM Oscar Benjamin
>> >>>  wrote:
>> >>> >
>> >>> > This looks like good work to do. I don't know how these applications
>> >>> > are evaluated but my thought if I was reviewing this would be that
>> it
>> >>> > seems quite vague. This would probably be a more enticing proposal
>> if
>> >>> > it had some specific suggestions of changes that would speed things
>> >>> > up.
>> >>> >
>> >>> > I can tell you now what is slow in the ODE module: currently even
>> for
>> >>> > the simplest ODEs all matching code is run for all the possible
>> >>> > methods even after a suitable method has been found. It would be
>> much
>> >>> > better to identify the most immediately usable solver and then use
>> >>> > that without matching all the others. This needs a refactor of the
>> >>> > module though and a redesign of the basic approach used by dsolve. I
>> >>> > want that to happen as an ultimate goal but I would like to see
>> better
>> >>> > test coverage first.
>> >>> >
>> >>> > On Wed, 27 Mar 2019 at 09:56, Shiksha Rawat <
>> shiksharawa...@gmail.com> wrote:
>> >>> > >
>> >>> > >
>> https://github.com/sympy/sympy/wiki/GSoC-2019-Application-SHIKSHA-RAWAT-:-Benchmarks-and-performance
>> >>> > >
>> >>> > > I have designed a proposal for Benchmarks and Perfromance idea,
>> though it is not 

Re: [sympy] Gsoc Project idea " Efficient Equation ofMotionGenerationwith Python" discussion.

[Shiksha Rawat]

Okay, i have continued the discussion on the issue itself.

On Sat, Mar 30, 2019 at 12:06 AM Aaron Meurer  wrote:

> On Fri, Mar 29, 2019 at 12:07 PM Shiksha Rawat 
> wrote:
> >
> > Thank you for the replies.
> >
> > As suggested by Aaron , I figured out ways to fix the performance of
> https://github.com/sympy/sympy/issues/16249.
> > One of the easy way is to disable _find_localzeros
> > The function is creating a set of non-minimal(non-maximal) numbers and
> to identify these it is making comparison between every two possible
> combination of numbers.
> > But these non-minimal values can be computed by sorting the values in
> ascending or descending order.
> > This sorting can be done by using algorithms like merge-sort with
> complexity (nlogn) which is much better than currently used n**2.
> > So second option is to use better algorithms.
> >
> > Which would be better or which one should i use to fix this issue?
> >  Please suggest.
>
> It depends on what the performance is like, and what the tradeoffs
> are. Often when trying to make something faster you may think that
> something will improve performance, but after implementing it you'll
> find that it doesn't change it at all, or it even makes it worse. So
> you always have to try it out and profile it.
>
> It would be better to move the discussion of this specific issue to
> the issue itself.
>
> Aaron Meurer
>
> >
> > I am also trying to find regressions on which i could work in
> https://github.com/sympy/sympy_benchmarks.
> >
> > On Thu, Mar 28, 2019 at 9:38 PM Jason Moore 
> wrote:
> >>
> >> We have a benchmark repository that is run periodically:
> https://github.com/sympy/sympy_benchmarks
> >>
> >> I recommend starting there. You can find a number of regressions that
> can be investigated.
> >>
> >> Jason
> >> moorepants.info
> >> +01 530-601-9791
> >>
> >>
> >> On Wed, Mar 27, 2019 at 5:17 PM Aaron Meurer 
> wrote:
> >>>
> >>> I agree with Oscar. I would also add that it's usually not trivial to
> >>> determine where the bottlenecks are in SymPy. So I would write more
> >>> about how you intend to profile the code.
> >>>
> >>> Perhaps it would be useful to take an existing thing that is slow in
> >>> SymPy (you can use the performance issue label as a guide, or find
> >>> something yourself,
> >>>
> https://github.com/sympy/sympy/issues?q=is%3Aopen+is%3Aissue+label%3APerformance
> ),
> >>> and try to fix the performance, documenting how you went about finding
> >>> the bottleneck and fixing it. This can be used as a case study in your
> >>> application.
> >>>
> >>> Also I would note that currently the benchmarking infrastructure for
> >>> SymPy is quite bad (basically nonexistent). See
> >>>
> https://github.com/sympy/sympy/wiki/GSoC-2019-Ideas#benchmarks-and-performance
> .
> >>> It's fine if you do not want to work on that specifically, but you
> >>> should note that you will be running the benchmarks on your own
> >>> computer to find performance regressions. Not all performance issues
> >>> are regressions either (some things have always been slow), so you
> >>> should consider absolute numbers as well as relative numbers.
> >>>
> >>> Aaron Meurer
> >>>
> >>> On Wed, Mar 27, 2019 at 5:11 PM Oscar Benjamin
> >>>  wrote:
> >>> >
> >>> > This looks like good work to do. I don't know how these applications
> >>> > are evaluated but my thought if I was reviewing this would be that it
> >>> > seems quite vague. This would probably be a more enticing proposal if
> >>> > it had some specific suggestions of changes that would speed things
> >>> > up.
> >>> >
> >>> > I can tell you now what is slow in the ODE module: currently even for
> >>> > the simplest ODEs all matching code is run for all the possible
> >>> > methods even after a suitable method has been found. It would be much
> >>> > better to identify the most immediately usable solver and then use
> >>> > that without matching all the others. This needs a refactor of the
> >>> > module though and a redesign of the basic approach used by dsolve. I
> >>> > want that to happen as an ultimate goal but I would like to see
> better
> >>> > test coverage first.
> >>> >
> >>> > On Wed, 27 Mar 2019 at 09:56, Shiksha Rawat <
> shiksharawa...@gmail.com> wrote:
> >>> > >
> >>> > >
> https://github.com/sympy/sympy/wiki/GSoC-2019-Application-SHIKSHA-RAWAT-:-Benchmarks-and-performance
> >>> > >
> >>> > > I have designed a proposal for Benchmarks and Perfromance idea,
> though it is not complete yet.
> >>> > >
> >>> > > Can Jason Moore, Aaron and Oscar please review that and suggest
> changes?
> >>> > >
> >>> > >
> >>> > > On Tue, Mar 19, 2019 at 11:53 PM Shiksha Rawat <
> shiksharawa...@gmail.com> wrote:
> >>> > >>
> >>> > >> I did further digging on the idea mentioned by Jason Moore.
> >>> > >>
> >>> > >> Figuring out the main bottlenecks for sympy : The best way to
> figure out these bottlenecks would be to designing a typical problem for
> each module for example mass spring damper for physics and 

Re: [sympy] Gsoc Project idea " Efficient Equation ofMotionGenerationwith Python" discussion.

[Aaron Meurer]

On Fri, Mar 29, 2019 at 12:07 PM Shiksha Rawat  wrote:
>
> Thank you for the replies.
>
> As suggested by Aaron , I figured out ways to fix the performance of 
> https://github.com/sympy/sympy/issues/16249.
> One of the easy way is to disable _find_localzeros
> The function is creating a set of non-minimal(non-maximal) numbers and to 
> identify these it is making comparison between every two possible combination 
> of numbers.
> But these non-minimal values can be computed by sorting the values in 
> ascending or descending order.
> This sorting can be done by using algorithms like merge-sort with complexity 
> (nlogn) which is much better than currently used n**2.
> So second option is to use better algorithms.
>
> Which would be better or which one should i use to fix this issue?
>  Please suggest.

It depends on what the performance is like, and what the tradeoffs
are. Often when trying to make something faster you may think that
something will improve performance, but after implementing it you'll
find that it doesn't change it at all, or it even makes it worse. So
you always have to try it out and profile it.

It would be better to move the discussion of this specific issue to
the issue itself.

Aaron Meurer

>
> I am also trying to find regressions on which i could work in 
> https://github.com/sympy/sympy_benchmarks.
>
> On Thu, Mar 28, 2019 at 9:38 PM Jason Moore  wrote:
>>
>> We have a benchmark repository that is run periodically: 
>> https://github.com/sympy/sympy_benchmarks
>>
>> I recommend starting there. You can find a number of regressions that can be 
>> investigated.
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791
>>
>>
>> On Wed, Mar 27, 2019 at 5:17 PM Aaron Meurer  wrote:
>>>
>>> I agree with Oscar. I would also add that it's usually not trivial to
>>> determine where the bottlenecks are in SymPy. So I would write more
>>> about how you intend to profile the code.
>>>
>>> Perhaps it would be useful to take an existing thing that is slow in
>>> SymPy (you can use the performance issue label as a guide, or find
>>> something yourself,
>>> https://github.com/sympy/sympy/issues?q=is%3Aopen+is%3Aissue+label%3APerformance),
>>> and try to fix the performance, documenting how you went about finding
>>> the bottleneck and fixing it. This can be used as a case study in your
>>> application.
>>>
>>> Also I would note that currently the benchmarking infrastructure for
>>> SymPy is quite bad (basically nonexistent). See
>>> https://github.com/sympy/sympy/wiki/GSoC-2019-Ideas#benchmarks-and-performance.
>>> It's fine if you do not want to work on that specifically, but you
>>> should note that you will be running the benchmarks on your own
>>> computer to find performance regressions. Not all performance issues
>>> are regressions either (some things have always been slow), so you
>>> should consider absolute numbers as well as relative numbers.
>>>
>>> Aaron Meurer
>>>
>>> On Wed, Mar 27, 2019 at 5:11 PM Oscar Benjamin
>>>  wrote:
>>> >
>>> > This looks like good work to do. I don't know how these applications
>>> > are evaluated but my thought if I was reviewing this would be that it
>>> > seems quite vague. This would probably be a more enticing proposal if
>>> > it had some specific suggestions of changes that would speed things
>>> > up.
>>> >
>>> > I can tell you now what is slow in the ODE module: currently even for
>>> > the simplest ODEs all matching code is run for all the possible
>>> > methods even after a suitable method has been found. It would be much
>>> > better to identify the most immediately usable solver and then use
>>> > that without matching all the others. This needs a refactor of the
>>> > module though and a redesign of the basic approach used by dsolve. I
>>> > want that to happen as an ultimate goal but I would like to see better
>>> > test coverage first.
>>> >
>>> > On Wed, 27 Mar 2019 at 09:56, Shiksha Rawat  
>>> > wrote:
>>> > >
>>> > > https://github.com/sympy/sympy/wiki/GSoC-2019-Application-SHIKSHA-RAWAT-:-Benchmarks-and-performance
>>> > >
>>> > > I have designed a proposal for Benchmarks and Perfromance idea, though 
>>> > > it is not complete yet.
>>> > >
>>> > > Can Jason Moore, Aaron and Oscar please review that and suggest changes?
>>> > >
>>> > >
>>> > > On Tue, Mar 19, 2019 at 11:53 PM Shiksha Rawat 
>>> > >  wrote:
>>> > >>
>>> > >> I did further digging on the idea mentioned by Jason Moore.
>>> > >>
>>> > >> Figuring out the main bottlenecks for sympy : The best way to figure 
>>> > >> out these bottlenecks would be to designing a typical problem for each 
>>> > >> module for example mass spring damper for physics and computing time 
>>> > >> taken by sympy to give the output.If it is greater then expected than 
>>> > >> or a predefined threshold than analyzing the codebase of that module 
>>> > >> for possible changes to decrease computation time. And the results of 
>>> > >> predefined benchmarks could also be used.
>>> > >>
>>> > >> Creating 

Re: [sympy] Gsoc Project idea " Efficient Equation ofMotionGenerationwith Python" discussion.

[Shiksha Rawat]

Thank you for the replies.

As suggested by Aaron , I figured out ways to fix the performance of
https://github.com/sympy/sympy/issues/16249.
One of the easy way is to disable _find_localzeros
The function is creating a set of non-minimal(non-maximal) numbers and to
identify these it is making comparison between every two possible
combination of numbers.
But these non-minimal values can be computed by sorting the values in
ascending or descending order.
This sorting can be done by using algorithms like merge-sort with
complexity (nlogn) which is much better than currently used n**2.
So second option is to use better algorithms.

Which would be better or which one should i use to fix this issue?
 Please suggest.

I am also trying to find regressions on which i could work in
https://github.com/sympy/sympy_benchmarks.

On Thu, Mar 28, 2019 at 9:38 PM Jason Moore  wrote:

> We have a benchmark repository that is run periodically:
> https://github.com/sympy/sympy_benchmarks
>
> I recommend starting there. You can find a number of regressions that can
> be investigated.
>
> Jason
> moorepants.info
> +01 530-601-9791
>
>
> On Wed, Mar 27, 2019 at 5:17 PM Aaron Meurer  wrote:
>
>> I agree with Oscar. I would also add that it's usually not trivial to
>> determine where the bottlenecks are in SymPy. So I would write more
>> about how you intend to profile the code.
>>
>> Perhaps it would be useful to take an existing thing that is slow in
>> SymPy (you can use the performance issue label as a guide, or find
>> something yourself,
>>
>> https://github.com/sympy/sympy/issues?q=is%3Aopen+is%3Aissue+label%3APerformance
>> ),
>> and try to fix the performance, documenting how you went about finding
>> the bottleneck and fixing it. This can be used as a case study in your
>> application.
>>
>> Also I would note that currently the benchmarking infrastructure for
>> SymPy is quite bad (basically nonexistent). See
>>
>> https://github.com/sympy/sympy/wiki/GSoC-2019-Ideas#benchmarks-and-performance
>> .
>> It's fine if you do not want to work on that specifically, but you
>> should note that you will be running the benchmarks on your own
>> computer to find performance regressions. Not all performance issues
>> are regressions either (some things have always been slow), so you
>> should consider absolute numbers as well as relative numbers.
>>
>> Aaron Meurer
>>
>> On Wed, Mar 27, 2019 at 5:11 PM Oscar Benjamin
>>  wrote:
>> >
>> > This looks like good work to do. I don't know how these applications
>> > are evaluated but my thought if I was reviewing this would be that it
>> > seems quite vague. This would probably be a more enticing proposal if
>> > it had some specific suggestions of changes that would speed things
>> > up.
>> >
>> > I can tell you now what is slow in the ODE module: currently even for
>> > the simplest ODEs all matching code is run for all the possible
>> > methods even after a suitable method has been found. It would be much
>> > better to identify the most immediately usable solver and then use
>> > that without matching all the others. This needs a refactor of the
>> > module though and a redesign of the basic approach used by dsolve. I
>> > want that to happen as an ultimate goal but I would like to see better
>> > test coverage first.
>> >
>> > On Wed, 27 Mar 2019 at 09:56, Shiksha Rawat 
>> wrote:
>> > >
>> > >
>> https://github.com/sympy/sympy/wiki/GSoC-2019-Application-SHIKSHA-RAWAT-:-Benchmarks-and-performance
>> > >
>> > > I have designed a proposal for Benchmarks and Perfromance idea,
>> though it is not complete yet.
>> > >
>> > > Can Jason Moore, Aaron and Oscar please review that and suggest
>> changes?
>> > >
>> > >
>> > > On Tue, Mar 19, 2019 at 11:53 PM Shiksha Rawat <
>> shiksharawa...@gmail.com> wrote:
>> > >>
>> > >> I did further digging on the idea mentioned by Jason Moore.
>> > >>
>> > >> Figuring out the main bottlenecks for sympy : The best way to figure
>> out these bottlenecks would be to designing a typical problem for each
>> module for example mass spring damper for physics and computing time taken
>> by sympy to give the output.If it is greater then expected than or a
>> predefined threshold than analyzing the codebase of that module for
>> possible changes to decrease computation time. And the results of
>> predefined benchmarks could also be used.
>> > >>
>> > >> Creating benchmarks :
>> https://media.readthedocs.org/pdf/asv/v0.1.1/asv.pdf
>> > >> I think this documentation could come in handy for creating the
>> benchmarks. The requirement of a particular benchmark could be made on the
>> basis of the bottlenecks which we will figure out.
>> > >>
>> > >> Improving performance:  I think the best way to improve performance
>> would be cleaning up the codebase first and then making changes in the
>> algorithms used according to the requirements.
>> > >>
>> > >> Future Scope: Figuring out a method by which each PR also has to
>> give information about the time the modules 

Re: [sympy] Gsoc Project idea " Efficient Equation ofMotionGenerationwith Python" discussion.

[Jason Moore]

We have a benchmark repository that is run periodically:
https://github.com/sympy/sympy_benchmarks

I recommend starting there. You can find a number of regressions that can
be investigated.

Jason
moorepants.info
+01 530-601-9791


On Wed, Mar 27, 2019 at 5:17 PM Aaron Meurer  wrote:

> I agree with Oscar. I would also add that it's usually not trivial to
> determine where the bottlenecks are in SymPy. So I would write more
> about how you intend to profile the code.
>
> Perhaps it would be useful to take an existing thing that is slow in
> SymPy (you can use the performance issue label as a guide, or find
> something yourself,
>
> https://github.com/sympy/sympy/issues?q=is%3Aopen+is%3Aissue+label%3APerformance
> ),
> and try to fix the performance, documenting how you went about finding
> the bottleneck and fixing it. This can be used as a case study in your
> application.
>
> Also I would note that currently the benchmarking infrastructure for
> SymPy is quite bad (basically nonexistent). See
>
> https://github.com/sympy/sympy/wiki/GSoC-2019-Ideas#benchmarks-and-performance
> .
> It's fine if you do not want to work on that specifically, but you
> should note that you will be running the benchmarks on your own
> computer to find performance regressions. Not all performance issues
> are regressions either (some things have always been slow), so you
> should consider absolute numbers as well as relative numbers.
>
> Aaron Meurer
>
> On Wed, Mar 27, 2019 at 5:11 PM Oscar Benjamin
>  wrote:
> >
> > This looks like good work to do. I don't know how these applications
> > are evaluated but my thought if I was reviewing this would be that it
> > seems quite vague. This would probably be a more enticing proposal if
> > it had some specific suggestions of changes that would speed things
> > up.
> >
> > I can tell you now what is slow in the ODE module: currently even for
> > the simplest ODEs all matching code is run for all the possible
> > methods even after a suitable method has been found. It would be much
> > better to identify the most immediately usable solver and then use
> > that without matching all the others. This needs a refactor of the
> > module though and a redesign of the basic approach used by dsolve. I
> > want that to happen as an ultimate goal but I would like to see better
> > test coverage first.
> >
> > On Wed, 27 Mar 2019 at 09:56, Shiksha Rawat 
> wrote:
> > >
> > >
> https://github.com/sympy/sympy/wiki/GSoC-2019-Application-SHIKSHA-RAWAT-:-Benchmarks-and-performance
> > >
> > > I have designed a proposal for Benchmarks and Perfromance idea, though
> it is not complete yet.
> > >
> > > Can Jason Moore, Aaron and Oscar please review that and suggest
> changes?
> > >
> > >
> > > On Tue, Mar 19, 2019 at 11:53 PM Shiksha Rawat <
> shiksharawa...@gmail.com> wrote:
> > >>
> > >> I did further digging on the idea mentioned by Jason Moore.
> > >>
> > >> Figuring out the main bottlenecks for sympy : The best way to figure
> out these bottlenecks would be to designing a typical problem for each
> module for example mass spring damper for physics and computing time taken
> by sympy to give the output.If it is greater then expected than or a
> predefined threshold than analyzing the codebase of that module for
> possible changes to decrease computation time. And the results of
> predefined benchmarks could also be used.
> > >>
> > >> Creating benchmarks :
> https://media.readthedocs.org/pdf/asv/v0.1.1/asv.pdf
> > >> I think this documentation could come in handy for creating the
> benchmarks. The requirement of a particular benchmark could be made on the
> basis of the bottlenecks which we will figure out.
> > >>
> > >> Improving performance:  I think the best way to improve performance
> would be cleaning up the codebase first and then making changes in the
> algorithms used according to the requirements.
> > >>
> > >> Future Scope: Figuring out a method by which each PR also has to give
> information about the time the modules related to that PR will take to give
> output of problems associated with that module. (those mentioned in
> figuring out the bottlenecks point).
> > >>
> > >> I might be wrong about the ideas mentioned above. So I want
> suggestions from the mentors.
> > >>
> > >> Thanks.
> > >>
> > >> On Fri, Mar 15, 2019 at 9:48 PM Shiksha Rawat <
> shiksharawa...@gmail.com> wrote:
> > >>>
> > >>> I am really interested in taking up that idea. Can you suggest where
> or how should I start from because up till now I was just focusing on the
> physics module and benchmarks related to it?
> > >>> I am still trying to find how could we optimize matrix operations.
> > >>>
> > >>>
> > >>> On Fri, Mar 15, 2019 at 8:46 PM Jason Moore 
> wrote:
> > 
> >  The mechanics speedup idea is really just a narrow version of the
> profiling and benchmarking idea (focuses on just a couple of packages).
> Maybe a proposal that focuses on figuring out the main bottlenecks for
> sympy, creating 

Re: [sympy] Gsoc Project idea " Efficient Equation ofMotionGenerationwith Python" discussion.

[Aaron Meurer]

I agree with Oscar. I would also add that it's usually not trivial to
determine where the bottlenecks are in SymPy. So I would write more
about how you intend to profile the code.

Perhaps it would be useful to take an existing thing that is slow in
SymPy (you can use the performance issue label as a guide, or find
something yourself,
https://github.com/sympy/sympy/issues?q=is%3Aopen+is%3Aissue+label%3APerformance),
and try to fix the performance, documenting how you went about finding
the bottleneck and fixing it. This can be used as a case study in your
application.

Also I would note that currently the benchmarking infrastructure for
SymPy is quite bad (basically nonexistent). See
https://github.com/sympy/sympy/wiki/GSoC-2019-Ideas#benchmarks-and-performance.
It's fine if you do not want to work on that specifically, but you
should note that you will be running the benchmarks on your own
computer to find performance regressions. Not all performance issues
are regressions either (some things have always been slow), so you
should consider absolute numbers as well as relative numbers.

Aaron Meurer

On Wed, Mar 27, 2019 at 5:11 PM Oscar Benjamin
 wrote:
>
> This looks like good work to do. I don't know how these applications
> are evaluated but my thought if I was reviewing this would be that it
> seems quite vague. This would probably be a more enticing proposal if
> it had some specific suggestions of changes that would speed things
> up.
>
> I can tell you now what is slow in the ODE module: currently even for
> the simplest ODEs all matching code is run for all the possible
> methods even after a suitable method has been found. It would be much
> better to identify the most immediately usable solver and then use
> that without matching all the others. This needs a refactor of the
> module though and a redesign of the basic approach used by dsolve. I
> want that to happen as an ultimate goal but I would like to see better
> test coverage first.
>
> On Wed, 27 Mar 2019 at 09:56, Shiksha Rawat  wrote:
> >
> > https://github.com/sympy/sympy/wiki/GSoC-2019-Application-SHIKSHA-RAWAT-:-Benchmarks-and-performance
> >
> > I have designed a proposal for Benchmarks and Perfromance idea, though it 
> > is not complete yet.
> >
> > Can Jason Moore, Aaron and Oscar please review that and suggest changes?
> >
> >
> > On Tue, Mar 19, 2019 at 11:53 PM Shiksha Rawat  
> > wrote:
> >>
> >> I did further digging on the idea mentioned by Jason Moore.
> >>
> >> Figuring out the main bottlenecks for sympy : The best way to figure out 
> >> these bottlenecks would be to designing a typical problem for each module 
> >> for example mass spring damper for physics and computing time taken by 
> >> sympy to give the output.If it is greater then expected than or a 
> >> predefined threshold than analyzing the codebase of that module for 
> >> possible changes to decrease computation time. And the results of 
> >> predefined benchmarks could also be used.
> >>
> >> Creating benchmarks :  https://media.readthedocs.org/pdf/asv/v0.1.1/asv.pdf
> >> I think this documentation could come in handy for creating the 
> >> benchmarks. The requirement of a particular benchmark could be made on the 
> >> basis of the bottlenecks which we will figure out.
> >>
> >> Improving performance:  I think the best way to improve performance would 
> >> be cleaning up the codebase first and then making changes in the 
> >> algorithms used according to the requirements.
> >>
> >> Future Scope: Figuring out a method by which each PR also has to give 
> >> information about the time the modules related to that PR will take to 
> >> give output of problems associated with that module. (those mentioned in 
> >> figuring out the bottlenecks point).
> >>
> >> I might be wrong about the ideas mentioned above. So I want suggestions 
> >> from the mentors.
> >>
> >> Thanks.
> >>
> >> On Fri, Mar 15, 2019 at 9:48 PM Shiksha Rawat  
> >> wrote:
> >>>
> >>> I am really interested in taking up that idea. Can you suggest where or 
> >>> how should I start from because up till now I was just focusing on the 
> >>> physics module and benchmarks related to it?
> >>> I am still trying to find how could we optimize matrix operations.
> >>>
> >>>
> >>> On Fri, Mar 15, 2019 at 8:46 PM Jason Moore  wrote:
> 
>  The mechanics speedup idea is really just a narrow version of the 
>  profiling and benchmarking idea (focuses on just a couple of packages). 
>  Maybe a proposal that focuses on figuring out the main bottlenecks for 
>  sympy, creating benchmarks for them, and then improving performance is a 
>  good proposal idea that will ultimately help all the packages. I'm happy 
>  to support and mentor on that idea if someone wants to submit.
> 
>  Jason
>  moorepants.info
>  +01 530-601-9791
> 
> 
>  On Thu, Mar 14, 2019 at 2:19 PM Aaron Meurer  wrote:
> >
> > I agree. The biggest challenge with symbolic matrices 

Re: [sympy] Gsoc Project idea " Efficient Equation ofMotionGenerationwith Python" discussion.

[Oscar Benjamin]

This looks like good work to do. I don't know how these applications
are evaluated but my thought if I was reviewing this would be that it
seems quite vague. This would probably be a more enticing proposal if
it had some specific suggestions of changes that would speed things
up.

I can tell you now what is slow in the ODE module: currently even for
the simplest ODEs all matching code is run for all the possible
methods even after a suitable method has been found. It would be much
better to identify the most immediately usable solver and then use
that without matching all the others. This needs a refactor of the
module though and a redesign of the basic approach used by dsolve. I
want that to happen as an ultimate goal but I would like to see better
test coverage first.

On Wed, 27 Mar 2019 at 09:56, Shiksha Rawat  wrote:
>
> https://github.com/sympy/sympy/wiki/GSoC-2019-Application-SHIKSHA-RAWAT-:-Benchmarks-and-performance
>
> I have designed a proposal for Benchmarks and Perfromance idea, though it is 
> not complete yet.
>
> Can Jason Moore, Aaron and Oscar please review that and suggest changes?
>
>
> On Tue, Mar 19, 2019 at 11:53 PM Shiksha Rawat  
> wrote:
>>
>> I did further digging on the idea mentioned by Jason Moore.
>>
>> Figuring out the main bottlenecks for sympy : The best way to figure out 
>> these bottlenecks would be to designing a typical problem for each module 
>> for example mass spring damper for physics and computing time taken by sympy 
>> to give the output.If it is greater then expected than or a predefined 
>> threshold than analyzing the codebase of that module for possible changes to 
>> decrease computation time. And the results of predefined benchmarks could 
>> also be used.
>>
>> Creating benchmarks :  https://media.readthedocs.org/pdf/asv/v0.1.1/asv.pdf
>> I think this documentation could come in handy for creating the benchmarks. 
>> The requirement of a particular benchmark could be made on the basis of the 
>> bottlenecks which we will figure out.
>>
>> Improving performance:  I think the best way to improve performance would be 
>> cleaning up the codebase first and then making changes in the algorithms 
>> used according to the requirements.
>>
>> Future Scope: Figuring out a method by which each PR also has to give 
>> information about the time the modules related to that PR will take to give 
>> output of problems associated with that module. (those mentioned in figuring 
>> out the bottlenecks point).
>>
>> I might be wrong about the ideas mentioned above. So I want suggestions from 
>> the mentors.
>>
>> Thanks.
>>
>> On Fri, Mar 15, 2019 at 9:48 PM Shiksha Rawat  
>> wrote:
>>>
>>> I am really interested in taking up that idea. Can you suggest where or how 
>>> should I start from because up till now I was just focusing on the physics 
>>> module and benchmarks related to it?
>>> I am still trying to find how could we optimize matrix operations.
>>>
>>>
>>> On Fri, Mar 15, 2019 at 8:46 PM Jason Moore  wrote:

 The mechanics speedup idea is really just a narrow version of the 
 profiling and benchmarking idea (focuses on just a couple of packages). 
 Maybe a proposal that focuses on figuring out the main bottlenecks for 
 sympy, creating benchmarks for them, and then improving performance is a 
 good proposal idea that will ultimately help all the packages. I'm happy 
 to support and mentor on that idea if someone wants to submit.

 Jason
 moorepants.info
 +01 530-601-9791


 On Thu, Mar 14, 2019 at 2:19 PM Aaron Meurer  wrote:
>
> I agree. The biggest challenge with symbolic matrices is expression
> blow up. In some cases it is unavoidable, for instance, symbolic
> eigenvalues/eigenvectors use the symbolic solutions to polynomials,
> which are complicated in the general case for n > 2.
>
> One thing I meant by "overhead" is that if the type of a matrix's
> entries is known to all be rational numbers, for instance, we can
> operate directly on those numbers, ideally using fast number types
> like gmpy.mpq. If they are all rational functions, we can use
> polynomial algorithms that operate on rational functions. These always
> keep rational functions in canonical form, and the zero equivalence
> testing becomes literally "expr == 0" (no simplification required).
> These can be more efficient than general symbolic manipulation.
>
> This is how the polys module is structured. See
> https://docs.sympy.org/latest/modules/polys/internals.html. It would
> be nice to have a similar structure in the matrices, where a matrix
> can have a ground domain (or type) associated with its underlying
> data.
>
> Aaron Meurer
>
> On Thu, Mar 14, 2019 at 2:52 PM Oscar Benjamin
>  wrote:
> >
> > (Replying on-list)
> >
> > On Thu, 14 Mar 2019 at 20:37, Alan Bromborsky  
> > wrote:
> > >
> > > Since 

Re: [sympy] Gsoc Project idea " Efficient Equation ofMotionGenerationwith Python" discussion.

[Shiksha Rawat]

https://github.com/sympy/sympy/wiki/GSoC-2019-Application-SHIKSHA-RAWAT-:-Benchmarks-and-performance

I have designed a proposal for Benchmarks and Perfromance idea, though it
is not complete yet.

Can Jason Moore, Aaron and Oscar please review that and suggest changes?


On Tue, Mar 19, 2019 at 11:53 PM Shiksha Rawat 
wrote:

> I did further digging on the idea mentioned by Jason Moore.
>
> *Figuring out the main bottlenecks for sympy *: The best way to figure
> out these bottlenecks would be to designing a typical problem for each
> module for example mass spring damper for physics and computing time taken
> by sympy to give the output.If it is greater then expected than or a
> predefined threshold than analyzing the codebase of that module for
> possible changes to decrease computation time. And the results of
> predefined benchmarks could also be used.
>
> *Creating benchmarks :  *
> https://media.readthedocs.org/pdf/asv/v0.1.1/asv.pdf
> I think this documentation could come in handy for creating the
> benchmarks. The requirement of a particular benchmark could be made on the
> basis of the bottlenecks which we will figure out.
>
> *Improving performance:  *I think the best way to improve performance
> would be cleaning up the codebase first and then making changes in the
> algorithms used according to the requirements.
>
> *Future Scope:* Figuring out a method by which each PR also has to give
> information about the time the modules related to that PR will take to give
> output of problems associated with that module. (those mentioned in
> figuring out the bottlenecks point).
>
> I might be wrong about the ideas mentioned above. So I want suggestions
> from the mentors.
>
> Thanks.
>
> On Fri, Mar 15, 2019 at 9:48 PM Shiksha Rawat 
> wrote:
>
>> I am really interested in taking up that idea. Can you suggest where or
>> how should I start from because up till now I was just focusing on the
>> physics module and benchmarks related to it?
>> I am still trying to find how could we optimize matrix operations.
>>
>>
>> On Fri, Mar 15, 2019 at 8:46 PM Jason Moore  wrote:
>>
>>> The mechanics speedup idea is really just a narrow version of the
>>> profiling and benchmarking idea (focuses on just a couple of packages).
>>> Maybe a proposal that focuses on figuring out the main bottlenecks for
>>> sympy, creating benchmarks for them, and then improving performance is a
>>> good proposal idea that will ultimately help all the packages. I'm happy to
>>> support and mentor on that idea if someone wants to submit.
>>>
>>> Jason
>>> moorepants.info
>>> +01 530-601-9791
>>>
>>>
>>> On Thu, Mar 14, 2019 at 2:19 PM Aaron Meurer  wrote:
>>>
 I agree. The biggest challenge with symbolic matrices is expression
 blow up. In some cases it is unavoidable, for instance, symbolic
 eigenvalues/eigenvectors use the symbolic solutions to polynomials,
 which are complicated in the general case for n > 2.

 One thing I meant by "overhead" is that if the type of a matrix's
 entries is known to all be rational numbers, for instance, we can
 operate directly on those numbers, ideally using fast number types
 like gmpy.mpq. If they are all rational functions, we can use
 polynomial algorithms that operate on rational functions. These always
 keep rational functions in canonical form, and the zero equivalence
 testing becomes literally "expr == 0" (no simplification required).
 These can be more efficient than general symbolic manipulation.

 This is how the polys module is structured. See
 https://docs.sympy.org/latest/modules/polys/internals.html. It would
 be nice to have a similar structure in the matrices, where a matrix
 can have a ground domain (or type) associated with its underlying
 data.

 Aaron Meurer

 On Thu, Mar 14, 2019 at 2:52 PM Oscar Benjamin
  wrote:
 >
 > (Replying on-list)
 >
 > On Thu, 14 Mar 2019 at 20:37, Alan Bromborsky 
 wrote:
 > >
 > > Since most pc these days have multiple cores and threads what not
 use
 > > parallel algorithyms.  For honesty I must state I have a vested
 interest
 > > since I have a pc with a threadripper cpu with 16 cores and 32
 threads.
 >
 > Parallel algorithms can offer improvement. Your 16 cores might amount
 > to a 10x speed up if used well for this kind of thing. The
 > double-threading probably can't be exploited in CPython.
 >
 > However I think that many of the things that SymPy is slow for have
 > *really* bad asymptotic performance: think O(N!) rather than O(N^2).
 > Many orders of magnitude improvements can be made by spotting these
 > where more efficient methods are possible. It's not hard in a CAS to
 > accidentally generate enormous expressions and end up simplifying them
 > down again. This leads to many situations where it would be vastly
 > more efficient to somehow take a more 

Re: [sympy] Gsoc Project idea " Efficient Equation ofMotionGenerationwith Python" discussion.

[Shiksha Rawat]

I did further digging on the idea mentioned by Jason Moore.

*Figuring out the main bottlenecks for sympy *: The best way to figure out
these bottlenecks would be to designing a typical problem for each module
for example mass spring damper for physics and computing time taken by
sympy to give the output.If it is greater then expected than or a
predefined threshold than analyzing the codebase of that module for
possible changes to decrease computation time. And the results of
predefined benchmarks could also be used.

*Creating benchmarks :  *
https://media.readthedocs.org/pdf/asv/v0.1.1/asv.pdf
I think this documentation could come in handy for creating the benchmarks.
The requirement of a particular benchmark could be made on the basis of the
bottlenecks which we will figure out.

*Improving performance:  *I think the best way to improve performance would
be cleaning up the codebase first and then making changes in the algorithms
used according to the requirements.

*Future Scope:* Figuring out a method by which each PR also has to give
information about the time the modules related to that PR will take to give
output of problems associated with that module. (those mentioned in
figuring out the bottlenecks point).

I might be wrong about the ideas mentioned above. So I want suggestions
from the mentors.

Thanks.

On Fri, Mar 15, 2019 at 9:48 PM Shiksha Rawat 
wrote:

> I am really interested in taking up that idea. Can you suggest where or
> how should I start from because up till now I was just focusing on the
> physics module and benchmarks related to it?
> I am still trying to find how could we optimize matrix operations.
>
>
> On Fri, Mar 15, 2019 at 8:46 PM Jason Moore  wrote:
>
>> The mechanics speedup idea is really just a narrow version of the
>> profiling and benchmarking idea (focuses on just a couple of packages).
>> Maybe a proposal that focuses on figuring out the main bottlenecks for
>> sympy, creating benchmarks for them, and then improving performance is a
>> good proposal idea that will ultimately help all the packages. I'm happy to
>> support and mentor on that idea if someone wants to submit.
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791
>>
>>
>> On Thu, Mar 14, 2019 at 2:19 PM Aaron Meurer  wrote:
>>
>>> I agree. The biggest challenge with symbolic matrices is expression
>>> blow up. In some cases it is unavoidable, for instance, symbolic
>>> eigenvalues/eigenvectors use the symbolic solutions to polynomials,
>>> which are complicated in the general case for n > 2.
>>>
>>> One thing I meant by "overhead" is that if the type of a matrix's
>>> entries is known to all be rational numbers, for instance, we can
>>> operate directly on those numbers, ideally using fast number types
>>> like gmpy.mpq. If they are all rational functions, we can use
>>> polynomial algorithms that operate on rational functions. These always
>>> keep rational functions in canonical form, and the zero equivalence
>>> testing becomes literally "expr == 0" (no simplification required).
>>> These can be more efficient than general symbolic manipulation.
>>>
>>> This is how the polys module is structured. See
>>> https://docs.sympy.org/latest/modules/polys/internals.html. It would
>>> be nice to have a similar structure in the matrices, where a matrix
>>> can have a ground domain (or type) associated with its underlying
>>> data.
>>>
>>> Aaron Meurer
>>>
>>> On Thu, Mar 14, 2019 at 2:52 PM Oscar Benjamin
>>>  wrote:
>>> >
>>> > (Replying on-list)
>>> >
>>> > On Thu, 14 Mar 2019 at 20:37, Alan Bromborsky 
>>> wrote:
>>> > >
>>> > > Since most pc these days have multiple cores and threads what not use
>>> > > parallel algorithyms.  For honesty I must state I have a vested
>>> interest
>>> > > since I have a pc with a threadripper cpu with 16 cores and 32
>>> threads.
>>> >
>>> > Parallel algorithms can offer improvement. Your 16 cores might amount
>>> > to a 10x speed up if used well for this kind of thing. The
>>> > double-threading probably can't be exploited in CPython.
>>> >
>>> > However I think that many of the things that SymPy is slow for have
>>> > *really* bad asymptotic performance: think O(N!) rather than O(N^2).
>>> > Many orders of magnitude improvements can be made by spotting these
>>> > where more efficient methods are possible. It's not hard in a CAS to
>>> > accidentally generate enormous expressions and end up simplifying them
>>> > down again. This leads to many situations where it would be vastly
>>> > more efficient to somehow take a more direct route.
>>> >
>>> > --
>>> > 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 post to this group, send email to sympy@googlegroups.com.
>>> > Visit this group at https://groups.google.com/group/sympy.
>>> > To view this discussion on the web visit
>>> 

Re: [sympy] Gsoc Project idea " Efficient Equation ofMotionGenerationwith Python" discussion.

[Shiksha Rawat]

I am really interested in taking up that idea. Can you suggest where or how
should I start from because up till now I was just focusing on the physics
module and benchmarks related to it?
I am still trying to find how could we optimize matrix operations.


On Fri, Mar 15, 2019 at 8:46 PM Jason Moore  wrote:

> The mechanics speedup idea is really just a narrow version of the
> profiling and benchmarking idea (focuses on just a couple of packages).
> Maybe a proposal that focuses on figuring out the main bottlenecks for
> sympy, creating benchmarks for them, and then improving performance is a
> good proposal idea that will ultimately help all the packages. I'm happy to
> support and mentor on that idea if someone wants to submit.
>
> Jason
> moorepants.info
> +01 530-601-9791
>
>
> On Thu, Mar 14, 2019 at 2:19 PM Aaron Meurer  wrote:
>
>> I agree. The biggest challenge with symbolic matrices is expression
>> blow up. In some cases it is unavoidable, for instance, symbolic
>> eigenvalues/eigenvectors use the symbolic solutions to polynomials,
>> which are complicated in the general case for n > 2.
>>
>> One thing I meant by "overhead" is that if the type of a matrix's
>> entries is known to all be rational numbers, for instance, we can
>> operate directly on those numbers, ideally using fast number types
>> like gmpy.mpq. If they are all rational functions, we can use
>> polynomial algorithms that operate on rational functions. These always
>> keep rational functions in canonical form, and the zero equivalence
>> testing becomes literally "expr == 0" (no simplification required).
>> These can be more efficient than general symbolic manipulation.
>>
>> This is how the polys module is structured. See
>> https://docs.sympy.org/latest/modules/polys/internals.html. It would
>> be nice to have a similar structure in the matrices, where a matrix
>> can have a ground domain (or type) associated with its underlying
>> data.
>>
>> Aaron Meurer
>>
>> On Thu, Mar 14, 2019 at 2:52 PM Oscar Benjamin
>>  wrote:
>> >
>> > (Replying on-list)
>> >
>> > On Thu, 14 Mar 2019 at 20:37, Alan Bromborsky 
>> wrote:
>> > >
>> > > Since most pc these days have multiple cores and threads what not use
>> > > parallel algorithyms.  For honesty I must state I have a vested
>> interest
>> > > since I have a pc with a threadripper cpu with 16 cores and 32
>> threads.
>> >
>> > Parallel algorithms can offer improvement. Your 16 cores might amount
>> > to a 10x speed up if used well for this kind of thing. The
>> > double-threading probably can't be exploited in CPython.
>> >
>> > However I think that many of the things that SymPy is slow for have
>> > *really* bad asymptotic performance: think O(N!) rather than O(N^2).
>> > Many orders of magnitude improvements can be made by spotting these
>> > where more efficient methods are possible. It's not hard in a CAS to
>> > accidentally generate enormous expressions and end up simplifying them
>> > down again. This leads to many situations where it would be vastly
>> > more efficient to somehow take a more direct route.
>> >
>> > --
>> > 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 post to this group, send email to sympy@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/CAHVvXxTeAGZUv1kdtKCvBRodMZPyX5jHh76G0M49VshwMziJZA%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+unsubscr...@googlegroups.com.
>> To post to this group, send email to sympy@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/CAKgW%3D6JGfKjgHP3EaoX%3DXW_SMfnbGOZgi9LLJoUT3Ty7%3Dutd%2BA%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+unsubscr...@googlegroups.com.
> To post to this group, send email to sympy@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/CAP7f1AiMm_i%2BJBLBnv3_xzG_8Czag10DWvAUfiAhe-QUzUANiw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You 

Re: [sympy] Gsoc Project idea " Efficient Equation ofMotionGenerationwith Python" discussion.

[Jason Moore]

The mechanics speedup idea is really just a narrow version of the profiling
and benchmarking idea (focuses on just a couple of packages). Maybe a
proposal that focuses on figuring out the main bottlenecks for sympy,
creating benchmarks for them, and then improving performance is a good
proposal idea that will ultimately help all the packages. I'm happy to
support and mentor on that idea if someone wants to submit.

Jason
moorepants.info
+01 530-601-9791


On Thu, Mar 14, 2019 at 2:19 PM Aaron Meurer  wrote:

> I agree. The biggest challenge with symbolic matrices is expression
> blow up. In some cases it is unavoidable, for instance, symbolic
> eigenvalues/eigenvectors use the symbolic solutions to polynomials,
> which are complicated in the general case for n > 2.
>
> One thing I meant by "overhead" is that if the type of a matrix's
> entries is known to all be rational numbers, for instance, we can
> operate directly on those numbers, ideally using fast number types
> like gmpy.mpq. If they are all rational functions, we can use
> polynomial algorithms that operate on rational functions. These always
> keep rational functions in canonical form, and the zero equivalence
> testing becomes literally "expr == 0" (no simplification required).
> These can be more efficient than general symbolic manipulation.
>
> This is how the polys module is structured. See
> https://docs.sympy.org/latest/modules/polys/internals.html. It would
> be nice to have a similar structure in the matrices, where a matrix
> can have a ground domain (or type) associated with its underlying
> data.
>
> Aaron Meurer
>
> On Thu, Mar 14, 2019 at 2:52 PM Oscar Benjamin
>  wrote:
> >
> > (Replying on-list)
> >
> > On Thu, 14 Mar 2019 at 20:37, Alan Bromborsky 
> wrote:
> > >
> > > Since most pc these days have multiple cores and threads what not use
> > > parallel algorithyms.  For honesty I must state I have a vested
> interest
> > > since I have a pc with a threadripper cpu with 16 cores and 32 threads.
> >
> > Parallel algorithms can offer improvement. Your 16 cores might amount
> > to a 10x speed up if used well for this kind of thing. The
> > double-threading probably can't be exploited in CPython.
> >
> > However I think that many of the things that SymPy is slow for have
> > *really* bad asymptotic performance: think O(N!) rather than O(N^2).
> > Many orders of magnitude improvements can be made by spotting these
> > where more efficient methods are possible. It's not hard in a CAS to
> > accidentally generate enormous expressions and end up simplifying them
> > down again. This leads to many situations where it would be vastly
> > more efficient to somehow take a more direct route.
> >
> > --
> > 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 post to this group, send email to sympy@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/CAHVvXxTeAGZUv1kdtKCvBRodMZPyX5jHh76G0M49VshwMziJZA%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+unsubscr...@googlegroups.com.
> To post to this group, send email to sympy@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/CAKgW%3D6JGfKjgHP3EaoX%3DXW_SMfnbGOZgi9LLJoUT3Ty7%3Dutd%2BA%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+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@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/CAP7f1AiMm_i%2BJBLBnv3_xzG_8Czag10DWvAUfiAhe-QUzUANiw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Gsoc Project idea " Efficient Equation ofMotionGenerationwith Python" discussion.

[Aaron Meurer]

I agree. The biggest challenge with symbolic matrices is expression
blow up. In some cases it is unavoidable, for instance, symbolic
eigenvalues/eigenvectors use the symbolic solutions to polynomials,
which are complicated in the general case for n > 2.

One thing I meant by "overhead" is that if the type of a matrix's
entries is known to all be rational numbers, for instance, we can
operate directly on those numbers, ideally using fast number types
like gmpy.mpq. If they are all rational functions, we can use
polynomial algorithms that operate on rational functions. These always
keep rational functions in canonical form, and the zero equivalence
testing becomes literally "expr == 0" (no simplification required).
These can be more efficient than general symbolic manipulation.

This is how the polys module is structured. See
https://docs.sympy.org/latest/modules/polys/internals.html. It would
be nice to have a similar structure in the matrices, where a matrix
can have a ground domain (or type) associated with its underlying
data.

Aaron Meurer

On Thu, Mar 14, 2019 at 2:52 PM Oscar Benjamin
 wrote:
>
> (Replying on-list)
>
> On Thu, 14 Mar 2019 at 20:37, Alan Bromborsky  wrote:
> >
> > Since most pc these days have multiple cores and threads what not use
> > parallel algorithyms.  For honesty I must state I have a vested interest
> > since I have a pc with a threadripper cpu with 16 cores and 32 threads.
>
> Parallel algorithms can offer improvement. Your 16 cores might amount
> to a 10x speed up if used well for this kind of thing. The
> double-threading probably can't be exploited in CPython.
>
> However I think that many of the things that SymPy is slow for have
> *really* bad asymptotic performance: think O(N!) rather than O(N^2).
> Many orders of magnitude improvements can be made by spotting these
> where more efficient methods are possible. It's not hard in a CAS to
> accidentally generate enormous expressions and end up simplifying them
> down again. This leads to many situations where it would be vastly
> more efficient to somehow take a more direct route.
>
> --
> 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 post to this group, send email to sympy@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/CAHVvXxTeAGZUv1kdtKCvBRodMZPyX5jHh76G0M49VshwMziJZA%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+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@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/CAKgW%3D6JGfKjgHP3EaoX%3DXW_SMfnbGOZgi9LLJoUT3Ty7%3Dutd%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Gsoc Project idea " Efficient Equation ofMotionGenerationwith Python" discussion.

[Oscar Benjamin]

(Replying on-list)

On Thu, 14 Mar 2019 at 20:37, Alan Bromborsky  wrote:
>
> Since most pc these days have multiple cores and threads what not use
> parallel algorithyms.  For honesty I must state I have a vested interest
> since I have a pc with a threadripper cpu with 16 cores and 32 threads.

Parallel algorithms can offer improvement. Your 16 cores might amount
to a 10x speed up if used well for this kind of thing. The
double-threading probably can't be exploited in CPython.

However I think that many of the things that SymPy is slow for have
*really* bad asymptotic performance: think O(N!) rather than O(N^2).
Many orders of magnitude improvements can be made by spotting these
where more efficient methods are possible. It's not hard in a CAS to
accidentally generate enormous expressions and end up simplifying them
down again. This leads to many situations where it would be vastly
more efficient to somehow take a more direct route.

-- 
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 post to this group, send email to sympy@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/CAHVvXxTeAGZUv1kdtKCvBRodMZPyX5jHh76G0M49VshwMziJZA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Gsoc Project idea " Efficient Equation ofMotionGenerationwith Python" discussion.

[Vishesh Mangla]

@asmeurer
Well group theory concept is quite different and is really worth
implementing unlike karatsuba, ffts, or cook s algo etc.

On Fri, Mar 15, 2019, 01:20 Aaron Meurer  wrote:

> For matrices in sympy, I suspect in most cases the best speed ups would
> come from removing  overhead from the calculations, rather than from
> algorithmic improvements. Many of the algorithms mentioned here are only
> theoretically faster, or only faster asymptoticly. In some cases, they
> would only be faster for matrices that are larger than anything sympy could
> reasonably handle.
>
> Benchmarking and profiling are very important if you are looking to
> improve performance. Also take a look at the benchmarking idea on the GSoC
> ideas page.
>
> Aaron Meurer
>
> On Thu, Mar 14, 2019 at 12:04 PM Vishesh Mangla 
> wrote:
>
>> Give me 2 days since currently I am having my mid sems. I will respond
>> asap once I read it.
>>
>>
>>
>> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
>> Windows 10
>>
>>
>>
>> *From: *Jason Moore 
>> *Sent: *14 March 2019 22:56
>> *To: *sympy@googlegroups.com
>> *Subject: *Re: [sympy] Gsoc Project idea " Efficient Equation
>> ofMotionGenerationwith Python" discussion.
>>
>>
>>
>> Work to speed up matrix algorithms given assumptions on matrices would
>> help.
>>
>>
>>
>> Jason
>>
>> moorepants.info
>> +01 530-601-9791
>>
>>
>>
>>
>>
>> On Thu, Mar 14, 2019 at 9:31 AM Shiksha Rawat 
>> wrote:
>>
>>
>> https://web.wpi.edu/Pubs/ETD/Available/etd-012318-234642/unrestricted/zli.pdf
>>  in
>> this I think the description on "Embedding Matrix Multiplication in a
>> Group Algebra "  on page number 10 can be helpful.
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Mar 14, 2019 at 8:33 PM Shiksha Rawat 
>> wrote:
>>
>> Can Jason Moore or Oscar suggest anything,please?
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Mar 14, 2019 at 6:56 PM Vishesh Mangla 
>> wrote:
>>
>> Well, I can’t say much because I ‘m not a maths student and just study
>> maths because I like doing so.
>>
>> In this case you would be knowing it better than me.
>>
>>
>>
>> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
>> Windows 10
>>
>>
>>
>> *From: *Shiksha Rawat 
>> *Sent: *14 March 2019 18:49
>> *To: *sympy 
>> *Subject: *Re: [sympy] Gsoc Project idea " Efficient Equation
>> ofMotionGeneration with Python" discussion.
>>
>>
>>
>> Yes, I have studied group theory in my college curriculum.
>>
>> I tried to find ways by which group theory cap to used to simplify matrix
>> multiplication and came across
>> https://web.wpi.edu/Pubs/ETD/Available/etd-012318-234642/unrestricted/zli.pdf
>>
>> and
>> http://www.ccs.neu.edu/home/viola/classes/gems-08/lectures/le21-23.pdf.
>>
>>
>>
>> The ways suggested here can be used even when the dimensions of matrix
>> are not very large.
>>
>>
>>
>> Can this be of any help?
>>
>>
>>
>> On Thu, Mar 14, 2019 at 3:48 PM Vishesh Mangla 
>> wrote:
>>
>> Well if you see these algorithms are not for general purpose matrices but
>> for where high accuracy is required. I would rather say to use concepts of
>> group theory and representation theory (i do not have lot of knowledge
>> about this but 'm studying) which can reduce matrices to lower
>> dimensions.If you or your friends are from mathematical backgrounds they
>> might be able to tell you better if this can make it easier what you want
>> to do.
>>
>>
>>
>> On Thu, Mar 14, 2019, 15:07  wrote:
>>
>> I think you are confused with numpy and scipy.I don't think the algorithm
>> mentioned by you is much helpful to this cause. Could you please check out
>> some more algorithm for the same.
>>
>> --
>> 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 post to this group, send email to sympy@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/ff670eab-fe67-498c-ab45-b4abbd5018c5%40googlegroups.com
>> .

Re: [sympy] Gsoc Project idea " Efficient Equation ofMotionGenerationwith Python" discussion.

[Oscar Benjamin]

I haven't looked at SymPy's specific code for generating equations of
motion but I have used SymPy for generating equations of motion and
other mechanics related problems.

The example here:
https://github.com/sympy/sympy/issues/16207
comes from a mechanics problem and was slow because of slow matrix
calculations where the matrix has symbolic coefficients.

Note that the matrix in question is 13x13 so much smaller than anyone
would consider these large matrix multiplication algorithms to be
useful. The slowness of symbolic calculations makes it possible to
consider entirely different optimisations than those used in numeric
libraries though. In #16207 I can get a 50x speed up by factoring the
block structure of the matrix. The speed difference would be even
bigger for larger matrices. For a numeric library the additional
checks I performed to discover if that optimisation was possible would
cause a noticeable slowdown in the cases where the method doesn't
apply so that kind of thing wouldn't be considered.

Although #16207 is about eigenvalues the same principles can apply to
matrix multiplication and to solving systems of equations etc.

On Thu, 14 Mar 2019 at 19:50, Aaron Meurer  wrote:
>
> For matrices in sympy, I suspect in most cases the best speed ups would come 
> from removing  overhead from the calculations, rather than from algorithmic 
> improvements. Many of the algorithms mentioned here are only theoretically 
> faster, or only faster asymptoticly. In some cases, they would only be faster 
> for matrices that are larger than anything sympy could reasonably handle.
>
> Benchmarking and profiling are very important if you are looking to improve 
> performance. Also take a look at the benchmarking idea on the GSoC ideas page.
>
> Aaron Meurer
>
> On Thu, Mar 14, 2019 at 12:04 PM Vishesh Mangla  
> wrote:
>>
>> Give me 2 days since currently I am having my mid sems. I will respond asap 
>> once I read it.
>>
>>
>>
>> Sent from Mail for Windows 10
>>
>>
>>
>> From: Jason Moore
>> Sent: 14 March 2019 22:56
>> To: sympy@googlegroups.com
>> Subject: Re: [sympy] Gsoc Project idea " Efficient Equation 
>> ofMotionGenerationwith Python" discussion.
>>
>>
>>
>> Work to speed up matrix algorithms given assumptions on matrices would help.
>>
>>
>>
>> Jason
>>
>> moorepants.info
>> +01 530-601-9791
>>
>>
>>
>>
>>
>> On Thu, Mar 14, 2019 at 9:31 AM Shiksha Rawat  
>> wrote:
>>
>> https://web.wpi.edu/Pubs/ETD/Available/etd-012318-234642/unrestricted/zli.pdf
>>  in this I think the description on "Embedding Matrix Multiplication in a 
>> Group Algebra "  on page number 10 can be helpful.
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Mar 14, 2019 at 8:33 PM Shiksha Rawat  
>> wrote:
>>
>> Can Jason Moore or Oscar suggest anything,please?
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Mar 14, 2019 at 6:56 PM Vishesh Mangla  
>> wrote:
>>
>> Well, I can’t say much because I ‘m not a maths student and just study maths 
>> because I like doing so.
>>
>> In this case you would be knowing it better than me.
>>
>>
>>
>> Sent from Mail for Windows 10
>>
>>
>>
>> From: Shiksha Rawat
>> Sent: 14 March 2019 18:49
>> To: sympy
>> Subject: Re: [sympy] Gsoc Project idea " Efficient Equation 
>> ofMotionGeneration with Python" discussion.
>>
>>
>>
>> Yes, I have studied group theory in my college curriculum.
>>
>> I tried to find ways by which group theory cap to used to simplify matrix 
>> multiplication and came across 
>> https://web.wpi.edu/Pubs/ETD/Available/etd-012318-234642/unrestricted/zli.pdf
>>
>> and http://www.ccs.neu.edu/home/viola/classes/gems-08/lectures/le21-23.pdf.
>>
>>
>>
>> The ways suggested here can be used even when the dimensions of matrix are 
>> not very large.
>>
>>
>>
>> Can this be of any help?
>>
>>
>>
>> On Thu, Mar 14, 2019 at 3:48 PM Vishesh Mangla  
>> wrote:
>>
>> Well if you see these algorithms are not for general purpose matrices but 
>> for where high accuracy is required. I would rather say to use concepts of 
>> group theory and representation theory (i do not have lot of knowledge about 
>> this but 'm studying) which can reduce matrices to lower dimensions.If you 
>> or your friends are from mathematical backgrounds they might be able to tell 
>> you better if this can make it easier what you want to do.
>>
&g

Re: [sympy] Gsoc Project idea " Efficient Equation ofMotionGenerationwith Python" discussion.

[Aaron Meurer]

For matrices in sympy, I suspect in most cases the best speed ups would
come from removing  overhead from the calculations, rather than from
algorithmic improvements. Many of the algorithms mentioned here are only
theoretically faster, or only faster asymptoticly. In some cases, they
would only be faster for matrices that are larger than anything sympy could
reasonably handle.

Benchmarking and profiling are very important if you are looking to improve
performance. Also take a look at the benchmarking idea on the GSoC ideas
page.

Aaron Meurer

On Thu, Mar 14, 2019 at 12:04 PM Vishesh Mangla 
wrote:

> Give me 2 days since currently I am having my mid sems. I will respond
> asap once I read it.
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *Jason Moore 
> *Sent: *14 March 2019 22:56
> *To: *sympy@googlegroups.com
> *Subject: *Re: [sympy] Gsoc Project idea " Efficient Equation
> ofMotionGenerationwith Python" discussion.
>
>
>
> Work to speed up matrix algorithms given assumptions on matrices would
> help.
>
>
>
> Jason
>
> moorepants.info
> +01 530-601-9791
>
>
>
>
>
> On Thu, Mar 14, 2019 at 9:31 AM Shiksha Rawat 
> wrote:
>
>
> https://web.wpi.edu/Pubs/ETD/Available/etd-012318-234642/unrestricted/zli.pdf 
> in
> this I think the description on "Embedding Matrix Multiplication in a
> Group Algebra "  on page number 10 can be helpful.
>
>
>
>
>
>
>
> On Thu, Mar 14, 2019 at 8:33 PM Shiksha Rawat 
> wrote:
>
> Can Jason Moore or Oscar suggest anything,please?
>
>
>
>
>
>
>
> On Thu, Mar 14, 2019 at 6:56 PM Vishesh Mangla 
> wrote:
>
> Well, I can’t say much because I ‘m not a maths student and just study
> maths because I like doing so.
>
> In this case you would be knowing it better than me.
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *Shiksha Rawat 
> *Sent: *14 March 2019 18:49
> *To: *sympy 
> *Subject: *Re: [sympy] Gsoc Project idea " Efficient Equation
> ofMotionGeneration with Python" discussion.
>
>
>
> Yes, I have studied group theory in my college curriculum.
>
> I tried to find ways by which group theory cap to used to simplify matrix
> multiplication and came across
> https://web.wpi.edu/Pubs/ETD/Available/etd-012318-234642/unrestricted/zli.pdf
>
> and http://www.ccs.neu.edu/home/viola/classes/gems-08/lectures/le21-23.pdf
> .
>
>
>
> The ways suggested here can be used even when the dimensions of matrix are
> not very large.
>
>
>
> Can this be of any help?
>
>
>
> On Thu, Mar 14, 2019 at 3:48 PM Vishesh Mangla 
> wrote:
>
> Well if you see these algorithms are not for general purpose matrices but
> for where high accuracy is required. I would rather say to use concepts of
> group theory and representation theory (i do not have lot of knowledge
> about this but 'm studying) which can reduce matrices to lower
> dimensions.If you or your friends are from mathematical backgrounds they
> might be able to tell you better if this can make it easier what you want
> to do.
>
>
>
> On Thu, Mar 14, 2019, 15:07  wrote:
>
> I think you are confused with numpy and scipy.I don't think the algorithm
> mentioned by you is much helpful to this cause. Could you please check out
> some more algorithm for the same.
>
> --
> 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 post to this group, send email to sympy@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/ff670eab-fe67-498c-ab45-b4abbd5018c5%40googlegroups.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 post to this group, send email to sympy@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/CACaE8x4ccaTQ3HsC6OGutHjkoJjBkKN%2BZ7VVz7gn%2BHZPzqCbUQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/sympy/CACaE8x4ccaTQ3HsC6OGutHjkoJjBkKN%2BZ7VVz7gn%2BHZPzqCbUQ%40mail.gmail.com?utm_medium=email_source=footer>
>

RE: [sympy] Gsoc Project idea " Efficient Equation ofMotionGenerationwith Python" discussion.

[Vishesh Mangla]

Give me 2 days since currently I am having my mid sems. I will respond asap 
once I read it.

Sent from Mail for Windows 10

From: Jason Moore
Sent: 14 March 2019 22:56
To: sympy@googlegroups.com
Subject: Re: [sympy] Gsoc Project idea " Efficient Equation 
ofMotionGenerationwith Python" discussion.

Work to speed up matrix algorithms given assumptions on matrices would help.

Jason
moorepants.info
+01 530-601-9791


On Thu, Mar 14, 2019 at 9:31 AM Shiksha Rawat  wrote:
https://web.wpi.edu/Pubs/ETD/Available/etd-012318-234642/unrestricted/zli.pdf 
in this I think the description on "Embedding Matrix Multiplication in a Group 
Algebra "  on page number 10 can be helpful.



On Thu, Mar 14, 2019 at 8:33 PM Shiksha Rawat  wrote:
Can Jason Moore or Oscar suggest anything,please?



On Thu, Mar 14, 2019 at 6:56 PM Vishesh Mangla  
wrote:
Well, I can’t say much because I ‘m not a maths student and just study maths 
because I like doing so.
In this case you would be knowing it better than me.
 
Sent from Mail for Windows 10
 
From: Shiksha Rawat
Sent: 14 March 2019 18:49
To: sympy
Subject: Re: [sympy] Gsoc Project idea " Efficient Equation ofMotionGeneration 
with Python" discussion.
 
Yes, I have studied group theory in my college curriculum.
I tried to find ways by which group theory cap to used to simplify matrix 
multiplication and came across 
https://web.wpi.edu/Pubs/ETD/Available/etd-012318-234642/unrestricted/zli.pdf
and http://www.ccs.neu.edu/home/viola/classes/gems-08/lectures/le21-23.pdf.
 
The ways suggested here can be used even when the dimensions of matrix are not 
very large.
 
Can this be of any help?
 
On Thu, Mar 14, 2019 at 3:48 PM Vishesh Mangla  
wrote:
Well if you see these algorithms are not for general purpose matrices but for 
where high accuracy is required. I would rather say to use concepts of group 
theory and representation theory (i do not have lot of knowledge about this but 
'm studying) which can reduce matrices to lower dimensions.If you or your 
friends are from mathematical backgrounds they might be able to tell you better 
if this can make it easier what you want to do. 
 
On Thu, Mar 14, 2019, 15:07  wrote:
I think you are confused with numpy and scipy.I don't think the algorithm 
mentioned by you is much helpful to this cause. Could you please check out some 
more algorithm for the same.

-- 
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 post to this group, send email to sympy@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/ff670eab-fe67-498c-ab45-b4abbd5018c5%40googlegroups.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 post to this group, send email to sympy@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/CACaE8x4ccaTQ3HsC6OGutHjkoJjBkKN%2BZ7VVz7gn%2BHZPzqCbUQ%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+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@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/CAKVsmS6yAn2JiMbOXuhEEB%2B59ucL6ii5nRtm107LP%2BTB%2BdW%2BLw%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+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@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/5c8a5671.1c69fb81.44872.5298%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 post to this group, send email to sympy@googlegroups.com.
Visit this group at https://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://gro