Re: [sympy] [RFC] change in Piecewise integration behavior

[Aaron Meurer]

This looks fine. Indefinite integration is only ever defined up to a
piecewise constant, so it isn't necessary to deprecate anything when
changing the mathematical form a result.

Aaron Meurer

On Wed, Jun 21, 2017 at 8:47 PM, Chris Smith  wrote:
> The following comes from my current `lts` branch:
>
>
 var('A:C')
> (A, B, C)
 i = Piecewise((A, x<1), (B, x>2), (C, True)).integrate(x); i  # new
 continuous result
> Piecewise((A*x, x <= 1), (A + C*x - C, x <= 2), (A + B*x - 2*B + C, True))
 for j in range(0,6):
> ...  j,i.subs(x,j)
> ...
> (0, 0)
> (1, A)
> (2, A + C)
> (3, A + B + C)
> (4, A + 2*B + C)
> (5, A + 3*B + C)
 pwi = Piecewise((A, x<1), (B, x>2), (C, True)).piecewise_integrate(x)  #
 old discontinuous result
 pwi
> Piecewise((A*x, x < 1), (B*x, x > 2), (C*x, True))
 for j in range(0,6):
> ...  j,pwi.subs(x,j)
> ...
> (0, 0)
> (1, C)
> (2, 2*C)
> (3, 3*B)
> (4, 4*B)
> (5, 5*B)
>
> The inequalities changing to equalities represents a corner case that I
> haven't addressed yet. It especially shows up when the derivatives of the
> integral are computed:
>
 i.diff(x)
> Piecewise((A, x <= 1), (C, x <= 2), (B, True))
 pwi.diff(x)
