Re: [sympy] We need some community input on the desired behavior of an equation class...

[gu...@uwosh.edu]

I think the issue is whether we are thinking about this as computer code or 
a computer tool for doing mathematics.

I believe the mathematical concept of an equation that connects two 
expressions with an equals sign also implies an assignment. When you write 
`a = b/c` on a piece of paper the equation implies: `a==b/c` assuming no 
mistake is made. It implies you can calculate a by taking b and dividing it 
by c. It implies that you can rearrange it to calculate b or c from the 
other two variable.  It also implies: `da/db = 1/c` and so on. I see little 
value to the equation class if it simply is the equivalent of a list of two 
expressions that operations are distributed over. I think SymPy pretty much 
covers that behavior with vectors or just Python lists.

I have also made some more elaborate comments in the draft SymPEP for the 
equation class 
. But 
in summary they point out that if we apply operations such as diff() the 
same to both sides of an equation we arrive at expressions that are not 
consistent in a general way with the application of derivatives to an 
equation. 

An equation class that behaves as a list of two expressions which is 
displayed with an equals sign between the two expressions is certainly 
easier to implement. However, IMHO an equation with an equals sign *is* 
more than that.

Jonathan
On Thursday, February 4, 2021 at 4:51:31 PM UTC-6 asme...@gmail.com wrote:

> On Thu, Feb 4, 2021 at 2:18 PM Matthias Geier  
> wrote:
> >
> > Hi all.
> >
> > First of all, thanks for all the effort all of you are putting into
> > SymPy in general and into the upcoming Equation class specifically!
> >
> > I'm not sure whether I fully understand either side of the contentious
> > questions mentioned in this thread, but let me nevertheless add my
> > opinion:
> >
> > I think what Jonathan describes is a mixture of two things:
> >
> > * an "equation" where operations can be applied on both sides
> > * a "definition" or "assignment" where an expression (on the right
> > side) gets a new name (on the left side)
> >
> > I'm quite sure that those should be two separate classes, but I'm not
> > sure whether *both* should be part of SymPy.
> >
> > I think the "Equation" class should never treat the two sides
> > differently (unless explicitly requested by "rhs" or "lhs" stuff, and
> > probably as argument to subs()?).
>
> I agree with this.
>
> Incidentally, there is an Assignment class in SymPy, in the codegen
> module. It is designed specifically around generating code, so it
> might not apply to the use cases here.
>
> Aaron Meurer
>
> >
> > However, I can very much appreciate the desire to have a symbol that
> > represents an expression, where both are displayed nicely with an
> > equals sign in between.
> >
> > FWIW, I've somewhat recently created an ad-hoc class called
> > "NamedExpression" that does some of what Jonathan describes.
> >
> > It's defined there:
> > 
> https://github.com/AudioSceneDescriptionFormat/splines/blob/master/doc/euclidean/utility.py
> >
> > And there's an example using it:
> > https://splines.readthedocs.io/en/latest/euclidean/hermite-uniform.html
> >
> > Apart from derivatives, there is also .evaluate_at() which treats the
> > two sides of the equation differently.
> >
> > On top of that, I've also made a "NamedMatrix" class with a few
> > additional features specific to matrices.
> > For example it allows to invert and transpose both sides (which is
> > also shown in the example mentioned above).
> >
> > As a special feature it has also a .pull_out() method, which allows to
> > pull a common factor out of all matrix coefficients.
> >
> > I'm not suggesting to implement any of this in SymPy, probably it is
> > much too specific and uses some assumptions that are not appropriate
> > for general use.
> >
> > Probably something like this could become a separate Python module
> > (targeted at teaching) using building blocks from SymPy (like the
> > upcoming Equation class)?
> >
> > cheers,
> > Matthias
> >
> > On Thu, Jan 21, 2021 at 4:29 AM Aaron Meurer  wrote:
> > >
> > > On Wed, Jan 20, 2021 at 3:49 PM gu...@uwosh.edu  
> wrote:
> > > >
> > > > First, Oscar thank you for taking the time to summarize for everyone 
> the key issues we are trying to make decisions on.
> > > >
> > > > Second, I think I can help people understand a little more about why 
> these are issues.
> > > >
> > > > Most of them arise because in code we make a distinction between a 
> function and a symbol. As a physical scientist I routinely work with 
> equations where all the symbols can be thought of as functions of all the 
> other symbols. Consider the ideal gas law: P = nRT/V, where P = pressure, n 
> = moles, R = gas constant, T = absolute temperature and V = volume. You can 
> solve this equation for any of the symbols. In the form it is written it 
> makes perfect sense to say dP/dT = nR/V. If I had solved for V => dV/dT 

