Re: [sympy] small questions about manipulating equations and sums
On Fri, 1 May 2020 at 23:59, David Bailey wrote:
>
> On 01/05/2020 23:44, Oscar Benjamin wrote:
>
> On Fri, 1 May 2020 at 12:09, David Bailey wrote:
>
> On 01/05/2020 00:32, Oscar Benjamin wrote:
>
> Hi Aaron,
>
> Yes, if we had Equation we should disallow its use in an expression. I
> don't see any situation where it would make sense. We would need a
> clear distinction between Equation and Equality as well as methods to
> convert between them.
>
> 1. Equality is a Boolean
> 2. Equation is Basic
> 3. Neither is Expr
> 4. You can use `.as_Boolean/.as_Equation` or something to convert between
> 5. Equation should be used instead of Equality for e.g. passing
> equations to solve/dsolve and for returning solutions.
> 6. Equation should be invalid in any Boolean context
> 7. Equality should not support any of the arithmetic manipulations
> that Equation does
> 8. Equation should be usable in subs or subseq or something (but
> Equality should not)
> 9. Equation should have a solve method for making something the lhs
> 10. Documentation should find a way of making this understandable...
>
> Hang on, doesn't that exclude the very operations we were just discussing,
> such as
>
> 3+Equation(a-3,b-3)
>
> That example works fine with Equation:
>
> In [5]: a, b = symbols('a, b')
>
> In [6]: 3+Equation(a-3,b-3)
> Out[6]: a = b
>
> Yes but isn't that inconsistent with your statement "Yes, if we had Equation
> we should disallow its use in an expression"? Surely the example we are
> discussing is an Equation embedded in an expression!
There is a difference between having an object as part of an
expression and having an object that supports arithmetic operations.
Objects of type Expr support arithmetic operations and by default the
result creates an expression involving the original object so e.g. a+b
becomes Add(a, b). That's what happens with Eq in sympy 1.5 because in
1.5 Eq is a subclass of Expr so Eq(a, b)+1 becomes Add(Eq(a, b), 1)
which is nonsensical. In 1.6 Eq does not subclass Expr and also Expr
is fussier about what types it can interact with through arithmetic
operations so this gives an error.
The point of Equation is that it can support some arithmetic
operations and the result will always be an Equation and never an
expression. It should never be a part of an expression though so e.g.
Add(Equation(x, y), z) is an error because Add is of type Expr and its
arguments need to be of type Expr but Equation is not of type Expr.
That does not preclude Equation(x,y)+1 giving an Equation though.
--
Oscar
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAHVvXxQOuE_VKo6DFmVjNMBQ9MbNotvRv8Vif_A2KarhfZNYLA%40mail.gmail.com.
Re: [sympy] small questions about manipulating equations and sums
On 01/05/2020 23:44, Oscar Benjamin wrote:
On Fri, 1 May 2020 at 12:09, David Bailey wrote:
On 01/05/2020 00:32, Oscar Benjamin wrote:
Hi Aaron,
Yes, if we had Equation we should disallow its use in an expression. I
don't see any situation where it would make sense. We would need a
clear distinction between Equation and Equality as well as methods to
convert between them.
1. Equality is a Boolean
2. Equation is Basic
3. Neither is Expr
4. You can use `.as_Boolean/.as_Equation` or something to convert between
5. Equation should be used instead of Equality for e.g. passing
equations to solve/dsolve and for returning solutions.
6. Equation should be invalid in any Boolean context
7. Equality should not support any of the arithmetic manipulations
that Equation does
8. Equation should be usable in subs or subseq or something (but
Equality should not)
9. Equation should have a solve method for making something the lhs
10. Documentation should find a way of making this understandable...
Hang on, doesn't that exclude the very operations we were just discussing, such
as
3+Equation(a-3,b-3)
That example works fine with Equation:
In [5]: a, b = symbols('a, b')
In [6]: 3+Equation(a-3,b-3)
Out[6]: a = b
Yes but isn't that inconsistent with your statement "Yes, if we had
Equation we should disallow its use in an expression"? Surely the
example we are discussing *is *an Equation embedded in an expression!
Sorry, I am probably missing something!
David
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/446ac9c7-bd50-142c-1f06-9d75eb8af9b5%40dbailey.co.uk.
Re: [sympy] small questions about manipulating equations and sums
On Fri, 1 May 2020 at 12:09, David Bailey wrote:
>
> On 01/05/2020 00:32, Oscar Benjamin wrote:
>
> Hi Aaron,
>
> Yes, if we had Equation we should disallow its use in an expression. I
> don't see any situation where it would make sense. We would need a
> clear distinction between Equation and Equality as well as methods to
> convert between them.
>
> 1. Equality is a Boolean
> 2. Equation is Basic
> 3. Neither is Expr
> 4. You can use `.as_Boolean/.as_Equation` or something to convert between
> 5. Equation should be used instead of Equality for e.g. passing
> equations to solve/dsolve and for returning solutions.
> 6. Equation should be invalid in any Boolean context
> 7. Equality should not support any of the arithmetic manipulations
> that Equation does
> 8. Equation should be usable in subs or subseq or something (but
> Equality should not)
> 9. Equation should have a solve method for making something the lhs
> 10. Documentation should find a way of making this understandable...
>
> Hang on, doesn't that exclude the very operations we were just discussing,
> such as
>
> 3+Equation(a-3,b-3)
That example works fine with Equation:
In [5]: a, b = symbols('a, b')
In [6]: 3+Equation(a-3,b-3)
Out[6]: a = b
It doesn't work with Eq/Equality though. E.g. in 1.6:
In [7]: 3+Eq(a-3,b-3)
---
TypeError Traceback (most recent call last)
in
> 1 3+Eq(a-3,b-3)
TypeError: unsupported operand type(s) for +: 'int' and 'Equality'
--
Oscar
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAHVvXxTfeGTAOpbPKpD-GCRc_NM0n%3DyXSBC63ztp34LaR-2nJQ%40mail.gmail.com.
Re: [sympy] Re: Google Season of Docs organization application
Hi Aaron, I have filled out the form and will be happy to mentor for the program. Regards, Nikhil Maan On Saturday, May 2, 2020 at 12:47:02 AM UTC+5:30, Aaron Meurer wrote: > > I am working on the organization application for GSoD now. > > Anyone who is interested in mentoring, please let me know, and also > fill out this form https://bit.ly/gsod-mentor-reg. > > The deadline for the application is Monday. If you are interested in > mentoring, please let me know right away so I can get an idea if we > should request 1 slot or 2. > > Aaron Meurer > > On Fri, Apr 17, 2020 at 1:54 PM Aaron Meurer > wrote: > > > > I would first like to remind everyone that we participated in Google > > Season of Docs last year. This is the report of the project > > > https://github.com/sympy/sympy/wiki/GSoD-2019-Report-Lauren-Glattly:-SymPy-Documentation-Style-Guide. > > > > The technical writer, Lauren Glattly, did not write code. However, > > several proposals came up as part of the project that involved code. > > We as mentors we able to assist in this. You can see from this > > milestone https://github.com/sympy/sympy/milestone/54 some of the code > > related ideas that were implemented, and some which aren't implemented > > yet. > > I've asked on the GSoD slack if they have any official policies about > > code related ideas. I didn't find anything in their guides, although > > all of their example ideas do not involve any coding > > https://developers.google.com/season-of-docs/docs/project-ideas. > > > > My personal view is this: we have an entire community who knows how to > > code, and how to do the above ideas. We even have programs like Google > > Summer of Code and NumFOCUS small development grants to pay for these > > things. On the other hand, we don't have any kind of technical writing > > expertise in our community. The aim of Google Season of Docs is to > > give open source projects some of that expertise. So even if code > > projects were allowed, I feel that they would be squandering the > > opportunity. There are lots of improvements that our documentation > > needs that doesn't involve any code. There are even ideas that don't > > require deep knowledge of SymPy or Python. But what they do require is > > someone who understands how to write documentation in a clear and > > consistent way that makes it easiest for users to understand. > > > > Aaron Meurer > > > > On Wed, Apr 15, 2020 at 7:40 PM Nikhil Maan > wrote: > > > > > > I am also interested in mentoring for GSoD. I am pretty familiar with > the documentation, and I also have some prior experience as a technical > writer, which might be useful during the program. > > > As for the question of scope, the program is meant for technical > writers, who might not be too familiar with the language and the tools we > are using, apart from what's required for the documentation. So, any ideas > that require altering code should be kept out of scope IMO. > > > > > > 2. Examples are an essential part of any documentation, especially > end-user documentation. So, writing code examples should be kept in scope. > If the writers face some difficulties while writing examples, the mentors > should be able to help them. > > > > > > 3. From what I found, meijerint_doc is built using a python script, > and it would require making changes to the code to modify the docs. I think > this should be out of scope. > > > > > > I am not sure about 1 and 4. The GSoD guides list some frameworks, > including sphinx, to build the documentation( > https://developers.google.com/season-of-docs/docs/project-ideas). But, I > am not sure to what extent we should expect the writers to be familiar with > the frameworks, and HTML and JS for that matter. I think it depends on the > organization and our requirements. > > > > > > Regards, > > > Nikhil Maan > > > > > > On Wednesday, April 15, 2020 at 6:59:42 PM UTC+5:30, S.Y. Lee wrote: > > >> > > >> I'm interested in joining the GSoD as a mentor, for some prior > experiences in solving the sphinx issues in the community. > > >> But I'd have some other questions to clarify what kind of ideas from > below are clearly out of scope regarding the comment. > > >> > > >>> Ideas that involve writing code are generally out of scope for GSoD. > > >> > > >> Modifying the sphinx extension. > > >> Writing example codes for the doc. > > >> Automatically generated docs like meijerint_doc. > > >> Other projects related to the doc website, but which requires some > knowledge in HTML or javascript. > > >> > > >> > > >> On Tuesday, April 14, 2020 at 5:36:55 AM UTC+9, Aaron Meurer wrote: > > >>> > > >>> The Google Season of Docs (GSoD) organization applications are now > > >>> open. See > https://developers.google.com/season-of-docs/docs/admin-guide. > > >>> > > >>> If anyone is interested in being a mentor for Google Season of Docs, > > >>> please let me know about it and
Re: [sympy] Re: Google Season of Docs organization application
I am working on the organization application for GSoD now. Anyone who is interested in mentoring, please let me know, and also fill out this form https://bit.ly/gsod-mentor-reg. The deadline for the application is Monday. If you are interested in mentoring, please let me know right away so I can get an idea if we should request 1 slot or 2. Aaron Meurer On Fri, Apr 17, 2020 at 1:54 PM Aaron Meurer wrote: > > I would first like to remind everyone that we participated in Google > Season of Docs last year. This is the report of the project > https://github.com/sympy/sympy/wiki/GSoD-2019-Report-Lauren-Glattly:-SymPy-Documentation-Style-Guide. > The technical writer, Lauren Glattly, did not write code. However, > several proposals came up as part of the project that involved code. > We as mentors we able to assist in this. You can see from this > milestone https://github.com/sympy/sympy/milestone/54 some of the code > related ideas that were implemented, and some which aren't implemented > yet. > I've asked on the GSoD slack if they have any official policies about > code related ideas. I didn't find anything in their guides, although > all of their example ideas do not involve any coding > https://developers.google.com/season-of-docs/docs/project-ideas. > > My personal view is this: we have an entire community who knows how to > code, and how to do the above ideas. We even have programs like Google > Summer of Code and NumFOCUS small development grants to pay for these > things. On the other hand, we don't have any kind of technical writing > expertise in our community. The aim of Google Season of Docs is to > give open source projects some of that expertise. So even if code > projects were allowed, I feel that they would be squandering the > opportunity. There are lots of improvements that our documentation > needs that doesn't involve any code. There are even ideas that don't > require deep knowledge of SymPy or Python. But what they do require is > someone who understands how to write documentation in a clear and > consistent way that makes it easiest for users to understand. > > Aaron Meurer > > On Wed, Apr 15, 2020 at 7:40 PM Nikhil Maan wrote: > > > > I am also interested in mentoring for GSoD. I am pretty familiar with the > > documentation, and I also have some prior experience as a technical writer, > > which might be useful during the program. > > As for the question of scope, the program is meant for technical writers, > > who might not be too familiar with the language and the tools we are using, > > apart from what's required for the documentation. So, any ideas that > > require altering code should be kept out of scope IMO. > > > > 2. Examples are an essential part of any documentation, especially end-user > > documentation. So, writing code examples should be kept in scope. If the > > writers face some difficulties while writing examples, the mentors should > > be able to help them. > > > > 3. From what I found, meijerint_doc is built using a python script, and it > > would require making changes to the code to modify the docs. I think this > > should be out of scope. > > > > I am not sure about 1 and 4. The GSoD guides list some frameworks, > > including sphinx, to build the > > documentation(https://developers.google.com/season-of-docs/docs/project-ideas). > > But, I am not sure to what extent we should expect the writers to be > > familiar with the frameworks, and HTML and JS for that matter. I think it > > depends on the organization and our requirements. > > > > Regards, > > Nikhil Maan > > > > On Wednesday, April 15, 2020 at 6:59:42 PM UTC+5:30, S.Y. Lee wrote: > >> > >> I'm interested in joining the GSoD as a mentor, for some prior experiences > >> in solving the sphinx issues in the community. > >> But I'd have some other questions to clarify what kind of ideas from below > >> are clearly out of scope regarding the comment. > >> > >>> Ideas that involve writing code are generally out of scope for GSoD. > >> > >> Modifying the sphinx extension. > >> Writing example codes for the doc. > >> Automatically generated docs like meijerint_doc. > >> Other projects related to the doc website, but which requires some > >> knowledge in HTML or javascript. > >> > >> > >> On Tuesday, April 14, 2020 at 5:36:55 AM UTC+9, Aaron Meurer wrote: > >>> > >>> The Google Season of Docs (GSoD) organization applications are now > >>> open. See https://developers.google.com/season-of-docs/docs/admin-guide. > >>> > >>> If anyone is interested in being a mentor for Google Season of Docs, > >>> please let me know about it and fill out the mentor form there. If you > >>> are interested in being a co-admin let me know about that too. > >>> > >>> The deadline to submit our application is May 4. > >>> > >>> I will start a wiki page for the application soon. For now, if you > >>> have any ideas for Google Season of Docs, please edit the ideas page > >>>
[sympy] Regarding Gsoc project in Series Expansions
Currently I am going through the gruntz thesis and references which are related to limit module (have started bit early compared to the schedule mentioned in my proposal as my college is closed due to covid-19 effect, so I can denote enough time on this project). I am currently working on some of the issues.It would be really helpful if someone could guide me on this topic and review my work in future. Below I have attached the link to my proposal. Regards Saanidhya vats Link to proposal: https://docs.google.com/document/d/1Ym2rE1Ucw_A8fcdDT3PQmSyxUQDvGhX6QoBS1dDSIB8/edit?usp=sharing -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/637c5892-3e53-4d45-bb1d-b0dd5419122f%40googlegroups.com.
Re: [sympy] small questions about manipulating equations and sums
On 01/05/2020 00:32, Oscar Benjamin wrote: Hi Aaron, Yes, if we had Equation we should disallow its use in an expression. I don't see any situation where it would make sense. We would need a clear distinction between Equation and Equality as well as methods to convert between them. 1. Equality is a Boolean 2. Equation is Basic 3. Neither is Expr 4. You can use `.as_Boolean/.as_Equation` or something to convert between 5. Equation should be used instead of Equality for e.g. passing equations to solve/dsolve and for returning solutions. 6. Equation should be invalid in any Boolean context 7. Equality should not support any of the arithmetic manipulations that Equation does 8. Equation should be usable in subs or subseq or something (but Equality should not) 9. Equation should have a solve method for making something the lhs 10. Documentation should find a way of making this understandable... Hang on, doesn't that exclude the very operations we were just discussing, such as 3+Equation(a-3,b-3) David -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/38ea233b-23fd-94a7-65a9-299982085527%40dbailey.co.uk.
[sympy] Re: small questions about manipulating equations and sums
https://github.com/sympy/sympy/pull/18174 is open for the ability to work with equations and https://github.com/sympy/sympy/issues/19191 for extracting constants/sign from Integral/Sum. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55a4ab2b-f731-4754-b7e3-ac73adac6aaa%40googlegroups.com.
[sympy] Re: small questions about manipulating equations and sums
I think #19191 addresses removal of constant/sign from Sum/Integral. And #18174 addresses the ability to work with equations. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5a3f5aa1-53ea-4d08-91f3-bb5be7b94390%40googlegroups.com.
[sympy] Re: small questions about manipulating equations and sums
Do you want me to open issues on GitHub? This is actually two topic (equations and sums), an I should have known better than to combine them. > > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/7433fa25-0bf7-4961-9f5a-af8ec6c625c8%40googlegroups.com.