> Piecewise((A, x < 1), (B, x > 2), (C, True))
>
> The reversal of args is correct in the first case: the args are ordered
> according to spatial appearance along the x-axis.
>
> On Wednesday, June 21, 2017 at 9:21:44 AM UTC-5, Aaron Meurer wrote:
>>
>> Can you give an example of old vs. new behavior? Are they mathematically
>> equivalent (up to pievewise constant)?
>>
>> Aaron Meurer
>>
>> On Tue, Jun 20, 2017 at 8:37 AM Chris Smith  wrote:
>>>
>>> Currently, indefinite integration of Piecewise gives the discontinuous
>>> Piecewise result obtained by simply integrating the pieces of the Piecewise.
>>> I propose (in PR #12587) that the `integrate` method give the continuous
>>> result and a method `piecewise_integrate` be used to return the old
>>> behavior. Are there other ideas? Do we need a deprecation of the old
>>> behavior?
>>>
>>> --
>>> 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/95872e1e-ac0e-4b3d-b1c2-43520fa88158%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/23828d79-5a21-4961-9e84-977916751c64%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/CAKgW%3D6JDTMdhp%2B%2BzhHeZxY7xYKJ8_cR8FaihbaBpjLXhLuGybA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[sympy] SymPy release

[Aaron Meurer]

Hi all.

I'm happy to announce that NumFOCUS has provided some funding for me
to do a SymPy release as part of their small development grants. I
will be working on creating a SymPy release over the next couple of
weeks, with the goal of getting the release out in time for our code
generation tutorial at the SciPy conference.

What you can do to help:

- Please add any issue or pull request that should be fixed for the
release to the release milestone
https://github.com/sympy/sympy/milestone/46. Please be aware that this
release is on a tight schedule, so anything that cannot be fixed in
the short term will be postponed. Any review or coding help on
blocking issues is greatly appreciated.

- I will be creating a separate release branch. Modifications to
master may continue as usual.

- Any help on updating the release notes
(https://github.com/sympy/sympy/wiki/Release-Notes-for-1.1) is
appreciated.

I will also be working on updating the release automation. If anyone
wants to help in this effort, please see the upcoming pull request for
the release branch. If all goes well, we should be able to make
another point release (1.1.1) soon after the conference.

The are a few development processes that I would like to change for
the future, to make future releases easier to do. I will be sending
separate messages to the list about them.

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 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%3D6JH-7GBx1FfuDG8%2B4yV3GK3QxNDa5OYW9VOEXx4LPgi9Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] SymPy release

[Nathan Goldbaum]

Hi Aaron,

Will there be time to do a release candidate? Or should downstream projects
just check out the master branch and check if anything is broken right now?

-Nathan

On Thu, Jun 22, 2017 at 2:29 PM, Aaron Meurer  wrote:

> Hi all.
>
> I'm happy to announce that NumFOCUS has provided some funding for me
> to do a SymPy release as part of their small development grants. I
> will be working on creating a SymPy release over the next couple of
> weeks, with the goal of getting the release out in time for our code
> generation tutorial at the SciPy conference.
>
> What you can do to help:
>
> - Please add any issue or pull request that should be fixed for the
> release to the release milestone
> https://github.com/sympy/sympy/milestone/46. Please be aware that this
> release is on a tight schedule, so anything that cannot be fixed in
> the short term will be postponed. Any review or coding help on
> blocking issues is greatly appreciated.
>
> - I will be creating a separate release branch. Modifications to
> master may continue as usual.
>
> - Any help on updating the release notes
> (https://github.com/sympy/sympy/wiki/Release-Notes-for-1.1) is
> appreciated.
>
> I will also be working on updating the release automation. If anyone
> wants to help in this effort, please see the upcoming pull request for
> the release branch. If all goes well, we should be able to make
> another point release (1.1.1) soon after the conference.
>
> The are a few development processes that I would like to change for
> the future, to make future releases easier to do. I will be sending
> separate messages to the list about them.
>
> 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 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%3D6JH-7GBx1FfuDG8%2B4yV3GK3QxNDa5OYW9VOEXx4LPgi9
> Q%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/CAJXewO%3D4dbmv7X07DwWs1f9j6O-zSgQn%3DguF7DF15R4XYDving%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[sympy] Request for community input: removing versioned docs

[Aaron Meurer]

Hello all.

I would like input from the broader SymPy community here. Right now,
at http://docs.sympy.org/ we have versioned docs for each version
going back to 0.6.7, e.g., http://docs.sympy.org/0.7.3/index.html.

I am proposing to remove these. The only docs that would be on the
docs site are http://docs.sympy.org/latest/ (the default) and
http://docs.sympy.org/dev/ (built automatically from master). I am
undecided if existing versioned docs pages should be setup to redirect
to latest, provide a message, or just 404.

Two reasons why I want to do this:

- Empirically, many users end up on old docs pages, without
intentionally going there. Google search likes to return search
results from old docs pages. We have attempted to use the webmaster
tools to fix this, but just playing around with some random search
terms, it seems they still appear in the top of the results (e.g.,
"sympy ln" gives 0.7.1 docs as the first result).

- This gives the false impression that we support older versions. We
do not support any version of SymPy other than the latest version. We
do not make backport releases, except in extreme situations.

I am looking for feedback on this, whether you think it's a good idea,
a bad idea, or any suggestions.

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 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%3D6J0hZT3QVQpBaiEJgebb4nMaVtJG5sWB2gFF_p8umdi1Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] SymPy release

[Aaron Meurer]

I hope so, but it won't be out for long. It would definitely be
helpful if downstream projects checked against master now.

Aaron Meurer

On Thu, Jun 22, 2017 at 3:31 PM, Nathan Goldbaum  wrote:
> Hi Aaron,
>
> Will there be time to do a release candidate? Or should downstream projects
> just check out the master branch and check if anything is broken right now?
>
> -Nathan
>
> On Thu, Jun 22, 2017 at 2:29 PM, Aaron Meurer  wrote:
>>
>> Hi all.
>>
>> I'm happy to announce that NumFOCUS has provided some funding for me
>> to do a SymPy release as part of their small development grants. I
>> will be working on creating a SymPy release over the next couple of
>> weeks, with the goal of getting the release out in time for our code
>> generation tutorial at the SciPy conference.
>>
>> What you can do to help:
>>
>> - Please add any issue or pull request that should be fixed for the
>> release to the release milestone
>> https://github.com/sympy/sympy/milestone/46. Please be aware that this
>> release is on a tight schedule, so anything that cannot be fixed in
>> the short term will be postponed. Any review or coding help on
>> blocking issues is greatly appreciated.
>>
>> - I will be creating a separate release branch. Modifications to
>> master may continue as usual.
>>
>> - Any help on updating the release notes
>> (https://github.com/sympy/sympy/wiki/Release-Notes-for-1.1) is
>> appreciated.
>>
>> I will also be working on updating the release automation. If anyone
>> wants to help in this effort, please see the upcoming pull request for
>> the release branch. If all goes well, we should be able to make
>> another point release (1.1.1) soon after the conference.
>>
>> The are a few development processes that I would like to change for
>> the future, to make future releases easier to do. I will be sending
>> separate messages to the list about them.
>>
>> 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 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%3D6JH-7GBx1FfuDG8%2B4yV3GK3QxNDa5OYW9VOEXx4LPgi9Q%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/CAJXewO%3D4dbmv7X07DwWs1f9j6O-zSgQn%3DguF7DF15R4XYDving%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%3D6JKjOOA-m9uQj59qrw9%3DbCsnqujWC6viqtu4anOvj2hPA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[sympy] Re: Request for community input: removing versioned docs

[Francesco Bonazzi]

https://en.wikipedia.org/wiki/HTTP_301

On Thursday, 22 June 2017 15:38:28 UTC-4, Aaron Meurer wrote:
>
> Hello all. 
>
> I would like input from the broader SymPy community here. Right now, 
> at http://docs.sympy.org/ we have versioned docs for each version 
> going back to 0.6.7, e.g., http://docs.sympy.org/0.7.3/index.html. 
>
> I am proposing to remove these. The only docs that would be on the 
> docs site are http://docs.sympy.org/latest/ (the default) and 
> http://docs.sympy.org/dev/ (built automatically from master). I am 
> undecided if existing versioned docs pages should be setup to redirect 
> to latest, provide a message, or just 404. 
>
> Two reasons why I want to do this: 
>
> - Empirically, many users end up on old docs pages, without 
> intentionally going there. Google search likes to return search 
> results from old docs pages. We have attempted to use the webmaster 
> tools to fix this, but just playing around with some random search 
> terms, it seems they still appear in the top of the results (e.g., 
> "sympy ln" gives 0.7.1 docs as the first result). 
>
> - This gives the false impression that we support older versions. We 
> do not support any version of SymPy other than the latest version. We 
> do not make backport releases, except in extreme situations. 
>
> I am looking for feedback on this, whether you think it's a good idea, 
> a bad idea, or any suggestions. 
>
> 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 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/81d8514e-9fa3-44e4-92e7-296d06973a8a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Request for community input: removing versioned docs

[Nathan Goldbaum]

Hi Aaron,

A while back we modified our sphinx theme to add a "canonical" link:

https://github.com/yt-project/yt/blob/master/doc/source/_templates/layout.html#L4

After waiting for the googlebot to reindex our docs, google now seems to do
a good job of only linking to our stable docs (which live at
yt-project.org/doc).

Maybe sympy could do the same?

-Nathan

On Thu, Jun 22, 2017 at 2:38 PM, Aaron Meurer  wrote:

> Hello all.
>
> I would like input from the broader SymPy community here. Right now,
> at http://docs.sympy.org/ we have versioned docs for each version
> going back to 0.6.7, e.g., http://docs.sympy.org/0.7.3/index.html.
>
> I am proposing to remove these. The only docs that would be on the
> docs site are http://docs.sympy.org/latest/ (the default) and
> http://docs.sympy.org/dev/ (built automatically from master). I am
> undecided if existing versioned docs pages should be setup to redirect
> to latest, provide a message, or just 404.
>
> Two reasons why I want to do this:
>
> - Empirically, many users end up on old docs pages, without
> intentionally going there. Google search likes to return search
> results from old docs pages. We have attempted to use the webmaster
> tools to fix this, but just playing around with some random search
> terms, it seems they still appear in the top of the results (e.g.,
> "sympy ln" gives 0.7.1 docs as the first result).
>
> - This gives the false impression that we support older versions. We
> do not support any version of SymPy other than the latest version. We
> do not make backport releases, except in extreme situations.
>
> I am looking for feedback on this, whether you think it's a good idea,
> a bad idea, or any suggestions.
>
> 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 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%3D6J0hZT3QVQpBaiEJgebb4nMaVtJG5sWB2gFF_p8umdi1Q%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/CAJXewO%3DjaNSGYzvfCfBNV1SOTsQOsD2NREp08CnCrNYNSm4R0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[sympy] Re: Request for community input: removing versioned docs

[Björn Dahlgren]

On Thursday, 22 June 2017 21:38:28 UTC+2, Aaron Meurer wrote:
>
> I am looking for feedback on this, whether you think it's a good idea, 
> a bad idea, or any suggestions. 
>

I am +1 on removing them. If that is too harsh: one could also keep a 
archive of old docs
under e.g. docs.sympy.org/archive, with a banner stating that it is 
unsupported,
and with a robots.txt file asking search engines not to index that folder.

-- 
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/de255434-ebc0-43a5-9328-5f09d2cb639f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Re: Request for community input: removing versioned docs

[Aaron Meurer]

Our docs are hosted statically on GitHub pages, so I believe the only
way to do redirects is like we do currently
https://github.com/sympy/sympy_doc/blob/d8a3a2c81f4f26757f0be8699b7c3881b9b4147d/index.html.

Aaron Meurer

On Thu, Jun 22, 2017 at 3:44 PM, Francesco Bonazzi
 wrote:
> https://en.wikipedia.org/wiki/HTTP_301
>
>
> On Thursday, 22 June 2017 15:38:28 UTC-4, Aaron Meurer wrote:
>>
>> Hello all.
>>
>> I would like input from the broader SymPy community here. Right now,
>> at http://docs.sympy.org/ we have versioned docs for each version
>> going back to 0.6.7, e.g., http://docs.sympy.org/0.7.3/index.html.
>>
>> I am proposing to remove these. The only docs that would be on the
>> docs site are http://docs.sympy.org/latest/ (the default) and
>> http://docs.sympy.org/dev/ (built automatically from master). I am
>> undecided if existing versioned docs pages should be setup to redirect
>> to latest, provide a message, or just 404.
>>
>> Two reasons why I want to do this:
>>
>> - Empirically, many users end up on old docs pages, without
>> intentionally going there. Google search likes to return search
>> results from old docs pages. We have attempted to use the webmaster
>> tools to fix this, but just playing around with some random search
>> terms, it seems they still appear in the top of the results (e.g.,
>> "sympy ln" gives 0.7.1 docs as the first result).
>>
>> - This gives the false impression that we support older versions. We
>> do not support any version of SymPy other than the latest version. We
>> do not make backport releases, except in extreme situations.
>>
>> I am looking for feedback on this, whether you think it's a good idea,
>> a bad idea, or any suggestions.
>>
>> 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 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/81d8514e-9fa3-44e4-92e7-296d06973a8a%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/CAKgW%3D6J3R26YLzWVZUfaza9qTSUOS-LG_1%3DNNRQ9Rmunvzv92A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[sympy] Re: Request for community input: removing versioned docs

[Jason Moore]

It seems that many other scipy related packages handle this by giving big 
warnings at the top of old doc pages to manually redirect you. This seems 
to work for me the vast majority of the time, only occasionaly to I get 
stuck on old, for example. Readthedocs does this for your automatically too 
and has a nice sidebar that tells you what version of the docs you are on.

I'm not in favor of removing old docs because it is a real pain for the 
user to build old docs. I'd be more in favor of warnings on old doc pages.

On Thursday, June 22, 2017 at 12:38:28 PM UTC-7, Aaron Meurer wrote:
>
> Hello all. 
>
> I would like input from the broader SymPy community here. Right now, 
> at http://docs.sympy.org/ we have versioned docs for each version 
> going back to 0.6.7, e.g., http://docs.sympy.org/0.7.3/index.html. 
>
> I am proposing to remove these. The only docs that would be on the 
> docs site are http://docs.sympy.org/latest/ (the default) and 
> http://docs.sympy.org/dev/ (built automatically from master). I am 
> undecided if existing versioned docs pages should be setup to redirect 
> to latest, provide a message, or just 404. 
>
> Two reasons why I want to do this: 
>
> - Empirically, many users end up on old docs pages, without 
> intentionally going there. Google search likes to return search 
> results from old docs pages. We have attempted to use the webmaster 
> tools to fix this, but just playing around with some random search 
> terms, it seems they still appear in the top of the results (e.g., 
> "sympy ln" gives 0.7.1 docs as the first result). 
>
> - This gives the false impression that we support older versions. We 
> do not support any version of SymPy other than the latest version. We 
> do not make backport releases, except in extreme situations. 
>
> I am looking for feedback on this, whether you think it's a good idea, 
> a bad idea, or any suggestions. 
>
> 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 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/0b37c004-410b-4b4c-9b26-04375ac9392a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] how to convert latex expression into sympy expression?

[Richard Fateman]

see, for example,
https://people.eecs.berkeley.edu/~fateman/papers/mly-psmath.pdf

for a discussion.  It is really a consideration of "optical character 
recognition"
of math equations, where the characters are mostly perfectly represented,
and the spacing is perfectly represented.  But what is the meaning of, say,
a superscript?  

To find info, consider that google is your friend.
RJF

On Wednesday, June 14, 2017 at 3:24:25 PM UTC-7, Jason Moore wrote:
>
> Here is one option: https://github.com/augustt198/latex2sympy
>
> moorepants.info
> +01 530-601-9791
>
> On Wed, Jun 14, 2017 at 12:22 AM, Christophe BAL (via GMAIL) <
> proj...@gmail.com > wrote:
>
>> Hello.
>>
>> Because LaTeX is not mathmetically semantic, you can't have a perfect 
>> converter from LaTeX to SymPy. 
>>
>>
>>
>>
>> Le 14/06/2017 à 06:09, 8216...@qq.com  a écrit :
>>
>> I have a lot of latex expression, such as: 
>> a+b+c=0
>> abc>0
>> \frac{1}{a}+\frac{1}{b}+\frac{1}{c}
>> \left({a+b+c}\right)^2=a^2+b^2+c^2+2ab+2bc+2ac=0
>>
>> I want a function, let's say latex2sympy(latex), to convert latex to 
>> sympy expression?
>>
>> how can i do that?
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "sympy" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to sympy+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/5f86b9c7-1ace-410c-aeb7-c57f505c42ff%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> -- 
>> Christophe BAL
>> Enseignant Agrégé de Mathématiques
>> Programmeur Python Amateur
>>
>> -- 
>> 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/9dedee5e-10c9-6ef5-2a33-2c1f3591323c%40gmail.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/db292e42-f453-4b0a-a97a-957f068db953%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sympy] Re: Request for community input: removing versioned docs