Re: [sympy] We need some community input on the desired behavior of an equation class...

[Aaron Meurer]

On Thu, Feb 4, 2021 at 2:18 PM Matthias Geier  wrote:
>
> Hi all.
>
> First of all, thanks for all the effort all of you are putting into
> SymPy in general and into the upcoming Equation class specifically!
>
> I'm not sure whether I fully understand either side of the contentious
> questions mentioned in this thread, but let me nevertheless add my
> opinion:
>
> I think what Jonathan describes is a mixture of two things:
>
> * an "equation" where operations can be applied on both sides
> * a "definition" or "assignment" where an expression (on the right
> side) gets a new name (on the left side)
>
> I'm quite sure that those should be two separate classes, but I'm not
> sure whether *both* should be part of SymPy.
>
> I think the "Equation" class should never treat the two sides
> differently (unless explicitly requested by "rhs" or "lhs" stuff, and
> probably as argument to subs()?).

I agree with this.

Incidentally, there is an Assignment class in SymPy, in the codegen
module. It is designed specifically around generating code, so it
might not apply to the use cases here.

Aaron Meurer

>
> However, I can very much appreciate the desire to have a symbol that
> represents an expression, where both are displayed nicely with an
> equals sign in between.
>
> FWIW, I've somewhat recently created an ad-hoc class called
> "NamedExpression" that does some of what Jonathan describes.
>
> It's defined there:
> https://github.com/AudioSceneDescriptionFormat/splines/blob/master/doc/euclidean/utility.py
>
> And there's an example using it:
> https://splines.readthedocs.io/en/latest/euclidean/hermite-uniform.html
>
> Apart from derivatives, there is also .evaluate_at() which treats the
> two sides of the equation differently.
>
> On top of that, I've also made a "NamedMatrix" class with a few
> additional features specific to matrices.
> For example it allows to invert and transpose both sides (which is
> also shown in the example mentioned above).
>
> As a special feature it has also a .pull_out() method, which allows to
> pull a common factor out of all matrix coefficients.
>
> I'm not suggesting to implement any of this in SymPy, probably it is
> much too specific and uses some assumptions that are not appropriate
> for general use.
>
> Probably something like this could become a separate Python module
> (targeted at teaching) using building blocks from SymPy (like the
> upcoming Equation class)?
>
> cheers,
> Matthias
>
> On Thu, Jan 21, 2021 at 4:29 AM Aaron Meurer  wrote:
> >
> > On Wed, Jan 20, 2021 at 3:49 PM gu...@uwosh.edu  wrote:
> > >
> > > First, Oscar thank you for taking the time to summarize for everyone the 
> > > key issues we are trying to make decisions on.
> > >
> > > Second, I think I can help people understand a little more about why 
> > > these are issues.
> > >
> > > Most of them arise because in code we make a distinction between a 
> > > function and a symbol. As a physical scientist I routinely work with 
> > > equations where all the symbols can be thought of as functions of all the 
> > > other symbols. Consider the ideal gas law: P = nRT/V, where P = pressure, 
> > > n = moles, R = gas constant, T = absolute temperature and V = volume. You 
> > > can solve this equation for any of the symbols. In the form it is written 
> > > it makes perfect sense to say dP/dT = nR/V. If I had solved for V => 
> > > dV/dT = nR/P. Measurements in the laboratory show that both relationships 
> > > are true. Thus the following does not make sense for this simple example:
> > > >>>diff(P=n*R*T/V,T)
> > > 0 = n*R/V
> > > n*R/V is generally not equal to zero (only two cases: n = 0 and V = oo; 
> > > both physically not very important).
> > >
> > > Because of the way SymPy presently treats functions, getting the behavior 
> > > that I would expect as a scientists for an equation such as the ideal gas 
> > > law cannot be achieved by using functions instead of symbols.
> >
> > This starts to get into the question of what the semantic meaning of
> > Eqn is. Should Derivative treat the variables in Eqn as depending on
> > each other, because the equality implies they do? What about Eqn(f(x),
> > a*x)? Does the presence of f(x) prevent a from depending on x? You
> > could also write Eqn(a, f(x)/x). The first one "looks" like a doesn't
> > depend on x and the second one "looks" like it does. But shouldn't the
> > two Eqns be treated in the same way, since one can be obtained from
> > the other by a simple, reversible transformation?
> >
> > My feeling on this is that Derivative already solves this problem by
> > implicitly assuming that variables are independent of one another,
> > unless explicitly stated otherwise via a functional relationship. I
> > don't think Eqn should change this behavior. As an aside, it may be
> > useful, independently of Eqn, to have a function that can take
> > derivatives under the assumption that certain symbols depend on one
> > another, as a convenience over creating explicit 

Re: [sympy] We need some community input on the desired behavior of an equation class...

[Matthias Geier]

Hi all.

First of all, thanks for all the effort all of you are putting into
SymPy in general and into the upcoming Equation class specifically!

I'm not sure whether I fully understand either side of the contentious
questions mentioned in this thread, but let me nevertheless add my
opinion:

I think what Jonathan describes is a mixture of two things:

* an "equation" where operations can be applied on both sides
* a "definition" or "assignment" where an expression (on the right
side) gets a new name (on the left side)

I'm quite sure that those should be two separate classes, but I'm not
sure whether *both* should be part of SymPy.

I think the "Equation" class should never treat the two sides
differently (unless explicitly requested by "rhs" or "lhs" stuff, and
probably as argument to subs()?).

However, I can very much appreciate the desire to have a symbol that
represents an expression, where both are displayed nicely with an
equals sign in between.

FWIW, I've somewhat recently created an ad-hoc class called
"NamedExpression" that does some of what Jonathan describes.

It's defined there:
https://github.com/AudioSceneDescriptionFormat/splines/blob/master/doc/euclidean/utility.py

And there's an example using it:
https://splines.readthedocs.io/en/latest/euclidean/hermite-uniform.html

Apart from derivatives, there is also .evaluate_at() which treats the
two sides of the equation differently.

On top of that, I've also made a "NamedMatrix" class with a few
additional features specific to matrices.
For example it allows to invert and transpose both sides (which is
also shown in the example mentioned above).

As a special feature it has also a .pull_out() method, which allows to
pull a common factor out of all matrix coefficients.

I'm not suggesting to implement any of this in SymPy, probably it is
much too specific and uses some assumptions that are not appropriate
for general use.

Probably something like this could become a separate Python module
(targeted at teaching) using building blocks from SymPy (like the
upcoming Equation class)?

cheers,
Matthias

On Thu, Jan 21, 2021 at 4:29 AM Aaron Meurer  wrote:
>
> On Wed, Jan 20, 2021 at 3:49 PM gu...@uwosh.edu  wrote:
> >
> > First, Oscar thank you for taking the time to summarize for everyone the 
> > key issues we are trying to make decisions on.
> >
> > Second, I think I can help people understand a little more about why these 
> > are issues.
> >
> > Most of them arise because in code we make a distinction between a function 
> > and a symbol. As a physical scientist I routinely work with equations where 
> > all the symbols can be thought of as functions of all the other symbols. 
> > Consider the ideal gas law: P = nRT/V, where P = pressure, n = moles, R = 
> > gas constant, T = absolute temperature and V = volume. You can solve this 
> > equation for any of the symbols. In the form it is written it makes perfect 
> > sense to say dP/dT = nR/V. If I had solved for V => dV/dT = nR/P. 
> > Measurements in the laboratory show that both relationships are true. Thus 
> > the following does not make sense for this simple example:
> > >>>diff(P=n*R*T/V,T)
> > 0 = n*R/V
> > n*R/V is generally not equal to zero (only two cases: n = 0 and V = oo; 
> > both physically not very important).
> >
> > Because of the way SymPy presently treats functions, getting the behavior 
> > that I would expect as a scientists for an equation such as the ideal gas 
> > law cannot be achieved by using functions instead of symbols.
>
> This starts to get into the question of what the semantic meaning of
> Eqn is. Should Derivative treat the variables in Eqn as depending on
> each other, because the equality implies they do? What about Eqn(f(x),
> a*x)? Does the presence of f(x) prevent a from depending on x? You
> could also write Eqn(a, f(x)/x). The first one "looks" like a doesn't
> depend on x and the second one "looks" like it does. But shouldn't the
> two Eqns be treated in the same way, since one can be obtained from
> the other by a simple, reversible transformation?
>
> My feeling on this is that Derivative already solves this problem by
> implicitly assuming that variables are independent of one another,
> unless explicitly stated otherwise via a functional relationship. I
> don't think Eqn should change this behavior. As an aside, it may be
> useful, independently of Eqn, to have a function that can take
> derivatives under the assumption that certain symbols depend on one
> another, as a convenience over creating explicit Function objects
> (idiff() is an example of this sort of thing).
>
> But the underlying question about the semantic meaning is, to what
> degree does Eqn represent an "equality", vs. just being a convenient
> way to manipulate two expressions in tandem. This question also comes
> up with some of my suggestions about manipulating an Eqn in my
> previous post. I think an Eqn *is* more than just a pair of
> expressions. But we should think about a 