[Shekhar Prasad Rajak]

I think it will be good to have big warnings at the top of old doc pages, 
as Jason Moore said.

--
Shekhar

On Friday, 23 June 2017 01:22:38 UTC+5:30, Jason Moore wrote:
>
> It seems that many other scipy related packages handle this by giving big 
> warnings at the top of old doc pages to manually redirect you. This seems 
> to work for me the vast majority of the time, only occasionaly to I get 
> stuck on old, for example. Readthedocs does this for your automatically too 
> and has a nice sidebar that tells you what version of the docs you are on.
>
> I'm not in favor of removing old docs because it is a real pain for the 
> user to build old docs. I'd be more in favor of warnings on old doc pages.
>
> On Thursday, June 22, 2017 at 12:38:28 PM UTC-7, Aaron Meurer wrote:
>>
>> Hello all. 
>>
>> I would like input from the broader SymPy community here. Right now, 
>> at http://docs.sympy.org/ we have versioned docs for each version 
>> going back to 0.6.7, e.g., http://docs.sympy.org/0.7.3/index.html. 
>>
>> I am proposing to remove these. The only docs that would be on the 
>> docs site are http://docs.sympy.org/latest/ (the default) and 
>> http://docs.sympy.org/dev/ (built automatically from master). I am 
>> undecided if existing versioned docs pages should be setup to redirect 
>> to latest, provide a message, or just 404. 
>>
>> Two reasons why I want to do this: 
>>
>> - Empirically, many users end up on old docs pages, without 
>> intentionally going there. Google search likes to return search 
>> results from old docs pages. We have attempted to use the webmaster 
>> tools to fix this, but just playing around with some random search 
>> terms, it seems they still appear in the top of the results (e.g., 
>> "sympy ln" gives 0.7.1 docs as the first result). 
>>
>> - This gives the false impression that we support older versions. We 
>> do not support any version of SymPy other than the latest version. We 
>> do not make backport releases, except in extreme situations. 
>>
>> I am looking for feedback on this, whether you think it's a good idea, 
>> a bad idea, or any suggestions. 
>>
>> 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 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/68a36c45-5229-4265-9a0c-ad0d7bc653e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sympy] Updating SymPy changelog process

[Aaron Meurer]

Once I have finished the SymPy release, I would like to make an update
to how we do changelogs.

Right now, changelog entries are made manually on the wiki, at
https://github.com/sympy/sympy/wiki/Release-Notes. The issue with this
is that very few people update the release notes when pull request
changes are made, so we end up with a long list of changes that need
to be added to the release notes at release time. This results in the
release notes generally not being done very well, because there are
typically too many changes to reasonably go through and add to the
notes.

My suggestion is to require each pull request to add its own release
notes entry as part of the PR. The PR won't be mergeable unless it has
a release notes entry.

The way to achieve this is to move the release notes from the wiki to
the main SymPy repo. The process that seems to work well is this:

- There is a directory changelog/ in the repo. Every pull request adds
a new file to this directory. The name of the file does not matter (a
good convention is branchname.rst).  This file follows a template
format, like

**Backwards incompatible changes:**

...

**Major changes:**

...

**Minor changes:**

...

(the header names could be different). Each PR adds bullet points for
the changes made in that PR.

Then at release time, the release script takes all the files in
changelog.rst and amalgamates them into a single changelog file for
that release.

The separate files makes it so that there are never git merge
conflicts (so long as people chose unique filenames).

Each pull request would have a check in the tests to make sure that it
adds or modifies a changelog file. There could also be some way to
tell the tests that the change is too minor to require a changelog
entry (say, if it has "SKIP CHANGELOG" in the PR text).