[sympy]

[Mhd Ali]

How do I know for sure an issue is open?, I looked at some issues and it
shows that the issue is open but when I check the chat I see that it's been
closed

-- 
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/CANV73fELyqhtM6tzfm%2BC0c0sss%2BxmV6RiYqiNdSq%3D8UbgraM0w%40mail.gmail.com.

[sympy] New guy

[Mhd Ali]

Hello everyone, I am new to sympy, was going through the docs and I saw a 
lot of maths, can someone please tell me the basic math principles I need 
to know before I can be comfortable contributing to the project

-- 
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/b96a5937-dfe1-4544-a7cd-5b616dd9228fn%40googlegroups.com.

Re: [sympy] Unable to see my message

[Oscar Benjamin]

On Thu, 4 Feb 2021 at 18:48, mayank gaur  wrote:
>
> Now I have posted several times, so now I will not be moderated right?

When a message is in moderation the person who allows the message
through needs to tick a box to say "let this message through *and* all
future messages from the same sender". Probably someone forgot to tick
the extra box the first time you posted. Your messages now will not be
moderated.

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/CAHVvXxTP-PFykWk%3Dme_UTpV1B8NXKwvcafvSmAHmBG2rxRHQ%2BQ%40mail.gmail.com.

Re: [sympy] Unable to see my message

[mayank gaur]

Now I have posted several times, so now I will not be moderated right?
On Thursday, February 4, 2021 at 1:44:28 AM UTC+5:30 asme...@gmail.com 
wrote:

> I see several messages from you from January 3, as well as one today
> ("call for work"). Is that the message in question, or is it another
> one?
>
> Note that the mailing list is moderated so first time posts will take
> a little bit to show up, but once you have been moderated once, your
> messages should appear immediately.
>
> Aaron Meurer
>
> On Wed, Feb 3, 2021 at 8:04 AM mayank gaur  wrote:
> >
> > It has been 2 days and my message is still not available in the group. 
> Moderation is for the first time messages only and I have 2-3 messages in 
> the past. Can you please tell me why my messages are not visible?
> >
> > --
> > You received this message because you are subscribed to the Google 
> Groups "sympy" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to sympy+un...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sympy/448c4bee-8b58-4735-aec9-8fbe155bb64an%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/b99ffba6-2fe4-469e-a7e7-9a9e977fd515n%40googlegroups.com.

[sympy] Introduction for participation in GSOC 2021 as a contributor

['Supreet Singh 5-Year IDD Computer Science and Engineering' via sympy]

Hey Everyone, 

My name is* Supreet Singh* and currently I'm in second-year , pursuing 
Computer Science and Engineering from Indian Institute of Technology BHU 
Varanasi

   - I have been coding with python as my primary language for the last 2 
   years .
   - I am new to sympy and i am interested in contributing in open source 
   community. 
   - I have taken courses on discrete mathematics, probability and 
   statistics , Mathematics - I and II (vector calculus, numerical methods, 
   linear algebra, ODE's, complex analysis, improper integrals, fourier and 
   laplace transformation) , physics( kinematics, Quantum mechanics ) , 
   data structure and algorithm. 
   - I am good with * Django,* *numpy* , *pandas* ,  *matplotlib** .*
   - Along with python , I also have  good knowledge of*  C , C++,  java , 
   HTML, CSS , Java-Script , git *. 
   - I also have engineering level familiarity with symbolic maths systems.

 
I am interested in participating in GSoC 2021 for sympy and would love to 
contribute and work on the projects.

Thank you

-- 
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/88cc328c-9810-46f1-a33c-d59f869998c6n%40googlegroups.com.