This process was suggested to me by Anthony Scopatz, who uses it in
Xonsh https://github.com/xonsh/xonsh/blob/master/CONTRIBUTING.rst#changelog.

I would appreciate any thoughts or suggestions on this. It will likely
not be implemented until after the release.

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 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%3D6JnXOn7A%2B-J%2BMWRyg05CP05rq%2BzCJ719V2B9OaE5AyePw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Updating SymPy changelog process

[Jason Moore]

I fully support this!

moorepants.info
+01 530-601-9791

On Thu, Jun 22, 2017 at 1:17 PM, Aaron Meurer  wrote:

> Once I have finished the SymPy release, I would like to make an update
> to how we do changelogs.
>
> Right now, changelog entries are made manually on the wiki, at
> https://github.com/sympy/sympy/wiki/Release-Notes. The issue with this
> is that very few people update the release notes when pull request
> changes are made, so we end up with a long list of changes that need
> to be added to the release notes at release time. This results in the
> release notes generally not being done very well, because there are
> typically too many changes to reasonably go through and add to the
> notes.
>
> My suggestion is to require each pull request to add its own release
> notes entry as part of the PR. The PR won't be mergeable unless it has
> a release notes entry.
>
> The way to achieve this is to move the release notes from the wiki to
> the main SymPy repo. The process that seems to work well is this:
>
> - There is a directory changelog/ in the repo. Every pull request adds
> a new file to this directory. The name of the file does not matter (a
> good convention is branchname.rst).  This file follows a template
> format, like
>
> **Backwards incompatible changes:**
>
> ...
>
> **Major changes:**
>
> ...
>
> **Minor changes:**
>
> ...
>
> (the header names could be different). Each PR adds bullet points for
> the changes made in that PR.
>
> Then at release time, the release script takes all the files in
> changelog.rst and amalgamates them into a single changelog file for
> that release.
>
> The separate files makes it so that there are never git merge
> conflicts (so long as people chose unique filenames).
>
> Each pull request would have a check in the tests to make sure that it
> adds or modifies a changelog file. There could also be some way to
> tell the tests that the change is too minor to require a changelog
> entry (say, if it has "SKIP CHANGELOG" in the PR text).
>
> This process was suggested to me by Anthony Scopatz, who uses it in
> Xonsh https://github.com/xonsh/xonsh/blob/master/
> CONTRIBUTING.rst#changelog.
>
> I would appreciate any thoughts or suggestions on this. It will likely
> not be implemented until after the release.
>
> 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 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%3D6JnXOn7A%2B-J%2BMWRyg05CP05rq%
> 2BzCJ719V2B9OaE5AyePw%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/CAP7f1AgkHCFWQGYsMsQ-0CznDzQ%2BU3gMMftnAsPwhAwy6kxG-A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Updating SymPy changelog process

[Anthony Scopatz]

Hi All,

I'd like to say that for xonsh we find this strategy incredibly useful.
This was inspired originally by http://keepachangelog.com/en/1.0.0/

Let me know if you need any clarifications.

Be Well
Anthony

On Thu, Jun 22, 2017 at 4:18 PM Aaron Meurer  wrote:

> Once I have finished the SymPy release, I would like to make an update
> to how we do changelogs.
>
> Right now, changelog entries are made manually on the wiki, at
> https://github.com/sympy/sympy/wiki/Release-Notes. The issue with this
> is that very few people update the release notes when pull request
> changes are made, so we end up with a long list of changes that need
> to be added to the release notes at release time. This results in the
> release notes generally not being done very well, because there are
> typically too many changes to reasonably go through and add to the
> notes.
>
> My suggestion is to require each pull request to add its own release
> notes entry as part of the PR. The PR won't be mergeable unless it has
> a release notes entry.
>
> The way to achieve this is to move the release notes from the wiki to
> the main SymPy repo. The process that seems to work well is this:
>
> - There is a directory changelog/ in the repo. Every pull request adds
> a new file to this directory. The name of the file does not matter (a
> good convention is branchname.rst).  This file follows a template
> format, like
>
> **Backwards incompatible changes:**
>
> ...
>
> **Major changes:**
>
> ...
>
> **Minor changes:**
>
> ...
>
> (the header names could be different). Each PR adds bullet points for
> the changes made in that PR.
>
> Then at release time, the release script takes all the files in
> changelog.rst and amalgamates them into a single changelog file for
> that release.
>
> The separate files makes it so that there are never git merge
> conflicts (so long as people chose unique filenames).
>
> Each pull request would have a check in the tests to make sure that it
> adds or modifies a changelog file. There could also be some way to
> tell the tests that the change is too minor to require a changelog
> entry (say, if it has "SKIP CHANGELOG" in the PR text).
>
> This process was suggested to me by Anthony Scopatz, who uses it in
> Xonsh
> https://github.com/xonsh/xonsh/blob/master/CONTRIBUTING.rst#changelog.
>
> I would appreciate any thoughts or suggestions on this. It will likely
> not be implemented until after the release.
>
> 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 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%3D6JnXOn7A%2B-J%2BMWRyg05CP05rq%2BzCJ719V2B9OaE5AyePw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 

Asst. Prof. Anthony Scopatz
Nuclear Engineering Program
Mechanical Engineering Dept.
University of South Carolina
scop...@cec.sc.edu
Office: (803) 777-9334
Cell: (512) 827-8239
Office: Horizon 1, #011 (ground floor, not first)
Book a meeting with me at https://scopatz.youcanbook.me/
Open up an issue: https://github.com/scopatz/me/issues
Check my calendar


-- 
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/CAPk-6T5rANGBmNXtJtij%2BxOT1EFvk8mvTCGuVrS38-zOOrYm5g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Issues with integrate and piecewise functions

[Chris Smith]

Here is an example from the `lts` branch computing the product of two 
functions
that have different ranges in each:

>>> p = Piecewise((a,abs(x-1)<1),(b,abs(x-2)<2),(c,True))*Piecewise((d,x>1
),(e,True))
>>> piecewise_fold(p)
Piecewise(
(a*d, (x > 1) & (x < 2)), 
(b*d, (x > 1) & (x < 4)), 
(c*d, x > 1), 
(a*e, Abs(x - 1) < 1), 
(b*e, Abs(x - 2) < 2), 
(c*e, True))
>>> _.integrate(x).diff(x)
Piecewise(
(c*e, x <= 0), 
(a*e, x <= 1), 
(a*d, x <= 2), 
(b*d, x <= 4), 
(c*d, True))


[Note that value `b*e` does not appear in the final result because it has 
been determined to not appear because higher priority expression are 
defined on the range in which `b*e` is defined.]

I like the idea of range_function. Here are two ways it might be done:

>>> def range_function(x, *args):
...  return Piecewise(*[
...   (a[0], And(x>=a[1],x<=a[2])) for a in args])
...
>>> range_function(x, (a,1,2),(b,3,4),(c,0,6))
Piecewise((a, (x >= 1) & (x <= 2)), (b, (x >= 3) & (x <= 4)), (c, (x >= 0) & 
(x <= 6)))


>>> def interval_function(x, *args):
...  return Piecewise(*[
...   (a[0], a[1].contains(x)) for a in args])
...
>>> interval_function(x, (a,Interval(1,2)),(b,Interval.Lopen(0,4)))
Piecewise((a, (x >= 1) & (x <= 2)), (b, (x <= 4) & (x > 0)))


On Sunday, June 11, 2017 at 4:33:28 PM UTC-5, bonc...@udel.edu wrote:
>
>
>
> On Wednesday, June 7, 2017 at 5:49:34 PM UTC-4, Aaron Meurer wrote:
>>
>>
>>
>> > 
>> > My thoughts on Piecewise is that it's trying to do too many things. 
>>  There's 
>> > a difference between representing a function whose form changes 
>> depending on 
>> > the value of its argument (in my case, t) and an answer that depends on 
>> > parameter values (a and b).  The latter distinction is best described 
>> with a 
>> > cases statement.  I.e., t is different from a and b. 
>>
>> I'm not sure I follow here. Are you suggesting to use a separate 
>> object. What would it look like? 
>>
>> I'm thinking of a "range" object (I wish the name "Piecewise" was still 
> available). Something like this:
>
> f = range_function([(f1,t1,t2),(f2,t3,t4),...],t)
>
> The first argument is a list of functions with the range of the arguments 
> for that function. The final argument is the variable.  The notation mimics 
> the integrate function. 
>
> I've written a partially completed convolution function for these range 
> functions.  Convolution requires knowing the range of each function.  But I 
> got stuck when I ran the example before whose answer depends on parameter 
> values.  That the answer depends on parameter values is the job for a 
> "cases" function (like the Latex cases function).
>
> The last step (which I haven't finished, but it's straightforward) is to 
> combine the outputs of the various convolutions into a range function.
>
> I haven't given much thought how to extend the range function to multiple 
> variables.  It's probably straightforward when the ranges are rectangles, 
> but maybe less for other shapes (e.g., circles).
>
>  
>

-- 
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/4a050b71-9821-4062-b107-1165192287d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.