[sympy] Eigenvalues of a matrix with symbolic coefficients

[Oscar Benjamin]

I'm having some problems getting sympy to compute eigenvalues of a
matrix with symbolic coefficients.

A trivial example is:

In [4]: M = Matrix([[y, 0], [0, z]])

In [5]: M
Out[5]:
⎡y  0⎤
⎢⎥
⎣0  z⎦

In [6]: M.eigenvals()
Out[6]:
⎧   ____   ⎫
⎪  ╱2╱2⎪
⎨y   z   ╲╱  (y - z)   y   z   ╲╱  (y - z) ⎬
⎪─ + ─ - ─: 1, ─ + ─ + ─: 1⎪
⎩2   2 2   2   2 2 ⎭

Clearly the eigenvalues should be y and z so something has gone wrong.

It seems that perhaps what happens is that the characteristic
polynomial is expanded and then not re-factored when finding
solutions:

In [7]: (M - x*eye(2))
Out[7]:
⎡-x + y0   ⎤
⎢  ⎥
⎣  0 -x + z⎦

In [8]: (M - x*eye(2)).det()
Out[8]:
 2
x  - x⋅y - x⋅z + y⋅z

In [9]: solve((M - x*eye(2)).det(), x)
Out[9]:
⎡   __ __⎤
⎢  ╱2 ╱2 ⎥
⎢y   z   ╲╱  (y - z)y   z   ╲╱  (y - z)  ⎥
⎢─ + ─ - ─, ─ + ─ + ─⎥
⎣2   2 22   2 2  ⎦

In [10]: factor((M - x*eye(2)).det())
Out[10]: (x - y)⋅(x - z)

In [11]: solve(factor((M - x*eye(2)).det()), x)
Out[11]: [y, z]

Presumably det calls expand and I'm not sure why it would want to do
that. Also solve has clearly spotted that this is a second order
polynomial since we're using the quadratic formula but no attempt at
factorisation is made. I guess that without knowing knowing the sign
of y - z you can't know whether sqrt((y-z)**2) is y - z or z - y so
the quadratic formula cannot be simplified even though the original
polynomial could.

Is there some way to adjust this behaviour with flags etc.? Or is it
just a case where sympy has some room for improvement?

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 http://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAHVvXxQqEwSOnm0rR3qnfpKBEorgdcMYgVFSjjYL3Rc%2B5K4YeQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Eigenvalues of a matrix with symbolic coefficients

[Oscar Benjamin]

On 4 December 2014 at 17:44, Colin Macdonald macdon...@maths.ox.ac.uk wrote:
 In [4]: M = Matrix([[y, 0], [0, z]])

 In [5]: M
 Out[5]:
 ⎡y  0⎤
 ⎢⎥
 ⎣0  z⎦

 In [6]: M.eigenvals()
 Out[6]:
 ⎧   ____   ⎫
 ⎪  ╱2╱2⎪
 ⎨y   z   ╲╱  (y - z)   y   z   ╲╱  (y - z) ⎬
 ⎪─ + ─ - ─: 1, ─ + ─ + ─: 1⎪
 ⎩2   2 2   2   2 2 ⎭

 I think this has been improved in the dev version after 0.7.6.  I
 remember commenting on an old issue on this which was then recently
 closed, but I cannot locate at the moment...  test on git master?

Yes, you're right. git master shows:

In [3]: Matrix([[y, 0], [0, z]]).eigenvals()
Out[3]: {y: 1, z: 1}

And also:

In [8]: (M - x*eye(2)).det()
Out[8]:
 2
x  - x⋅y - x⋅z + y⋅z

In [9]: solve((M - x*eye(2)).det(), x)
Out[9]: [y, z]

Thanks for that,
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 http://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAHVvXxQ3p4bkzy8rLETuy-3b6QkhxbYHW-71khcuWJdMr%2BAC9g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[sympy] Magnitude of a complex number

[Oscar Benjamin]

Am I misunderstanding something here (using master):

$ isympy
Couldn't locate IPython. Having IPython installed is greatly recommended.
...
 z = (4+3*I)/(3-4*I)
 z
4 + 3⋅ⅈ
───
3 - 4⋅ⅈ
 abs(z)
  │   1   │
5⋅│───│
  │3 - 4⋅ⅈ│
 simplify(abs(z))
  │   1   │
5⋅│───│
  │3 - 4⋅ⅈ│
 abs(z).evalf()
1.00
 abs(z) ** 2
2
   │   1   │
25⋅│───│
   │3 - 4⋅ⅈ│
 z * z.conjugate()
(4 - 3⋅ⅈ)⋅(4 + 3⋅ⅈ)
───
(3 - 4⋅ⅈ)⋅(3 + 4⋅ⅈ)
 simplify(z * z.conjugate())
1

Why doesn't abs(z) simplify (or should I open an issue)?


--
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 http://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAHVvXxS6DNZR8dPJ5AZ96V7MKtZQrvug_Pjs2%3DLejVOP6e73aw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] diff(x^x,x)

[Oscar Benjamin]

On 29 May 2015 22:06, Thomas Leitz unruhsc...@gmail.com wrote:

 Hi,

 the online shell at http://live.sympy.org/ tells me

 diff(x^x,x) = 0

 Why is that?

^ doesn't do what you're expecting in Python. Use ** for exponentiation.

--
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 http://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAHVvXxSNEU1dGr9zKOXRq1uFQYYEz10qHNku0JmzGmCqBhAq2w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Convert between numeral systems

[Oscar Benjamin]

On 3 July 2015 at 13:48, Robert Pollak robert.pol...@mykolab.com wrote:
 Hello,

 I have got a newbie question: Does SymPy provide a way to deal with numbers
 in different numeral systems and e.g. to convert them between different
 systems? Or do I have to tell my students that they have to program this by
 theirselves :) ?

Hi Robert,

I guess you mean converting from e.g. hex to decimal or something like
that? Or do you want to use more obscure systems like Roman numerals?

Python's int function can convert from any positional system in bases
2-36. Also Python has the bin, hex and oct functions which you may
find useful:

 int('ff', base=16)
255
 hex(255)
'0xff'
 bin(255)
'0b'
 oct(255)
'0o377'
 str(255)
'255'

There is no general inverse for int(str, base) provided so you would
have to implement that yourself but it could be a good exercise for
your students.

I don't personally know if sympy has anything to help you here.

--
Oscar

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAHVvXxSM4rNzRWU7mzKMSWijgEvr8Din0miqsH34LBpLGc59LA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Solution of small system of equations grows past manageability

[Oscar Benjamin]

On 11 June 2016 at 17:52,   wrote:
>
> Yes, exactly, its the linear bearings that can be at different locations and
> force therefore the board to different positions, those are the ones that i
> am interested in!

Rather than thinking about x, y and theta think about the three pin
positions. Give them position vectors r1, r2 and r3. Each is
constrained by a linear bearing and so e.g. r1 = a1 + t1*b1 where a1
and b1 are known vectors and t1 is the unknown line parameter. We have
then three unknown scalars t1, t2, and t3. Although we don't know r1,
r2, or r3 we do know their pairwise distances d12, d13 and d23. This
gives three equations e.g. |r1-r2|**2 = d12**2. Substitute for r1, r2
and r3 into those and we get 3 bivariate quadratic equations for t1,
t2, and t3. I would expect that sympy can solve that quickly for
numeric coefficients (if you can give numeric values for a1, b1, d12,
etc.).

In your example it's clear from symmetry that if phi is a solution
then so is phi+pi so you should expect to get multiple solutions here.
This method will also give upside down solutions that you may need to
prune. Presumably also you'll need to check the solutions for
consistency with the limits on the line bearings.

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

Re: [sympy] Solution of small system of equations grows past manageability

[Oscar Benjamin]

On 14 June 2016 at 20:30,   wrote:
> I had the same idea earlier, but i dropped it because my intuition was, that
> three quadratic equations are worse than three linear and one quadratic
> equation :-)
>
> Since you brought this approach up again, i tried it now, but sympy does not
> seem to find a solution.
>
> You can check out my code here: http://pastebin.com/famnqkLC
>
> You wrote you expected sympy to find a solution for numeric coefficients,
> but i need a symbolic solution because i want to proceed further (by
> differentiating with respect so some of the parameters for optimization),
> and don't want a sympy.solve step in each optimization step.

You should perhaps explain more clearly what you do want then. You
want  in terms of  but what are X and Y?

> Any idea why my original approach "explodes" in regards of the resulting
> expressions?

Given your three linear equations you can solve them to get x, y, and
cosphi all in terms of sinphi. Then you have that cosphi is:

(-(Cux*Cvy - Cuy*Cvx)*(Awx*Cvz*sinphi - Awy*Cuz*sinphi + Cwz) +
(Cux*Cvz - Cuz*Cvx)*(Avx*Cvy*sinphi - Avy*Cuy*sinphi + Cwy) - (Cuy*Cvz
- Cuz*Cvy)*(Aux*Cvx*sinphi - Auy*Cux*sinphi + Cwx))/(Cux*Cvy*(Awx*Cuz
+ Awy*Cvz) - Cux*Cvz*(Avx*Cuy + Avy*Cvy) - Cuy*Cvx*(Awx*Cuz + Awy*Cvz)
+ Cuy*Cvz*(Aux*Cux + Auy*Cvx) + Cuz*Cvx*(Avx*Cuy + Avy*Cvy) -
Cuz*Cvy*(Aux*Cux + Auy*Cvx))

Which you can substitute for cosphi in cosphi**2+sinphi**2-1 to get a
quadratic in only sinphi.

The explosion comes from expanding the cosphi expression (and then
squaring!). You have 12 different symbols (excluding sinphi) and all
the cross-multiplications gives a combinatoric explosion of terms that
aren't easy to factor.

I guess what you want to do is rearrange the cosphi expression into
the form a*sinphi + b but without expanding a and b.

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

Re: [sympy] Status of old/new assumptions systems

[Oscar Benjamin]

On 15 January 2016 at 15:06, Aaron Meurer  wrote:
>
> In the released version (0.7.6.1), the systems are independent. In
> master, the new assumptions (ask(), Q) read the old assumptions on
> Symbols (is_positive, positive=True).
>
> For performance purposes, this was done in a way that prevents the new
> assumptions from noticing contradictions (it was added to the old ask
> handler system instead of the new satask handler system). This will
> hopefully change in the future, but there are some performance issues
> that need to be worked out with the satask system.

Does this mean that there is a third (newer) assumption system?

> For now, I would recommend using the old assumptions. However, you can
> play with the new assumptions. The goal in making the new assumptions
> read the old was to make this easier to do.

But it also makes it a confusing mish-mash of the two. What's the
eventual goal here?

--
Oscar

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To 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/CAHVvXxTJhd5gGULjDJU1sjyrfTxS3WLOLWH-ubxN2MMuKtvuMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Definite Intergral wrong. How to solve

[Oscar Benjamin]

On 13 February 2016 at 07:48, Nasir Haniffa  wrote:
> Hi,
>
> How to get the correct answer for the problems
>
> 1.   Integral( (1+x**2)**(-3/2) ,(x,-1,1)  )
>
>
> 2.   Integral( (1+x**2+y**2)**(-3/2) ,(x,-1,1), (y,-1,1)  )
>
> Both gives 0 in sympy which is wrong.

This is a bug in current master:

>>> from sympy import Symbol, Integral
>>> x = Symbol('x')
>>> Integral( (1+x**2)**(-3/2) ,(x,-1,1)  )
Integral((x**2 + 1)**(-2), (x, -1, 1))
>>> Integral( (1+x**2)**(-3/2) ,(x,-1,1)  ).doit()
1/2 + pi/4

Note that -3/2 under Python 2.7 gives -2 which is not what you want so
use -S(3)/2

>>> from sympy import S
>>> Integral( (1+x**2)**(-S(3)/2) ,(x,-1,1)  ).doit()
0
>>> expr = (1+x**2)**(-S(3)/2)
>>> expr.integrate((x, -1, 1))
0

Under sympy 0.7.1 I get:

>>> Integral( (1+x**2)**(-S(3)/2) ,(x,-1,1)  ).doit()
Integral((x**2 + 1)**(-3/2), (x, -1, 1))
>>> Integral( (1+x**2)**(-S(3)/2) ,(x,-1,1)  ).evalf()
1.41421356237310

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

Re: [sympy] Bug in factor() and simplify()

[Oscar Benjamin]

On 25 February 2016 at 15:30, Oscar Benjamin <oscar.j.benja...@gmail.com> wrote:
> On 25 February 2016 at 10:44, Yingchi Li <liying...@gmail.com> wrote:
>>
>> I have found a bug in factor() and simplify()
>> please look at the image below
>>
>> the correct answer is q2 + 0.1
>
> Looks like a recent regression since I don't see it with 0.7.1 but I
> do with master:

I traced this to here:

In [1]: expr = x*sin(y)**2 + x*cos(y)**2 + 0.1*sin(y)**2 + 0.1*cos(y)**2

In [2]: p = Poly(expr, x, cos(y), sin(y), domain='RR')

In [3]: p
Out[3]: Poly(1.0*x*cos(y)**2 + 1.0*x*sin(y)**2 + 0.1*cos(y)**2 +
0.1*sin(y)**2, x, cos(y), sin(y), domain='RR')

In [4]: p.rep
Out[4]: DMP([[[1.0], [], [1.0, 0.0, 0.0]], [[0.1], [], [0.1, 0.0,
0.0]]], RR, None)

In [5]: p.rep.factor_list()
Out[5]:
(1.0,
 [(DMP([[[0.1], [], [0.1, 0.0, 0.0]]], RR, None), 1),
  (DMP([[[1.0]], [[0.1]]], RR, None), 1)])

I think the bug is in there somehow but I have no idea what it means.
What is p.rep and how do you interpret it?

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

Re: [sympy] Re: Help: simple univariate polynomial, sympy solve gives no results

[Oscar Benjamin]

On 20 January 2016 at 15:05, Denis Akhiyarov  wrote:
>
> Oscar, you need to click on "more roots" in wolfram alpha to see the
> algebraic solution, which is definitely confusing.

Unless I'm misreading all of the additional roots are for the case
where A=0. IOW Wolfram is saying "hey if by any chance A=0 then this
would be a quartic and I would know how to get the roots of that". My
interpretation then is that if A != 0 so that it's a true quintic then
Wolfram can't solve it.

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

Re: [sympy] Re: Help: simple univariate polynomial, sympy solve gives no results

[Oscar Benjamin]

On 20 January 2016 at 15:11, Aaron Meurer  wrote:
> SymPy has algorithms to find roots of quintics in radicals (when they
> exist). I don't recall if the algorithms work for symbolic inputs.
>
> One can take a general quintic (x**5 + a*x**4 + b*x**3 + c*x**2 + d*x + e)
> and shift it by y (replace x with x - y). Then expand and collect terms in
> x. The coefficient of x**3 is a quadratic in y.  Hence, one can solve a
> quadratic in y in radicals terms of a and b, and shift the quintic by that.
> One then has a new quintic, with no cubic term, with the same roots shifted
> by some term which is expressible in radicals. Hence, the general quintic
> with no cubic term is not solvable in radicals, as a solution would give a
> solution to the general quintic (shift it back by the radical expression
> above, which would keep it in radicals).

The above argument extends to making any of the coefficients zero with
the exception of the constant coefficient e. If we could shift to x -
t so that we have a new polynomial with zero constant term then x = t
would be a root of the original polynomial which would imply being
able to find one root of (and hence all roots of) any quintic.
Otherwise though we can shift to make any of a, b, c or d zero.

However the OP asked about a less general case where the cubic and
quadratic coefficients are both zero. It's not possible in general to
shift a quintic so that both b and c are zero.

> Here is some SymPy code:
>
> a, b, c, d, e, x, y = symbols('a b c d e x y')
> q = x**5 + a*x**4 + b*x**3 + c*x**2 + d*x + e
> print(collect(q.subs(x, x - y).expand(), x, evaluate=False)[x**3])
> t = solve(collect(q.subs(x, x - y).expand(), x, evaluate=False)[x**3], y)[0]
> print(t)
> print(collect(q.subs(x, x - t).expand(), x, evaluate=False).get(x**3))

To make b and c zero we'd need to solve these two equations
simultaneously for one variable y:

In [5]: print(collect(q.subs(x, x - y).expand(), x, evaluate=False)[x**2])
6*a*y**2 - 3*b*y + c - 10*y**3

In [6]: print(collect(q.subs(x, x - y).expand(), x, evaluate=False)[x**3])
-4*a*y + b + 10*y**2

Clearly that will only work for some lucky values of a, b, and c. (One
that jumps out is the trivial solution that we could have y=0 if b and
c are both 0.)

So this is not a general quintic but neither sympy nor Wolfram can
solve it. I was wondering if it is possible to specifically verify
that it has an unsolvable Galois group but perhaps not.

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

Re: [sympy] Status of old/new assumptions systems

[Oscar Benjamin]

On 18 January 2016 at 20:47, Aaron Meurer  wrote:
>>> For now, I would recommend using the old assumptions. However, you can
>>> play with the new assumptions. The goal in making the new assumptions
>>> read the old was to make this easier to do.
>>
>> But it also makes it a confusing mish-mash of the two. What's the
>> eventual goal here?
>
> The eventual goal is to merge the two, so that one calls the other.
> Then it won't matter which one you use. It will just be a question of
> which syntax you prefer. For now, we have that in one direction (the
> new system calls the old).

Okay I get it now. So the plan is not really to have two systems or to
deprecate one but just to have two APIs for using assumptions. The
name "old assumptions" lead me to assume that when the new system was
ready the previous would be deprecated and removed.

I do prefer the the new assumptions API so I would consider it an
improvement when it's ready. Of course there will be some cases where
you need to attach assumptions to objects because of
auto-simplification. There was a recent thread about using
commutative=False to prevent (a*b)/(a*c) from automatically
cancelling. I guess there's no new-style way to do that?

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

Re: [sympy] Re: Help: simple univariate polynomial, sympy solve gives no results

[Oscar Benjamin]

On 20 January 2016 at 05:46, Denis Akhiyarov  wrote:
> On Tuesday, January 19, 2016 at 11:41:47 PM UTC-6, Denis Akhiyarov wrote:
>>
>> no algebraic roots according to this theorem:
>> https://en.wikipedia.org/wiki/Abel%E2%80%93Ruffini_theorem

The theorem only shows that a general algebraic solution for *all*
quintics (or higher degree polynomials) is not possible. In this case
it is not a fully general quintic since the coefficients of x^3 and
x^2 are both zero. I'm not sure how to check based on the coefficients
of a polynomial whether or not its Galois group is solvable. Can sympy
do that?

To the OP: do you need to solve this in terms of symbols A, B etc. or
is it acceptable to solve it using particular numbers for the
coefficients? You may have better luck using the actual numbers.

> actually this case looks like has some special properties and hence has some
> roots according to Wolfram:
>
> http://www.wolframalpha.com/input/?i=A*x%5E5%2BB*x%5E4%2BC*x-D%3D0

My interpretation of that Wolfram output is that Wolfram is unable to
solve this quintic (or rather this general family of quintics).

--
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/CAHVvXxSwgubqczYcavJ%2BBQVah0aR05dda-0fS4VPubBTajHizw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] integration with the square root of a non-negative expressions

[Oscar Benjamin]

On 14 February 2016 at 15:17, Andrew Corrigan  wrote:
> I'm having trouble computing a definite integral involving the sqrt of a
> non-negative expression, as implemented below (computing the length of a
> quadratic line in 2D).  It seems to fail.  I've generally had success using
> sympy for integration, except for when a sqrt is present.
>
> If anyone has any advice on how to make this work, I would appreciate it
> tremendously.  Thanks in advance!
>
> from sympy import *
> x0,x1,x2,y0,y1,y2,xi = symbols('x0 x1 x2 y0 y1 y2 xi', real=True)
> f_squared = (-4*x0*xi + 3*x0 - 4*x1*xi + x1 + 8*x2*xi - 4*x2)**2 + (4*xi*y0
> + 4*xi*y1 - 8*xi*y2 - 3*y0 - y1 + 4*y2)**2
> f = sqrt(f_squared)
> integrate(f, (xi,0,1))

Distilling this down you want to compute the integral of the square
root of a quadratic. Sympy can do this in some simple cases:

>>> sqrt(1 + x**2).integrate(x)
 
╱  2
x⋅╲╱  x  + 1asinh(x)
─ + 
  22

However it fails for slightly more complicated cases:

>>> sqrt(1 + x + x**2).integrate(x)
⌠
⎮
⎮   ╱  2
⎮ ╲╱  x  + x + 1  dx
⌡

This second form can always be reduced to the first by completing the
square and changing variables. It seems that sympy is currently unable
to do that 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 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/CAHVvXxS5ys%2Bkfmz1-ZM3ekadA-gwwQ9e%2BDSGd1P4oXAkcKFn%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] integration with the square root of a non-negative expressions

[Oscar Benjamin]

On 15 February 2016 at 15:01, Andrew Corrigan  wrote:
> Thank you both for your replies.  I'm not sure I follow the discussion to be
> honest as to how it applies to my original problem.  In particular:
>>>
>>> Distilling this down you want to compute the integral of the square
>>> root of a quadratic
>
> I'm not sure that is accurate.

It is for the example you showed :).

>  If you are just referring to that it is
> (foo(xi))**2  + (bar(xi))**2, then yes the expression is quadratic in foo
> and bar.  But in general, foo(xi) and bar(xi) are themselves higher degree
> polynomials of xi (and in higher dimensions other coordinates too).  This is
> a very simple and minimal reproducing example: in this case foo and bar are
> linear polynomials so the whole expression is quadratic.

The example is not minimal. Much of your expression is a red herring
with symbols that are unimportant to people reading on this list. A
minimal example would be something like:

sqrt(ax^2 + bx + c)

> I have expressions
> I need to integrate, where foo(xi) and bar(xi) are higher-order polynomials
> terms of xi.

If you want to do sqrt(P(x)) with P(x) polynomial of degree k then I
think you can have general solutions for k=1,2,3 and 4 (assuming P(x)
has no repeated roots). Sympy can do k=1 and should be able to do 2
with a bit of help. For 3 and 4 you want the elliptic integrals
although maybe sympy doesn't do them yet.

For k>4 there may be solutions for certain special cases of the
polynomial coefficients. In general for a polynomial with symbolic
coefficients I don't think that there exist well-known mathematical
functions to represent the results.

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

Re: [sympy] Simplifying trigonometric expression

[Oscar Benjamin]

On 18 February 2016 at 09:43, Paul Royik  wrote:
> I'm trying to simplify a*cos(b)**2+a*sin(b)**2 to a
>
> So, I write
>
> a = sympy.Wild('a')
> b = sympy.Wild('b')
> expr = 49*cos(x)**2+49*sin(x)**2 + 5
> expr.replace(a*sympy.sin(b)**2+a*sympy.cos(b)**2, a, exact=True)
>
>
> But this doesn't work. expr is unchanged.

How about:

>>> x = Symbol('x')
>>> trigsimp(49*cos(x)**2 + 49*sin(x)**2 + 5)
54

Or is your question about the fact that expr.replace does not modify
expr but rather returns a different expression? Maybe you wanted
something like:

 expr = expr.replace(...)

--
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/CAHVvXxSuE%2B3WkgOzSiALSwVcHEi%2B1tYvnypmZrq-DWdf2BsDkw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Sympy vs Numpy, better accuracy in precision?

[Oscar Benjamin]

On 5 April 2016 at 18:21, Isuru Fernando  wrote:
>
> I think the current way of representing Floats is reasonable.
>
> Float internally keeps it in binary representation, so any non-terminating
> number in base 2 is truncated when stored as a Float. That's why there is a
> string constructor which can take in an exact decimal value and create a
> number in binary representation with precision mentioned.
>
> Note that in this way only numbers representable as a sum of different
> powers of two have an exact value. Others can also be represented in an
> exact form if the base of the float is different than 2, but I think mpmath
> and many other libraries use only base 2.

Some do and some use decimal. The advantage of decimal is being able
to exactly represent numbers input as decimal. Maybe the key here is
not to have Float automatically turn into an mpf in the first place if
it can't be done losslessly. Maybe a Float can remember the exact
input it was given e.g. "1.4142" and not try to turn that into a
binary representation until the precision is specified later.

> If you want an exact form, best way would be to define it as a Rational and
> then you can do 1/3 as well which you can't if it's in decimal form. One
> other good thing about Rational is that `sin(Rational)` won't be evaluated
> unless SymPy knows the exact value, whereas `sin(Float)` would evaluate
> leading to error propagation even if it's something like `0.5` which
> represented exactly in binary representation.

Exactly sin(Rational) won't be auto-evaluated because it's not clear
how many digits to use until someone later calls .evalf(). I think it
should be the same for sin(Float). It shouldn't really matter whether
the user does S("0.1") or S("1/10").

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

Re: [sympy] Sympy vs Numpy, better accuracy in precision?

[Oscar Benjamin]

On 5 April 2016 at 18:08, Aaron Meurer <asmeu...@gmail.com> wrote:
> On Tue, Apr 5, 2016 at 12:54 PM, Oscar Benjamin
> <oscar.j.benja...@gmail.com> wrote:
>>
>>>
>>> I don't know if it should be considered a bug, but it's worth noting
>>> that if you want SymPy to give the right precision in general you have
>>> to start with Float objects that are set with the precision you need.
>>> To me it feels like a bug because it negates the purpose of the evalf
>>> precision argument.
>>
>> Is there a coherent policy on float-handling in sympy?
>>
>> My ideal would be:
>>
>> 1) All float objects are created exact (having the exact value of the
>> object passed in).
>> 2) No inexact auto-evaluation.
>> 3) .evalf() can be used to fully evaluate the expression with desired 
>> precision.
>> 4) Ideally the precision argument to .evalf would be the precision of
>> the *output* rather than the internal precision of the intermediate
>> calculations
>
> Can you clarify what you mean by "exact" here?
>
> Note that there's no way to know what the input value of a float is.
> That is, there's no way to write Float(0.2) (with no quotes) and have
> it be treated as Float(2/10).  The 0.2 object is converted to a Python
> floating point by the time that Float sees it, and it's not a decimal:
>
> In [49]: (0.2).as_integer_ratio()
> Out[49]: (3602879701896397, 18014398509481984)

Passing a Python float into a sympy expression (I know I accidentally
did it earlier in the thread) is usually not going to do what is
wanted e.g. 0.1*x creates a number not truly equal to 0.1 and passes
it to x.__rmul__. The good fix for this is as you say to use a string.
However there are times when it would be good to pass in a float that
you have obtained from some other calculation and have sympy work with
it.

Currently Sympy will round an input float to 15d.p. and as a result
S(0.1) will result in an mpf which really does have a true value of
0.1. This is useful for novices but IMO just hides the binary float
problem a bit. The right solution is for users to understand that they
should be using S("0.1") or something.

If OTOH I received my float from some other source (rather than trying
to make a simple number like 0.1) then sympy is rounding the number
rather than taking it in exactly. I would prefer it in this case if
sympy would retain the exact value of the input number the same way
that Fraction and Decimal do:

In [19]: from fractions import Fraction

In [20]: Fraction(0.1)
Out[20]: Fraction(3602879701896397, 36028797018963968)

In [21]: from decimal import Decimal

In [22]: Decimal(0.1)
Out[22]:

Decimal('0.155511151231257827021181583404541015625')
In [23]: from sympy import Float

In [24]: Float(0.1)
Out[24]: 0.100

Both Fraction and Decimal always retain the exact input value. If you
want to round it then you need to do that explicitly. This is useful
because once you're numbers are converted to say Decimal then you can
use the calculation contexts to control exactly how the rounding
occurs (or to prevent any rounding) etc. If the rounding occurs
straight away at input then you cannot.

> That's why Float allows string input (and it's the recommended way of
> creating them).
>
> With that being said, I don't think the fact that
> (1.4142).as_integer_ratio() isn't (7071, 5000) is the problem here.
> Float(1.4142) is indeed inexact compared to Float('1.4142'), but the
> wrong answers from x**6000%400 come from lack of computing precision,
> not lack of input accuracy.

It is a separate but related issue to this. In this particular case
S(1.4142) does what a user may be intending it to do and creates
mpf("1.4142") so the issue occurs later.

>> Currently 1) already occurs for decimal strings but Float(float)
>> rounds to 15 digits and you can explicitly force something impossible
>> as a ratio string: Float("1/3"). I think Float should be more like
>> decimal.Decimal here: all input arguments are treated as exact
>> regardless of precision etc. (and I don't see any good reason for
>> allowing Float("1/3"))
>>
>> Without 2) it is impossible to achieve 3). If approximate
>> auto-evaluation can occur before calling .evalf then there's no way
>> for evalf to set the precision to be used for the auto-evaluation.
>>
>> Obviously 4) is harder than current behaviour and perhaps impossible
>> in general but it is achievable for simple cases like in this thread.
>> From a user perspective it is definitely what is actually wanted and
>> much easier to understand.
>
> I'm unclear how this works, because if you take my example above with
> x = nsimplify("1.4142"

Re: [sympy] Re: Pretty print expressions

[Oscar Benjamin]

On 7 April 2016 at 13:50, Luv Agarwal  wrote:
> Also, is this the right place to ask questions?

It is although I don't know the answer to your question. Be patient...

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

Re: [sympy] Sympy vs Numpy, better accuracy in precision?

[Oscar Benjamin]

On 5 April 2016 at 17:15, Aaron Meurer <asmeu...@gmail.com> wrote:
> On Tue, Apr 5, 2016 at 6:19 AM, Oscar Benjamin
> <oscar.j.benja...@gmail.com> wrote:
>>
>> I though that it should be possible to easily do this with sympy
>> Floats but it doesn't seem to work:
>>
>> In [1]: x = S(1.4142)
>>
>> In [2]: x
>> Out[2]: 1.414200
>>
>> In [3]: x**6000
>> Out[3]: 1.16144178843571e+903
>>
>> In [4]: x**6000 % 400
>> Out[4]: 32.0
>>
>> This doesn't work because auto-evaluation of x**6000 destroyed all the
>> precision so I tried:
>
> No, it's because the default precision is 15. I didn't realize you
> needed a precision of 950. If you do what I did above with that you
> get the right answer
>
> In [6]: x = Float("1.4142", 950)
...

It is because of the auto-evaluation in the sense that there were
enough digits to exactly represent all the input numbers but the
auto-evaluation cheated me from specifying how many digits to use for
the exponentiation with evalf later. I think that inexact
auto-evaluation should be disabled by default. Explicitly calling
.evalf() serves as a useful reminder of the numeric approximations
that have occurred in the calculation and should be required for this.

>> So let's disable evaluation of at the mod step as well:
>>
>> In [10]: Mod(Pow(x, 6000, evaluate=False), 400, evaluate=False).evalf(50)
>> Out[10]:
>>⎛  6000 ⎞
>> Mod⎝1.4142, 400⎠
>>
>> How do I get that to actually evaluate?
>
> expr.doit() will evaluate the expression, but it evaluates it using
> the prevision of x. For your x, that's 15, so you get the wrong answer
> 32. If you set x = Float("1.4142", 950) you get the right answer.

Is there a reason for not evaluating this when evalf is called?

...
>
> I don't know if it should be considered a bug, but it's worth noting
> that if you want SymPy to give the right precision in general you have
> to start with Float objects that are set with the precision you need.
> To me it feels like a bug because it negates the purpose of the evalf
> precision argument.

Is there a coherent policy on float-handling in sympy?

My ideal would be:

1) All float objects are created exact (having the exact value of the
object passed in).
2) No inexact auto-evaluation.
3) .evalf() can be used to fully evaluate the expression with desired precision.
4) Ideally the precision argument to .evalf would be the precision of
the *output* rather than the internal precision of the intermediate
calculations

Currently 1) already occurs for decimal strings but Float(float)
rounds to 15 digits and you can explicitly force something impossible
as a ratio string: Float("1/3"). I think Float should be more like
decimal.Decimal here: all input arguments are treated as exact
regardless of precision etc. (and I don't see any good reason for
allowing Float("1/3"))

Without 2) it is impossible to achieve 3). If approximate
auto-evaluation can occur before calling .evalf then there's no way
for evalf to set the precision to be used for the auto-evaluation.

Obviously 4) is harder than current behaviour and perhaps impossible
in general but it is achievable for simple cases like in this thread.
>From a user perspective it is definitely what is actually wanted and
much easier to understand.

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

Re: [sympy] Arbitrary Precision Problem Persists

[Oscar Benjamin]

On 9 April 2016 at 19:56, Amy Valhausen  wrote:
> In the thread ; https://groups.google.com/forum/#!topic/sympy/eUfW6C_nHdI
>
> I was seeking feedback and help with the problem of type ;
>
> ( 1.414213562^6000) % 400)
>
> After reviewing all the excellent collaboration at the above link, Im
> feeling
> a little lost and overwhelmed.  So many good suggestions were made and
> also a lot of bugs, and bottlenecks discovered - Im not sure which approach
> is best for what I am hoping to solve?

Yes the thread did bring up a few issues and there were some bugs. I
think the reason for those bugs is that sympy's Float algebra is less
well used and tested than its other features. Modulo division with
floats for example seems an unusual usuage to me. That's because for a
problem like the one you have posed it's usually best not to use
float.

> Ive been reviewing the problems with the different approaches, including
> precision loss
> with use of floats, some of the suggested functions, etc.

The short answer is to just use rational numbers unless you can't for
some reason. So if 1.4142 is supposed to be an exact rational number
then:

Rational("1.4142")**6000 % 400

This will give you the exact answer is a rational number.
Unfortunately the rational number has a really big numerator and
denominator (print it to see) so this isn't necessarily a useful form
for viewing the output. To see the first say 50 decimal digits just
use evalf():

>>> ((Rational("1.4142")**6000) % 400).evalf(50)
271.04818100863092181593910948838929251832458036415

> Oscar mentioned the solution of using a string value and storing it as a
> possibility?

That was a suggestion for how the implementation of sympy could
change. I wasn't suggesting that to you to use. For your problem you
can pass the decimal string to Rational. But as already pointed out in
this thread it must be Rational("1.4142") and not Rational(1.4142).

> My hope is to arrive at a method that returns lossless precision, if I dont
> have to sacrifice speed then
> thats great but if preserving accuracy comes at a cost of speed thats ok
> with me.
>
> I'd like also to get the highest precision available, if possible past the
> 15 digit limit, the larger the better.

So see above. You can compute the result exactly as a rational number
(effectively having infinite precision). However this isn't always a
useful form so you can also evaluate it with evalf and ask for as many
digits as you desire. The exact answer can be written in decimal but
it needs 24003 digits so you can print it with:

>>> ((Rational("1.4142")**6000) % 400).evalf(24100)

As you can imagine though 24003 digits is usually too many to be
useful so it really depends what you're trying to do.

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

Re: [sympy] Sympy vs Numpy, better accuracy in precision?

[Oscar Benjamin]

On 11 April 2016 at 03:55, Amy Valhausen  wrote:
> In tried ;
>
> import mpmath
> x = Float("1.4142", 950)
> x**6000%400
>
> But got the same sort of error message again ;
>
 x = Float("1.4142", 950)
> Traceback (most recent call last):
>   File "", line 1, in 
> NameError: name 'Float' is not defined

You need to import Float and nsimplify from sympy with:

from sympy import Float, nsimplify

Or for these simple examples you could just do

from sympy import *

to import everything from sympy.

For your other questions about float accuracy see the responses from
Casevh and myself in the new thread that you started.

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

Re: [sympy] Bug in factor() and simplify()

[Oscar Benjamin]

On 26 February 2016 at 17:15, Aaron Meurer  wrote:
>> I traced this to here:
>>
>> In [1]: expr = x*sin(y)**2 + x*cos(y)**2 + 0.1*sin(y)**2 + 0.1*cos(y)**2
>>
>> In [2]: p = Poly(expr, x, cos(y), sin(y), domain='RR')
>>
>> In [3]: p
>> Out[3]: Poly(1.0*x*cos(y)**2 + 1.0*x*sin(y)**2 + 0.1*cos(y)**2 +
>> 0.1*sin(y)**2, x, cos(y), sin(y), domain='RR')
>>
>> In [4]: p.rep
>> Out[4]: DMP([[[1.0], [], [1.0, 0.0, 0.0]], [[0.1], [], [0.1, 0.0,
>> 0.0]]], RR, None)
>>
>> In [5]: p.rep.factor_list()
>> Out[5]:
>> (1.0,
>>  [(DMP([[[0.1], [], [0.1, 0.0, 0.0]]], RR, None), 1),
>>   (DMP([[[1.0]], [[0.1]]], RR, None), 1)])
>>
>> I think the bug is in there somehow but I have no idea what it means.
>> What is p.rep and how do you interpret it?
>
> It's the internal representation of the polynomial. It's a list of
> lists of lists of the coefficients (one level deep for each variable
> of the polynomial). factor_list() has a bug with floating point
> coefficients, it seems. Can you open an issue, if you haven't already?

I will do soon as I've almost fixed it. Actually I've found the bug in
dmp_factor_list in sympy/polys/factortools.py.

A simple example is

In [1]: x**2 - 0.01*y**2
Out[1]:
 2 2
x  - 0.01⋅y

In [2]: factor(x**2 - 0.01*y**2)
Out[2]: 1.0⋅(0.1⋅x - 0.01⋅y)⋅(0.1⋅x + 0.01⋅y)

In [3]: expand(factor(x**2 - 0.01*y**2))
Out[3]:
  2   2
0.01⋅x  - 0.0001⋅y

The bug is due to this:
https://github.com/sympy/sympy/blob/master/sympy/polys/factortools.py#L1272

The first pulls out a factor of 1/100 from the polynomial so that we get

(1/100) and (100*x**2 - y**2)

the second part is factored to

(10*x + y)*(10*x - y)

The factor of 100 is brought back in here:
https://github.com/sympy/sympy/blob/master/sympy/polys/factortools.py#L1304

However it is divided from BOTH factors to give

(10*x + y)/100 * (10*x - y)/100

So the result is 100x smaller than it should be. This will happen any
time you have non-integer valued floating point coefficients and there
are at least 2 polynomial factors in the expression.

I have an easy fix in dmp_factor_list:

$ git diff master
diff --git a/sympy/polys/factortools.py b/sympy/polys/factortools.py
index ebbabb8..ccecda6 100644
--- a/sympy/polys/factortools.py
+++ b/sympy/polys/factortools.py
@@ -1302,7 +1302,8 @@ def dmp_factor_list(f, u, K0):
 coeff = coeff/denom
 else:
 for i, (f, k) in enumerate(factors):
-f = dmp_quo_ground(f, denom, u, K0)
+if i == 0:
+f = dmp_quo_ground(f, denom, u, K0)
 f = dmp_convert(f, u, K0, K0_inexact)
 factors[i] = (f, k)

I think I can see the same bug in dup_factor_list:

https://github.com/sympy/sympy/blob/master/sympy/polys/factortools.py#L1197
https://github.com/sympy/sympy/blob/master/sympy/polys/factortools.py#L1225

But I don't know how to trigger a code path that would go through
dup_factor_list. Under what circumstances would I hit that path?

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

Re: [sympy] Sympy vs Numpy, better accuracy in precision?

[Oscar Benjamin]

On 5 April 2016 at 01:56, Amy Valhausen  wrote:
>
> import numpy
> (np.longdouble(1.4142)** 6000 )%400
...
>
> # The library mpmath is a good solution
 import sympy as smp
 mp = smp.mpmath
>
 mp.mp.dps = 50  # Computation precision is 50 digits


50 digits is nowhere near enough. Think about what the number
1.4142**6000 is: it's a big number. If I wrote it out in digits it
might look something like:

5432321453425234...234234234.123235345345

The digits that contain the precision needed to get the remainder
modulo 400 begin just before the decimal point. So how many digits are
there before that? If d is the number of digits preceding the decimal
point then loosely:

  10**d = 1.4142**6000

Which gives that

d = log10(1.4142**6000) = 6000*log10(1.4142) ~= 903

So if you want an answer that's good for m digits you'll need to use
about 900+m digits for the exponentiation:

In [1]: from sympy import mpmath

In [2]: mpmath.mp.dps = 950

In [3]: mpmath.mpf('1.4142') ** 6000 % 400
Out[3]: 
mpf('271.048181008630921815939109488389292518324580362344398848121124779167483584534976647550313880646779627157871790825164801629065802757168057723902165889739990234375')

BTW it's also possible to do this particular calculation easily enough
just with Python stdlib (and without numpy or sympy):

In [1]: from fractions import Fraction

In [2]: float(Fraction('1.4142')**6000 % 400)
Out[2]: 271.04818100863093


I though that it should be possible to easily do this with sympy
Floats but it doesn't seem to work:

In [1]: x = S(1.4142)

In [2]: x
Out[2]: 1.414200

In [3]: x**6000
Out[3]: 1.16144178843571e+903

In [4]: x**6000 % 400
Out[4]: 32.0

This doesn't work because auto-evaluation of x**6000 destroyed all the
precision so I tried:

In [5]: Pow(x, 6000, evaluate=False)
Out[5]:
  6000
1.4142

In [6]: Pow(x, 6000, evaluate=False) % 400
Out[6]: Mod(1.16144178843571e+903, 400)

Well that's annoying. It's gone ahead and auto-evaluated the x**6000
but created a Mod object instead of evaluating the modular division.

So let's disable evaluation of at the mod step as well:

In [10]: Mod(Pow(x, 6000, evaluate=False), 400, evaluate=False).evalf(50)
Out[10]:
   ⎛  6000 ⎞
Mod⎝1.4142, 400⎠

How do I get that to actually evaluate?


--
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/CAHVvXxRWe%2BDykG15%3Dks%2Bs04mF%2BgS2LmtRJ_kmAWQdwXNHAg5Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] dsolve fails to integrate simple ODE

[Oscar Benjamin]

Thanks for the quick response. I have one more while I'm here:

In [*43*]: eqn = exp(f(x).diff(x)-f(x))


In [*44*]: eqn

Out[*44*]:

 d

 -f(x) + ──(f(x))

 dx

ℯ


In [*45*]: dsolve(eqn, f(x))

---

IndexErrorTraceback (most recent call last)

 in ()

> 1 dsolve(eqn, f(x))


~/current/sympy/venv/lib/python3.6/site-packages/sympy/solvers/ode.py in
dsolve(eq, func, hint, simplify, ics, xi, eta, x0, n, **kwargs)

*662* # The key 'hint' stores the hint needed to be solved
for.

*663* hint = hints['hint']

--> 664 return _helper_simplify(eq, hint, hints, simplify, ics=
ics)

*665*

*666* def _helper_simplify(eq, hint, match, simplify=True, ics=None, **
kwargs):


~/current/sympy/venv/lib/python3.6/site-packages/sympy/solvers/ode.py in
_helper_simplify(eq, hint, match, simplify, ics, **kwargs)

*687* # attempt to solve for func, and apply any other hint
specific

*688* # simplifications

--> 689 sols = solvefunc(eq, func, order, match)

*690* if isinstance(sols, Expr):

*691* rv =  odesimp(sols, func, order, cons(sols), hint)


~/current/sympy/venv/lib/python3.6/site-packages/sympy/solvers/ode.py in
ode_lie_group(eq, func, order, match)

*   5460* else:

*   5461* y = Dummy("y")

-> 5462 h = sol[0].subs(func, y)

*   5463*

*   5464* if xis is not None and etas is not None:


IndexError: list index out of range

Not sure what the right response is here but perhaps not an IndexError.

--
Oscar


On Wed, 12 Sep 2018 at 00:06, Aaron Meurer  wrote:

> The algorithms to solve it aren't implemented. In factored form, the
> equation can be solved by integrating as you mentioned. There is an
> issue to implement this algorithm, but it hasn't been done yet
> https://github.com/sympy/sympy/issues/6259.
>
> In expanded form it is a Euler equation, but the algorithm isn't smart
> enough to recognize it (you need to multiply through by x**2). If you
> do that you get an answer:
>
> >>> dsolve((eqn.doit()*x**2).expand())
> Eq(f(x), C1 + C2*log(x) + (x - 1)*exp(x)*log(x) -
> Integral(x*exp(x)*log(x), x))
>
> I opened https://github.com/sympy/sympy/issues/15217 for this.
>
> I guess based on your other calculation the answer should be
> expressible via Ei, which SymPy doesn't know how to do for that
> integral.
>
> Regarding the final issue, I'm not sure why integrate() on an Eq
> doesn't evaluate the integral, but if you call doit() it computes it.
>
> >>> dsolve(eqn, g(x)).integrate(x).doit()
> Eq(Integral(g(x), x), C1*log(x) + exp(x) - Ei(x))
>
> I opened https://github.com/sympy/sympy/issues/15218 for this.
>
> Aaron Meurer
>
> On Tue, Sep 11, 2018 at 4:53 PM, Oscar Benjamin
>  wrote:
> > Hi,
> >
> > I'm not sure if I'm missing a trick but I've been trying to use dsolve
> and
> > it seems it doesn't work in many simple cases. I've put some examples
> below,
> > tested with sympy 1.2 installed using pip. I don't know if any of the
> below
> > is me using dsolve incorrectly or should be considered a bug or is just a
> > reflection of it being a work in progress.
> >
> > I want to solve the heat/diffusion equation for heat in a cylinder with
> an
> > exponential heat term:
> >
> > $ isympy
> >
> > In [1]: eqn = Derivative(Derivative(f(x),x)*x,x)/x - exp(x)
> >
> >
> > In [2]: eqn
> >
> > Out[2]:
> >
> >d ⎛  d   ⎞
> >
> >──⎜x⋅──(f(x))⎟
> >
> >x   dx⎝  dx  ⎠
> >
> > - ℯ  + ──
> >
> >  x
> >
> >
> > In [3]: dsolve(eqn, f(x))
> >
> >
> ---
> >
> > NotImplementedError
> >
> >
> > It strikes me as odd that sympy can't solve this since it's essentially
> an
> > algebraic rearrangement to get f here and all that is needed is to
> > understand that d/dx can be integrated. Sympy can do the integrals:
> >
> > In [16]: res = expand((simplify(eqn * x).integrate(x) +
> C1)/x).integrate(x)
> > + C2
> >
> > ...:
> >
> >
> > In [17]: res
> >
> > Out[17]:
> >
> >  x
> >
> > C₁⋅log(x) + C₂ + f(x) - ℯ  + Ei(x)
> >
> >
> > In [18]: solve(res, f(x))
> >
> > Out[18]:
> >
> > ⎡   x⎤
> >
> > ⎣-C₁⋅log(x) - C₂ + ℯ  - Ei(x)⎦
> >
> >
> > The algorithm for

[sympy] dsolve fails to integrate simple ODE

[Oscar Benjamin]

Hi,

I'm not sure if I'm missing a trick but I've been trying to use dsolve and
it seems it doesn't work in many simple cases. I've put some examples
below, tested with sympy 1.2 installed using pip. I don't know if any of
the below is me using dsolve incorrectly or should be considered a bug or
is just a reflection of it being a work in progress.

I want to solve the heat/diffusion equation for heat in a cylinder with an
exponential heat term:

$ isympy

In [*1*]: eqn = Derivative(Derivative(f(x),x)*x,x)/x - exp(x)


In [*2*]: eqn

Out[*2*]:

   d ⎛  d   ⎞

   ──⎜x⋅──(f(x))⎟

   x   dx⎝  dx  ⎠

- ℯ  + ──

 x


In [*3*]: dsolve(eqn, f(x))

---

NotImplementedError

It strikes me as odd that sympy can't solve this since it's essentially an
algebraic rearrangement to get f here and all that is needed is to
understand that d/dx can be integrated. Sympy can do the integrals:

In [*16*]: res = expand((simplify(eqn * x).integrate(x) +
C1)/x).integrate(x) + C2

...:


In [*17*]: res

Out[*17*]:

 x

C₁⋅log(x) + C₂ + f(x) - ℯ  + Ei(x)


In [*18*]: solve(res, f(x))

Out[*18*]:

⎡   x⎤

⎣-C₁⋅log(x) - C₂ + ℯ  - Ei(x)⎦

The algorithm for this is essentially the same as solving an algebraic
equation. If I replace the derivatives with logs then solve can do it:

In [*23*]: eqn = log(log(f(x))*x)/x - exp(x)


In [*24*]: eqn

Out[*24*]:

   x   log(x⋅log(f(x)))

- ℯ  + 

  x


In [*25*]: solve(eqn, f(x))

Out[*25*]:

⎡ x⎤

⎢  x⋅ℯ ⎥

⎢ ℯ⎥

⎢ ─⎥

⎢   x  ⎥

⎣ℯ ⎦

If I use f(x).diff(x) rather than Derivative then it looks more complicated
but should work:

In [*26*]: eqn = ((f(x)).diff(x)*x).diff(x)/x - exp(x)


In [*27*]: eqn

Out[*27*]:

   2

  d  d

   x⋅───(f(x)) + ──(f(x))

   2 dx

   x dx

- ℯ  + ──

 x


In [*28*]: dsolve(eqn)

---

NotImplementedError

The automatic expansion of the product rule here leaves us in a slightly
trickier position but again there is a general rule that sympy is
overlooking here: Use a substitution f' = g to bring it to 1st order:

In [*32*]: eqn = (g(x)*x).diff(x)/x - exp(x)


In [*33*]: eqn

Out[*33*]:

 d

   x⋅──(g(x)) + g(x)

   x dx

- ℯ  + ─

   x


In [*34*]: dsolve(eqn, g(x))

Out[*34*]:

  x

   C₁x   ℯ

g(x) = ── + ℯ  - ──

   x x

Then strangely I get:

In [*41*]: dsolve(eqn, g(x)).integrate(x)

Out[*41*]:

⌠

⎮ ⎛   x⎞

⌠   ⎮ ⎜C₁x   ℯ ⎟

⎮ g(x) dx = ⎮ ⎜── + ℯ  - ──⎟ dx

⌡   ⎮ ⎝x x ⎠

⌡

But if I just integrate the rhs it does the integral:

In [*40*]: dsolve(eqn, g(x)).rhs.integrate(x)

Out[*40*]:

 x

C₁⋅log(x) + ℯ  - Ei(x)

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

Re: [sympy] dsolve fails to integrate simple ODE

[Oscar Benjamin]

Done:
https://github.com/sympy/sympy/issues/15219


On Wed, 12 Sep 2018 at 00:30, Aaron Meurer  wrote:

> IndexError indicates a bug. Can you open an issue for it?
>
> Aaron Meurer
>
> On Tue, Sep 11, 2018 at 5:28 PM, Oscar Benjamin
>  wrote:
> > Thanks for the quick response. I have one more while I'm here:
> >
> > In [43]: eqn = exp(f(x).diff(x)-f(x))
> >
> >
> > In [44]: eqn
> >
> > Out[44]:
> >
> >  d
> >
> >  -f(x) + ──(f(x))
> >
> >  dx
> >
> > ℯ
> >
> >
> > In [45]: dsolve(eqn, f(x))
> >
> >
> ---
> >
> > IndexErrorTraceback (most recent call
> last)
> >
> >  in ()
> >
> > > 1 dsolve(eqn, f(x))
> >
> >
> > ~/current/sympy/venv/lib/python3.6/site-packages/sympy/solvers/ode.py in
> > dsolve(eq, func, hint, simplify, ics, xi, eta, x0, n, **kwargs)
> >
> > 662 # The key 'hint' stores the hint needed to be solved
> > for.
> >
> > 663 hint = hints['hint']
> >
> > --> 664 return _helper_simplify(eq, hint, hints, simplify,
> > ics=ics)
> >
> > 665
> >
> > 666 def _helper_simplify(eq, hint, match, simplify=True, ics=None,
> > **kwargs):
> >
> >
> > ~/current/sympy/venv/lib/python3.6/site-packages/sympy/solvers/ode.py in
> > _helper_simplify(eq, hint, match, simplify, ics, **kwargs)
> >
> > 687 # attempt to solve for func, and apply any other hint
> > specific
> >
> > 688 # simplifications
> >
> > --> 689 sols = solvefunc(eq, func, order, match)
> >
> > 690 if isinstance(sols, Expr):
> >
> > 691 rv =  odesimp(sols, func, order, cons(sols), hint)
> >
> >
> > ~/current/sympy/venv/lib/python3.6/site-packages/sympy/solvers/ode.py in
> > ode_lie_group(eq, func, order, match)
> >
> >5460 else:
> >
> >5461 y = Dummy("y")
> >
> > -> 5462 h = sol[0].subs(func, y)
> >
> >5463
> >
> >5464 if xis is not None and etas is not None:
> >
> >
> > IndexError: list index out of range
> >
> >
> > Not sure what the right response is here but perhaps not an IndexError.
> >
> > --
> > Oscar
> >
> >
> > On Wed, 12 Sep 2018 at 00:06, Aaron Meurer  wrote:
> >>
> >> The algorithms to solve it aren't implemented. In factored form, the
> >> equation can be solved by integrating as you mentioned. There is an
> >> issue to implement this algorithm, but it hasn't been done yet
> >> https://github.com/sympy/sympy/issues/6259.
> >>
> >> In expanded form it is a Euler equation, but the algorithm isn't smart
> >> enough to recognize it (you need to multiply through by x**2). If you
> >> do that you get an answer:
> >>
> >> >>> dsolve((eqn.doit()*x**2).expand())
> >> Eq(f(x), C1 + C2*log(x) + (x - 1)*exp(x)*log(x) -
> >> Integral(x*exp(x)*log(x), x))
> >>
> >> I opened https://github.com/sympy/sympy/issues/15217 for this.
> >>
> >> I guess based on your other calculation the answer should be
> >> expressible via Ei, which SymPy doesn't know how to do for that
> >> integral.
> >>
> >> Regarding the final issue, I'm not sure why integrate() on an Eq
> >> doesn't evaluate the integral, but if you call doit() it computes it.
> >>
> >> >>> dsolve(eqn, g(x)).integrate(x).doit()
> >> Eq(Integral(g(x), x), C1*log(x) + exp(x) - Ei(x))
> >>
> >> I opened https://github.com/sympy/sympy/issues/15218 for this.
> >>
> >> Aaron Meurer
> >>
> >> On Tue, Sep 11, 2018 at 4:53 PM, Oscar Benjamin
> >>  wrote:
> >> > Hi,
> >> >
> >> > I'm not sure if I'm missing a trick but I've been trying to use dsolve
> >> > and
> >> > it seems it doesn't work in many simple cases. I've put some examples
> >> > below,
> >> > tested with sympy 1.2 installed using pip. I don't know if any of the
> >> > below
> >> > is me using dsolve incorrectly or should be considered a bug or is
> just
> >> > a
> >> > reflection of it being a work in progress.
> >> >
> >> > I want to solve the heat/diffusion equ

Re: [sympy] Solving Integral with Symbolic Computation (Sympy), Division and Tricky Limits

[Oscar Benjamin]

On Fri, 19 Oct 2018 at 22:09, Aaron Meurer  wrote:
>
> You can pass the limits to integrate directly:
>
> >>> integrate(1/(x**2+y**2)**Rational(3,2), (y, -L/2, L/2))
> L/(x**3*sqrt(L**2/(4*x**2) + 1))
>
> It's generally recommended to do this as it isn't always correct to
> substitute the upper and lower values directly.  However, this result
> is equivalent to yours in this case, after pulling a 4 out of the
> square root.

Thinking about it the answer given by sympy above is only correct for x>0.

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

Re: [sympy] Solving Integral with Symbolic Computation (Sympy), Division and Tricky Limits

[Oscar Benjamin]

On Fri, 19 Oct 2018 at 17:17, bb  wrote:
>
> A physics teacher on an online course [presented][1] this integral,

I haven't looked at the video but...

> from sympy import integrate, sqrt, Symbol, pprint
> y = Symbol('y')
> x = Symbol('x')
> print (integrate('1/ ((x**2+y**2)**(3/2))',y))
>
> Result is
>
> y/(x**3*sqrt(1 + y**2/x**2))
>
> I plugged in the limits,
>
> from sympy import simplify
> L = Symbol('L')
> x = Symbol('x')
> simplify((L/2)/(x**3*sqrt(1 + (L/2)**2/x**2)) - \
>  (-L/2)/(x**3*sqrt(1 + (-L/2)**2/x**2)))
>
> I get
>
> 2*L/(x**3*sqrt(L**2/x**2 + 4))
>
> which does not look right.

I think this is correct. It just looks a bit strange because sympy
hasn't written it in the form you would normally use. The normal way
to write the result of the integral would be

>>> res = y/ (x**2 * (x**2+y**2)**Rational(1/2))
>>> res
y/(x**2*sqrt(x**2 + y**2))

We can see that this also differentates back to what you started with:

>>> res.diff(y)
-y**2/(x**2*(x**2 + y**2)**(3/2)) + 1/(x**2*sqrt(x**2 + y**2))
>>> simplify(res.diff(y))
(x**2 + y**2)**(-3/2)

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

[sympy] Operations on Eq objects

[Oscar Benjamin]

Hi all,

I find the behaviour of operations involving Eq strange. I would
really like to be able to use Eqs for algebra but they don't seem to
do anything useful. Is this behaviour intentional or is it something
that could be improved?

Setup:
>>> from sympy import *
>>> x = Symbol('x')
>>> y = Symbol('y')
>>> eq = Eq(x, y)
>>> eq
Eq(x, y)
>>> pprint(eq)
x = y

I don't understand what any of these mean:
>>> pprint(2*eq)
2⋅(x = y)
>>> pprint((2*eq).expand())
2⋅(x = y)
>>> exp(eq)
exp(Eq(x, y))
>>> pprint(abs(eq))
│x = y│
>>> eq - 1
-1 + Eq(x, y)
>>> pprint(eq - 1)
-1 + (x = y)

Integration works but differentiation doesn't:
>>> pprint(integrate(eq, x))
⌠⌠
⎮ x dx = ⎮ y dx
⌡⌡
>>> pprint(integrate(eq, x).doit())
 2
x
── = x⋅y
2
>>> diff(eq, x)
Derivative(Eq(x, y), x)
>>> pprint(diff(eq, x))
∂
──(x = y)
∂x
>>> pprint(diff(eq, x).doit())
∂
──(x = y)
∂x

Functions of Eq raise errors:
>>> sin(eq)
...
TypeError: cannot determine truth value of Relational

It looks as if I can chain equations and inequalities but does it
actually mean what it looks like mathematically?
>>> eq < 3
Eq(x, y) < 3
>>> pprint(eq < 3)
x = y < 3

Apart from the inequality example at the end I would like it if all of
the above operations acted on both lhs and rhs separately as in the
case of integration e.g.:

>>> eq
x = y
>>> 2*eq
2*x = 2*y
>>> sin(eq)
sin(x) = sin(y)

The other thing that I don't understand although it is clearly
documented is this:
>>> Eq(1, 1)
True
>>> Eq(1, 0)
False

These True/False values are annoying if you are building up Eqs
programatically e.g. to pass to solve:
>>> solve([Eq(1, 1), Eq(x, y), Eq(x, 1)], [x, y])
Traceback (most recent call last):
  File "", line 1, in 
  File "/Users/enojb/current/sympy/sympy/sympy/solvers/solvers.py",
line 980, in solve
return reduce_inequalities(f, symbols=symbols)
  File "/Users/enojb/current/sympy/sympy/sympy/solvers/inequalities.py",
line 987, in reduce_inequalities
rv = _reduce_inequalities(inequalities, symbols)
  File "/Users/enojb/current/sympy/sympy/sympy/solvers/inequalities.py",
line 907, in _reduce_inequalities
'''))
NotImplementedError:
inequality has more than one symbol of interest.

You can solve this last problem with evaluate=False but I really don't
understand why any evaluation is desirable here. I think that solve
has probably gotten confused here for the same reason that any other
code would: the True/False objects don't have any of the same
attributes that an Eq would have:

>>> Eq(0, 1).lhs
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'BooleanFalse' object has no attribute 'lhs'


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

Re: [sympy] Re: Operations on Eq objects

[Oscar Benjamin]

Thanks, I've commented there.

On Sat, 27 Oct 2018 at 20:40, Chris Smith  wrote:
>
> See this issue for previous discussion.
>
> On Saturday, October 27, 2018 at 12:44:09 PM UTC-5, Oscar wrote:
>>
>> Hi all,
>>
>> I find the behaviour of operations involving Eq strange. I would
>> really like to be able to use Eqs for algebra but they don't seem to
>> do anything useful. Is this behaviour intentional or is it something
>> that could be improved?
>>
>> Setup:
>> >>> from sympy import *
>> >>> x = Symbol('x')
>> >>> y = Symbol('y')
>> >>> eq = Eq(x, y)
>> >>> eq
>> Eq(x, y)
>> >>> pprint(eq)
>> x = y
>>
>> I don't understand what any of these mean:
>> >>> pprint(2*eq)
>> 2⋅(x = y)
>> >>> pprint((2*eq).expand())
>> 2⋅(x = y)
>> >>> exp(eq)
>> exp(Eq(x, y))
>> >>> pprint(abs(eq))
>> │x = y│
>> >>> eq - 1
>> -1 + Eq(x, y)
>> >>> pprint(eq - 1)
>> -1 + (x = y)
>>
>> Integration works but differentiation doesn't:
>> >>> pprint(integrate(eq, x))
>> ⌠⌠
>> ⎮ x dx = ⎮ y dx
>> ⌡⌡
>> >>> pprint(integrate(eq, x).doit())
>>  2
>> x
>> ── = x⋅y
>> 2
>> >>> diff(eq, x)
>> Derivative(Eq(x, y), x)
>> >>> pprint(diff(eq, x))
>> ∂
>> ──(x = y)
>> ∂x
>> >>> pprint(diff(eq, x).doit())
>> ∂
>> ──(x = y)
>> ∂x
>>
>> Functions of Eq raise errors:
>> >>> sin(eq)
>> ...
>> TypeError: cannot determine truth value of Relational
>>
>> It looks as if I can chain equations and inequalities but does it
>> actually mean what it looks like mathematically?
>> >>> eq < 3
>> Eq(x, y) < 3
>> >>> pprint(eq < 3)
>> x = y < 3
>>
>> Apart from the inequality example at the end I would like it if all of
>> the above operations acted on both lhs and rhs separately as in the
>> case of integration e.g.:
>>
>> >>> eq
>> x = y
>> >>> 2*eq
>> 2*x = 2*y
>> >>> sin(eq)
>> sin(x) = sin(y)
>>
>> The other thing that I don't understand although it is clearly
>> documented is this:
>> >>> Eq(1, 1)
>> True
>> >>> Eq(1, 0)
>> False
>>
>> These True/False values are annoying if you are building up Eqs
>> programatically e.g. to pass to solve:
>> >>> solve([Eq(1, 1), Eq(x, y), Eq(x, 1)], [x, y])
>> Traceback (most recent call last):
>>   File "", line 1, in 
>>   File "/Users/enojb/current/sympy/sympy/sympy/solvers/solvers.py",
>> line 980, in solve
>> return reduce_inequalities(f, symbols=symbols)
>>   File "/Users/enojb/current/sympy/sympy/sympy/solvers/inequalities.py",
>> line 987, in reduce_inequalities
>> rv = _reduce_inequalities(inequalities, symbols)
>>   File "/Users/enojb/current/sympy/sympy/sympy/solvers/inequalities.py",
>> line 907, in _reduce_inequalities
>> '''))
>> NotImplementedError:
>> inequality has more than one symbol of interest.
>>
>> You can solve this last problem with evaluate=False but I really don't
>> understand why any evaluation is desirable here. I think that solve
>> has probably gotten confused here for the same reason that any other
>> code would: the True/False objects don't have any of the same
>> attributes that an Eq would have:
>>
>> >>> Eq(0, 1).lhs
>> Traceback (most recent call last):
>>   File "", line 1, in 
>> AttributeError: 'BooleanFalse' object has no attribute 'lhs'
>>
>>
>> --
>> 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/420d940b-663f-4af7-b4eb-59a048d0bdb3%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/CAHVvXxSKpPy3rGkATFNcb_gc1YbFGA65PQ6FT3Sgb-%3Dw7kfhNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[sympy] Create a Matrix from blocks

[Oscar Benjamin]

Is there a straight-forward way to create a matrix from blocks?

The Matrix.diag function is nice for creating a block diagonal matrix:

In [1]: Matrix.diag(2*eye(2),3*eye(3))
Out[1]:
⎡2  0  0  0  0⎤
⎢ ⎥
⎢0  2  0  0  0⎥
⎢ ⎥
⎢0  0  3  0  0⎥
⎢ ⎥
⎢0  0  0  3  0⎥
⎢ ⎥
⎣0  0  0  0  3⎦

I'd like to do something similar but for a general block matrix. I
imagine something like:

>>> Matrix.fromblocks([[eye(2),2*eye(2)],[3*eye(2),4*eye(2)]])

The expected output would be:

[1 0 2 0]
[0 1 0 2]
[3 0 4 0]
[0 3 0 4]

This almost works if I pass a list of matrices to the Matrix constructor:

In [5]: Matrix([eye(2), eye(2)])
Out[5]:
⎡1  0⎤
⎢⎥
⎢0  1⎥
⎢⎥
⎢1  0⎥
⎢⎥
⎣0  1⎦

It doesn't work if I try to concatenate horizontally though:

In [7]: Matrix([[eye(2), eye(2)]])
Out[7]:
⎡⎡1  0⎤  ⎡1  0⎤⎤
⎢⎢⎥  ⎢⎥⎥
⎣⎣0  1⎦  ⎣0  1⎦⎦

Same happens if I try to do both:

In [8]: Matrix([[eye(2), eye(2)], [eye(2), eye(2)]])
Out[8]:
⎡⎡1  0⎤  ⎡1  0⎤⎤
⎢⎢⎥  ⎢⎥⎥
⎢⎣0  1⎦  ⎣0  1⎦⎥
⎢  ⎥
⎢⎡1  0⎤  ⎡1  0⎤⎥
⎢⎢⎥  ⎢⎥⎥
⎣⎣0  1⎦  ⎣0  1⎦⎦

I see that there is a BlockMatrix class but I don't want a block
matrix. I want to construct a normal matrix from blocks (similar to
diag). There is a deblock function but it doesn't do what I hoped:

In [13]: from sympy.matrices.expressions.blockmatrix import deblock

In [14]: deblock(Matrix([[eye(2), eye(2)], [eye(2), eye(2)]]))
Out[14]:
⎡⎡1  0⎤  ⎡1  0⎤⎤
⎢⎢⎥  ⎢⎥⎥
⎢⎣0  1⎦  ⎣0  1⎦⎥
⎢  ⎥
⎢⎡1  0⎤  ⎡1  0⎤⎥
⎢⎢⎥  ⎢⎥⎥
⎣⎣0  1⎦  ⎣0  1⎦

In [15]: deblock(BlockMatrix([[eye(2), eye(2)], [eye(2), eye(2)]]))
Out[15]:
⎡⎡1  0⎤  ⎡1  0⎤⎤
⎢⎢⎥  ⎢⎥⎥
⎢⎣0  1⎦  ⎣0  1⎦⎥
⎢  ⎥
⎢⎡1  0⎤  ⎡1  0⎤⎥
⎢⎢⎥  ⎢⎥⎥
⎣⎣0  1⎦  ⎣0  1⎦⎦

Am I missing a similar way to do this?

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

[sympy] Running SymPy's tests with pytest

[Oscar Benjamin]

Hi all,

For the past two months I've been working on making it possible to run
SymPy's test suite using pytest. It is now possible to do this so I
thought I'd write something here to explain how to use it and why it
can be useful.

There are two options in particular that I find very useful while
writing a patch for SymPy: -n for distributing tests over multiple
cores and --lf for only rerunning failed tests but first I'll explain
how to use pytest right now.


Installation and basic usage
-

A couple of things were fixed in pytest along the way so you might see
a couple of spurious fails if you're not using the most recent version
which can be installed with:

$ pip install pytest

You can then run SymPy's tests from the project root with

$ pytest -m 'not slow'

This will run all of the tests not marked with slow as is the default
when running using bin/test for SymPy's internal test runner. Pytest
also can accept a path if you want to run tests from a specific file:

$ pytest -m 'not slow' sympy/solvers/tests/test_ode.py

You can specify a particular test by name with -k

$ pytest sympy/solvers/tests/test_ode.py -k test_ode_order

You can also use an expression like

$ pytest sympy/solvers/tests/test_ode.py -k 'not test_linear'

This will run all tests from test_ode.py whose names do not begin with
test_linear.

The -m and -k flags can be combined and you can use more complex
expressions like -m 'not slow and not xfail'. Note that pytest runs
xfail tests by default and reports with they fail or pass (xpass).
SymPy's test runner just skips xfail tests.


Assert rewriting


Pytest has extensive assert-rewriting so as a simple example you can
get a fail message like:

__ test_ode_order 

def test_ode_order():
x = 0
from sympy import pi
f = Function('f')
g = Function('g')
assert sin(0) == 0
assert sin(pi) == 0
assert sin(-pi) == 0
assert sin(2*pi) == 0
>   assert sin(x) == 1
E   assert 0 == 1
E+  where 0 = sin(0)

sympy/solvers/tests/test_ode.py:1124: AssertionError

Note that it shows you the argument that is passed to sin and compare
with the output from bin/test:

Traceback (most recent call last):
  File "/Users/enojb/current/sympy/sympy/sympy/solvers/tests/test_ode.py",
line 1123, in test_ode_order
assert sin(x) == 1
AssertionError

SymPy's test runner has limited assert rewriting with bin/test -E:

Traceback (most recent call last):
  File "/Users/enojb/current/sympy/sympy/sympy/solvers/tests/test_ode.py",
line 1123, in test_ode_order
assert sin(x) == 1
AssertionError:
0 ==
1


Remembering failed tests
-

Pytest stores which tests have failed persistently between runs which
means that after running many tests you can rerun only the failed
tests with either

$ pytest --last-failed
$ pytest --lf

This is useful in the workflow:
1) Make changes
2) Run all tests
3) Look through fails and try to fix
4) Rerun fails with --lf
5) (Loop back to 3 if there are still fails)
6) Rerun all tests
7) Commit/push etc.

Pytest has a number of other options that make use of remembering
which tests have failed but this is the only one I've used.


Multicore test-running
-

Something that I find particularly useful about pytest is the xdist
plugin which allows running tests in parallel using worker processes
to take advantage of multiple cores. To use this you first need to
install it separately:

$ pip install pytest-xdist

Then you can invoke xdist from any pytest command by providing e.g.
-n4 to use 4 cores. For example (on this laptop):

$ bin/test sympy/solvers/tests/test_ode.py# 308 seconds
$ pytest -m 'not slow and not xfail'
sympy/solvers/tests/test_ode.py   # 310 seconds
$ pytest -m 'not slow and not xfail'
sympy/solvers/tests/test_ode.py -n4   # 166 seconds

On my work computer which has 8 cores I can run with -n7 and all
non-slow tests and doctests are completed in 13 minutes. I use -n7
because it means I can still use the computer: -n8 (all cores) runs
the tests faster but makes it noticeably difficult to do other things
at the same time.


Doctests


To run SymPy's doctests I've made use of the doctestplus pytest plugin:
https://github.com/astropy/pytest-doctestplus
This has been developed by the astropy project because of deficiencies
in pytest's standard doctest runner that also apply to SymPy. It
provides:
  * inexact comparison for doctests with float output
  * ability to run doctests in rst files
  * skipping doctests based on presence of optional dependencies

To use this you need to install it which you would normally do with

$ pip install pytest-doctestplus

However in getting this to work I have submitted patches to
doctestplus which are accepted but not yet released so for now you
need 

Re: [sympy] Running SymPy's tests with pytest

[Oscar Benjamin]

On Mon, 21 Jan 2019 at 23:58, Aaron Meurer  wrote:
>
> > SymPy's test runner just skips xfail tests.
>
> This should not be the case, except for slow xfail tests.

Sorry I've just checked and you're right. bin/test does run the xfail
tests and does report them as xpass with an X if they pass rather than
f for xfail.

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

[sympy] Unrelated PRs failing Travis tests due to test_sympify

[Oscar Benjamin]

Hi all,

Travis tests are failing in unrelated PRs due to the same issue. You
can see an example here:
https://travis-ci.org/sympy/sympy/jobs/457806002

The test run that fails is for optional dependencies on Python 3.6. I
guess that either a bug has snuck into master or there has been some
change in the dependencies.

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

Re: [sympy] Introduction and Question

[Oscar Benjamin]

On Sat, 17 Nov 2018 at 07:20, Pulkit Arora  wrote:
>
> Hi! I'm Pulkit Arora a 2nd year undergraduate, I came across sympy a week ago 
> and i was having some trouble finding my way in the Huge codebase SymPy has, 
> can someone help me out a bit?

Hi Pulkit. What exactly are you looking for?

> Also, Is it a good idea to get a grasp of sympy/core package or should i just 
> read its docs and try to solve issues in other packages?
> Thanks in advance!

I guess that depends what you want to do. If you're looking to improve
SymPy maybe you should try it out before looking at the code to see
which bits you would like to use and which you think can be improved.

--
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/CAHVvXxQSmVCLiw3FXoWvmFnqnbGKQ-5QvHW%2BDrObJDrNpxuBsA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[sympy] Defining custom invertible functions

[Oscar Benjamin]

Hi,

I was just looking at a way to solve ODEs algebraically and came up with
the code below which almost works (just needs integration constants). I
have a few questions though.

1. What is the right way to define an arbitrary invertible function and its
inverse?

2. Is the code below abusing doit() or is that a reasonable way to use it?

3. Should I check for the inverses in __new__ or is there a better way to
do that?

4. Does this represent a reasonable approach for something that could be
implemented in dsolve?

5. How can I make a different integration constant each time I call
intx.doit()?

class diffx(Function):
def __new__(cls, expr):
if isinstance(expr, intx):
return expr.args[0]
else:
return super().__new__(cls, expr)
def inverse(self):
return intx

class intx(Function):
def __new__(cls, expr):
if isinstance(expr, diffx):
return expr.args[0]
else:
return super().__new__(cls, expr)
def inverse(self):
return intx
def doit(self):
return Integral(self.args[0].doit(), x).doit()  # + Symbol('C')

eqn = diffx(x*diffx(f(x)))/x - exp(x)
soln,= solve(eqn, f(x))
print(soln.doit())

--
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/CAHVvXxS%2Brg9Jd4U%2BiHQH%3Df64MvJKxPB4RpO9t%3DLYfyGzESuyDA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] SymPy 1.4 release candidate 1 ready for testing

[Oscar Benjamin]

I think it is now possible to upload pre-releases to PyPI so that
users can ask pip to install them:
https://pip.pypa.io/en/stable/reference/pip_install/#pre-release-versions
https://packaging.python.org/guides/distributing-packages-using-setuptools/#pre-release-versioning

Also most Python projects these days provide wheels. Maybe SymPy
should do the same.

--
Oscar

On Tue, 2 Apr 2019 at 22:14, Aaron Meurer  wrote:
>
> Thanks. GitHub recently changed that, and I edited the old releases,
> but I guess I forgot to update the release script. I wish they would
> just let us remove those entirely from the release pages.
>
> Aaron Meurer
>
> On Tue, Apr 2, 2019 at 3:12 PM Ondřej Čertík  wrote:
> >
> >
> >
> > On Mon, Apr 1, 2019, at 9:44 PM, Aaron Meurer wrote:
> > > The SymPy 1.4 release candidate 1 is ready for testing. Please
> > > download it and let us know if you have any issues.
> > >
> > > The release can be downloaded from
> > > https://github.com/sympy/sympy/releases/tag/sympy-1.4rc1.
> > >
> > > The release notes for 1.4 are at
> > > https://github.com/sympy/sympy/wiki/release-notes-for-1.4. Feel free
> > > to edit that wiki page if you see any improvements that need to be
> > > made.
> >
> > I changed "Note: Do not download the Source code (zip) or the Source code 
> > (tar.gz)
> > files above." to "Note: Do not download the Source code (zip) or the Source 
> > code (tar.gz)
> > files below.".
> >
> > Because the files are now below.
> >
> > Ondrej
> >
> > --
> > 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/ee17e7e4-68cd-43d5-be7f-b181a226a887%40www.fastmail.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%3D6%2BKsDgH4TAd-wWcTKe-KpRnhB3PY-dgUxr2p%2Biavm%2Bh7g%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/CAHVvXxTy2MB98beeNbP-Vxv%3DngZ9V3i6JoJPp%3DJQDqw%3DQuLB%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] SymPy 1.4 release candidate 1 ready for testing

[Oscar Benjamin]

Making a wheel is not hard:

$ pip install wheel
$ python setup.py bdist_wheel
$ ls dist/
sympy-1.4rc1-py3-none-any.whl

--
Oscar

On Tue, 2 Apr 2019 at 22:39, Nathan Goldbaum  wrote:
>
> It would also be really nice to set up wheels for fastcache. I’ve had it on 
> my todo list forever.
>
> On Tue, Apr 2, 2019 at 4:38 PM Aaron Meurer  wrote:
>>
>> I should look into prereleases. I've shied away from them in the past
>> because pip used to install them by default. But I think things are
>> better now.  I also should get wheels working. I think it should be an
>> easy thing to add to the release script. I'll look into if it is
>> possible.
>>
>> Aaron Meurer
>>
>> On Tue, Apr 2, 2019 at 3:28 PM Oscar Benjamin
>>  wrote:
>> >
>> > I think it is now possible to upload pre-releases to PyPI so that
>> > users can ask pip to install them:
>> > https://pip.pypa.io/en/stable/reference/pip_install/#pre-release-versions
>> > https://packaging.python.org/guides/distributing-packages-using-setuptools/#pre-release-versioning
>> >
>> > Also most Python projects these days provide wheels. Maybe SymPy
>> > should do the same.
>> >
>> > --
>> > Oscar
>> >
>> > On Tue, 2 Apr 2019 at 22:14, Aaron Meurer  wrote:
>> > >
>> > > Thanks. GitHub recently changed that, and I edited the old releases,
>> > > but I guess I forgot to update the release script. I wish they would
>> > > just let us remove those entirely from the release pages.
>> > >
>> > > Aaron Meurer
>> > >
>> > > On Tue, Apr 2, 2019 at 3:12 PM Ondřej Čertík  wrote:
>> > > >
>> > > >
>> > > >
>> > > > On Mon, Apr 1, 2019, at 9:44 PM, Aaron Meurer wrote:
>> > > > > The SymPy 1.4 release candidate 1 is ready for testing. Please
>> > > > > download it and let us know if you have any issues.
>> > > > >
>> > > > > The release can be downloaded from
>> > > > > https://github.com/sympy/sympy/releases/tag/sympy-1.4rc1.
>> > > > >
>> > > > > The release notes for 1.4 are at
>> > > > > https://github.com/sympy/sympy/wiki/release-notes-for-1.4. Feel free
>> > > > > to edit that wiki page if you see any improvements that need to be
>> > > > > made.
>> > > >
>> > > > I changed "Note: Do not download the Source code (zip) or the Source 
>> > > > code (tar.gz)
>> > > > files above." to "Note: Do not download the Source code (zip) or the 
>> > > > Source code (tar.gz)
>> > > > files below.".
>> > > >
>> > > > Because the files are now below.
>> > > >
>> > > > Ondrej
>> > > >
>> > > > --
>> > > > 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/ee17e7e4-68cd-43d5-be7f-b181a226a887%40www.fastmail.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%3D6%2BKsDgH4TAd-wWcTKe-KpRnhB3PY-dgUxr2p%2Biavm%2Bh7g%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+unsubsc

Re: [sympy] problem with Imaginary in sympy

[Oscar Benjamin]

You can do it like this:

In [7]: setupstr='LI(OAMHolo(OAMHolo(XX,e,6),f,2),a,f)'

In [8]: from sympy import S

In [9]: S(setupstr)
Out[9]: LI(OAMHolo(OAMHolo(XX, e, 6), f, 2), a, f)


On Thu, 4 Apr 2019 at 15:41, Xuemei Gu  wrote:
>
> Thank you very much!
>
> I have another question:
>
> I get a string list such as  setupstr='LI(OAMHolo(OAMHolo(XX,e,6),f,2),a,f)'
>
> however in the string, LI OAMHolo are own defined functions, I don't know how 
> to replace them as functions.
> I want to know how to do in sympy like I use ToExpression in Mathematica.
>
> Thank you very much!
> best regards
> Mei
>
> On Mon, Apr 1, 2019 at 9:31 PM Aaron Meurer  wrote:
>>
>> I was hoping something like collect(x*y + x, [x, y], evaluate=False)
>> would do what you want, but it doesn't quite.
>>
>> You could create a Poly with the coefficients as variables and use
>> Poly.as_coefficients_dict.
>>
>> Aaron Meurer
>>
>> On Mon, Apr 1, 2019 at 1:02 PM Xuemei Gu  wrote:
>> >
>> >
>> > hey,
>> >
>> > I wander whether one has occurred such problem:
>> >
>> > I define a initial state:
>> >
>> > state=a[1]*b[0]*c[0]*d[0]*1j+a[1]*b[0]*c[0]*d[0] + a[2]*b[1]*c[1]*d[1] 
>> > # for some reason I have to do such decomposition
>> >
>> > datalist=state.as_coefficients_dict()
>> >
>> >
>> > I can get:
>> > { FF2[0]*FF3[0]*FF4[0]: 1,  FF2[1]*FF3[1]*FF4[1]: 1,
>> > I*FF2[0]*FF3[0]*FF4[0]: 1 }
>> >
>> > Now the problem is :
>> >
>> > Because I is a Imaginary number, it's not a symbol. How can I get 
>> > something such as  { FF2[0]*FF3[0]*FF4[0]: 1,  FF2[1]*FF3[1]*FF4[1]: 1,
>> > FF2[0]*FF3[0]*FF4[0]: 1j} or { FF2[0]*FF3[0]*FF4[0]: 1+1j,  
>> > FF2[1]*FF3[1]*FF4[1]: 1 }
>> >
>> > Thank you very much!
>> >
>> >
>> >
>> >
>> > --
>> > 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/d4505824-6110-4541-8199-09b6768315d9%40googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "sympy" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/sympy/GKRuQ1iYgEI/unsubscribe.
>> To unsubscribe from this group and all its topics, 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%3D6J5MX4JqkoRkVaL1a6C57wpGBKaXBH%3DhOZeK-cPe04SKg%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Xuemei Gu
> PhD Student
>
> State Key Laboratory for Novel Software Technology, Nanjing University
> 163 Xianlin Avenue, Qixia District, 210023, Nanjing City, China
>
> Institute for Quantum Optics and Quantum Information, Vienna
> Boltzmanngasse 3, A-1090 Vienna, Austria
>
> http://iqoqi-vienna.at/
> Office: +43 (0) 1 4277 29568
>
> --
> 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/CA%2BDAqr9yd3BkQnNYQ%3Dp6cXKccc8yZrFgirqxB3DmxEq%3Djy1grg%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/CAHVvXxR77kisBe8rkjsZ8cVgvqwf5Ggd5BuaKuBfFwRK0sWdsA%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]

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
>>>>

Re: [sympy] GSoC 2019 Proposal: Differential Equations

[Oscar Benjamin]

Hi Grace,

I don't know where it is you're looking to see the proposals for
differential equations but I can tell you that the ODE systems code is
a bit of a mess right now. See the label solvers.dsolve on Github for
relevant issues/PRs.

At the moment there are many methods for very specific types of ODE
but many are untested and/or don't work and many obvious cases are
missing. What is needed is some good more general methods. In some
cases I have tried to come up with examples but I can't come up with
any example where the method is useful.

If I was going to spend time fixing this then I would firstly:

1. Try to improve test coverage for the systems methods that are there
2. Fix the constant coeff homogeneous case (there are existing stalled
PRs) and a number of open issues
3. Remove as many of possible of the methods that are special cases of 2.
4. Handle the non-homogeneous version of 2 (and remove corresponding
special cases)
5. Add a generalised version of the nth_algebraic ODE solver that can
be used for simple ODE systems.

There will still be plenty more to do after that.

A good way to start working on this would be to identify the untested
methods and try to add tests for them. (If you run test_ode with
coverage testing enabled you can see which ones are covered).

--
Oscar

On Sat, 6 Apr 2019 at 19:55,  wrote:
>
> Hi everyone,
>
> My name is Grace Arnold and I'm a computer science major at the Illinois 
> Institute of Technology. I have a few years of experience with Java and 
> Python, and have taken the Differential Equations course. I'm interested in 
> contributing to SymPy's Differential Equations methods. Specifically, I see 
> that general linear systems of more than two equations was mentioned in the 
> project ideas. I would love to contribute to this project, but if anyone 
> could provide me with more direction regarding this project (i.e. more 
> desirable functions to be implemented within differential equations), then I 
> would be happy to hear them!
>
> I will be working on my proposal and more ideas soon and will post them here, 
> if anyone would like to read it and tell me what I can improve upon.
>
> Thank you co much,
> Grace Arnold
>
>
>
> --
> 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/44e5d117-da3a-41fb-a227-684c1de98e8c%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/CAHVvXxRP0icL01vD%3Dqb7mg33j8DsHorMMXWj--YHYSBC3rmS-g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Implementation of ODE's solution.

[Oscar Benjamin]

Great.

The separation ansatz and the Bessel function idea are both good. I
believe someone started a PR at some point for Bessel/Airy functions
so probably good to look at that as well.

For Lie groups the existing code needs substantial improvement. It is
largely untested and has many bugs. If that code was in an open PR now
then I would object to merging it. I think the priority there is not
so much extending the Lie group solvers but fixing what is already
there and coming up with good examples for tests that actually cover
the different branches of the code.

--
Oscar

On Sun, 17 Mar 2019 at 14:25, rituraj singh  wrote:
>
> Hello, Everyone
> Myself Ritu Raj Singh, sophomore of IIT BHU Varanasi.( GitHub profile)
>
> I would like to work on the implementation of ODE's solution this summer in 
> my GSoC.
>
> Currently, SymPy only supports many basic types of differential equations, 
> but there are plenty of methods that are not implemented.
>
> Separation ansatz:
>
> "A simple method to find out when an ordinary differential equation is 
> separable" by José ́Ángel Cid( currently working on this with the help of 
> smichr )
>
> "Solving Differential Equations in Terms of Bessel Functions" by Ruben 
> Debeerst.
>
> Webpage: http://rubendebeerst.de/master/
> Master Thesis: http://rubendebeerst.de/master/master.pdf
> Corresponding ISSAC 08 paper: 
> http://rubendebeerst.de/master/paper_issac2008.pdf.
>
> Lie groups and symmetry-related:
>
> An implementation of these methods was done for first order ODEs during 
> gsoc13. But we can do the same tricks for second order ODEs too.
> "Computer Algebra Solving of First Order ODEs Using Symmetry Methods" by E.S. 
> Cheb-Terrab, L.G.S. Duarte and L.A.C.P. da Mota. There is a short (15 pages) 
> and an updated (24 pages) version of this paper.
> "Computer Algebra Solving of Second Order ODEs Using Symmetry Methods" by 
> E.S. Cheb-Terrab, L.G.S. Duarte, L.A.C.P. da Mota
> "Integrating factors for second order ODEs" by E.S. Cheb-Terrab and A.D. Roche
> "Symmetries and First Order ODE Patterns" by E.S. Cheb-Terrab and A.D. Roche
> "Abel ODEs: Equivalence and Integrable Classes" by E.S. Cheb-Terrab and A.D. 
> Roche Note: Original version (12 pages): July 1999. Revised version (31 
> pages): January 2000
> "First order ODEs, Symmetries, and Linear Transformations" by E.S. 
> Cheb-Terrab and T. Kolokolnikov
> "Non-Liouvillian solutions for second order linear ODEs" by L. Chan, E.S. 
> Cheb-Terrab.
>
> So I would like to work to complete these tasks.
>
> --
> 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/c6fa99ef-15ed-49e4-9d74-4cfed8d41ebf%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/CAHVvXxQ-7AYFYdix38CtCxORRR8vz5hh1hQ-82ZL_6u9446CTQ%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]

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.
>>
>>
>>
>> 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 
>> 

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] Introduction and a question

[Oscar Benjamin]

There probably is a better way of doing this in your problem but I
just want to point out a way to "manually" extract parts of an
expression. Let's create an expression with a few parts:

In [1]: a, b, c, x = symbols('a b c x')

In [2]: p = a*x**2 + b*x + c

In [3]: r1, r2 = solve(p, x)

In [4]: r1
Out[4]:
_
   ╱   2
-b + ╲╱  -4⋅a⋅c + b
─
 2⋅a

Okay now suppose I want to get the discriminant out from inside the
square root and do something with it. I can use the .args attribute of
each sympy expression to drill down to the part I want like this:

In [5]: r1.args
Out[5]:
⎛_⎞
⎜ 1 ╱   2 ⎟
⎜1/2, ─, -b + ╲╱  -4⋅a⋅c + b  ⎟
⎝ a   ⎠

In [6]: r1.args[2]
Out[6]:
_
   ╱   2
-b + ╲╱  -4⋅a⋅c + b

In [7]: r1.args[2].args
Out[7]:
⎛   _⎞
⎜  ╱   2 ⎟
⎝╲╱  -4⋅a⋅c + b  , -b⎠

In [8]: r1.args[2].args[0]
Out[8]:
   _
  ╱   2
╲╱  -4⋅a⋅c + b

In [9]: r1.args[2].args[0].args
Out[9]:
⎛  2 ⎞
⎝-4⋅a⋅c + b , 1/2⎠

In [10]: r1.args[2].args[0].args[0]
Out[10]:
  2
-4⋅a⋅c + b


On Sun, 10 Mar 2019 at 16:01, Mark Juers  wrote:
>
> In my real problem, d is an arbitrarily complex expression I'd rather not 
> type out in full, and the factored part is inside a subexpression, so I'm not 
> sure I could get this to work.
>
> --
> 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/1b8b1b7e-22ea-4ae9-9338-f0829e2341b2%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/CAHVvXxQXVeRBKgStk_NcJdKujYRZgV_rXV-t3AC9gnrnJynohg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] End user question - usage on Ubuntu with PyPy

[Oscar Benjamin]

I generally use virtual environments to test development versions of
Python libraries. Within the virtual environment you can install the
library using pip install -e.

Create and activate virtualenv:

enojb@IT035770:~/current/tmp$ mkdir pypydemo
enojb@IT035770:~/current/tmp$ cd pypydemo/
enojb@IT035770:~/current/tmp/pypydemo$ pypy -m virtualenv mypypyenv
...
enojb@IT035770:~/current/tmp/pypydemo$ . mypypyenv/bin/activate

Clone and install sympy as "editable":

(mypypyenv) enojb@IT035770:~/current/tmp/pypydemo$ git clone
https://github.com/sympy/sympy.git
...
(mypypyenv) enojb@IT035770:~/current/tmp/pypydemo$ cd sympy/
(mypypyenv) enojb@IT035770:~/current/tmp/pypydemo/sympy$ pip install -e .
...
(mypypyenv) enojb@IT035770:~/current/tmp/pypydemo/sympy$ cd ..

Test and run:

(mypypyenv) enojb@IT035770:~/current/tmp/pypydemo$ isympy
Couldn't locate IPython. Having IPython installed is greatly recommended.
See http://ipython.scipy.org for more details. If you use Debian/Ubuntu,

just install the 'ipython' package and start isympy again.

Python console for SymPy 1.4.dev (Python 2.7.13-64-bit) (ground types: python)
These commands were executed:
>>> from __future__ import division
>>> from sympy import *
>>> x, y, z, t = symbols('x y z t')
>>> k, m, n = symbols('k m n', integer=True)
>>> f, g, h = symbols('f g h', cls=Function)
>>> init_printing()
Documentation can be found at https://docs.sympy.org/dev
Python 2.7.13 (ab0b9caf307db6592905a80b8faffd69b39005b8, Jun 24 2018, 08:19:27)
[PyPy 6.0.0 with GCC 4.2.1 Compatible Apple LLVM 9.1.0
(clang-902.0.39.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
(SymPyConsole)
>>> from sympy import __version__
>>> __version__
1.4.dev

Having set this up in future you only need to activate the virtualenv.
Changing branches with git will automatically update the code used for
"sympy" in the virtualenv.

--
Oscar


On Sun, 10 Mar 2019 at 23:32, Rathmann  wrote:
>
> When I was using a development repository and wanted to test with PyPy, I 
> wrote a little bash function that would set PYTHONPATH to include whatever 
> repository I was interested in, and then call PyPy.  That way I didn't need 
> to change my environment, and could easily switch from tree to tree.
>
> Now, on one of my Ubuntu installs, I don't have any of the Git tools, but 
> just installed Sympy from the regular Ubuntu channel using Synaptic.   
> (Ubuntu 18.10 currently has version 1.2, so not quite up to date, but very 
> functional.)Works nicely, and integrates with Jupyter notebook, etc.
>
> But, if I want to use PyPy, it doesn't see the Sympy install.  (This is a 
> generic PyPy / debian issue, I think.  PyPy doesn't seem to find any of the 
> extra packages that you install.)
>
> Have other people in the community taken the Ubuntu install route?  Is there 
> a reasonable technique for dealing with this situation?   I suppose I could 
> use the PYTHONPATH=... trick, but was wondering if there was a more easily 
> maintainable approach?
>
> I know I could use Anaconda or pip, but as a general rule like to use the 
> Ubuntu repositories where they are available.   I figure it it is easier to 
> administer a machine if all my packages are installed/updated with the same 
> tools.
>
> If there is a good solution, AND there is a consensus that it is worth 
> documenting, I volunteer to add it to the "Other methods" paragraph of the 
> installation section of the docs.
>
> Thanks.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sympy+unsubscr...@googlegroups.com.
> To 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/c98b85f1-042b-41c8-b819-afe53318b6fb%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/CAHVvXxRs1%3D5GrMdmi8%2BzE%3DXz3F%2BF%2BJhsPUO37FSS4STX1WzMBg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Can sympy solve (1. - (x ** n)) ** (1/n) = y , and similar?

[Oscar Benjamin]

On Fri, 8 Mar 2019 at 17:25, Stuart Reynolds  wrote:
>
> Dear Sympy users,
>
> I'm new to sympy and interested in using it for function design.
> I'm curious about what types of things I should be able to expected 
> sympy.solve to solve. In particular, trying to solve:
> (1. - (x ** 2)) ** (1. / 2) = 1/2
> seems to fail for me:

You can solve it like this using rational or floats:

In [9]: solve(Eq((1-(x**2))**(S(1)/2), S(1)/2), x)

Out[9]:

⎡-√3   √3⎤

⎢, ──⎥

⎣ 22 ⎦


In [10]: solve(Eq((1.0-(x**2))**0.5, 0.5), x)

Out[10]: [-0.866025403784439, 0.866025403784439]

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

Re: [sympy] Introduction and a question

[Oscar Benjamin]

I'm not sure if this would work for your real problem but for this
example you can do:

In [8]: factor(test-d)+d
Out[8]: d - (a - b)⋅(c - 1)

On Sun, 10 Mar 2019 at 07:56, Mark Juers  wrote:
>
> I'm a 4th-year PhD student in evolutionary biology at Indiana University in 
> Bloomington, IN. I've been using Python for about a year for various biology 
> projects and am working on a package related to my dissertation work.  I am 
> looking to replace Mathematica with SymPy in my workflow. I use Git and 
> Github for my research projects and for personal projects, dotfiles, etc. as 
> well.
>
> Now for my question. Suppose I have an expression like the following:
>
> from sympy import *
> var('a:d')
> w = Wild('w')
> test = a * (1 - c) + b * (c - 1) + d
>
> I'd like to rewrite test as (a - b) * (1 - c) + d
> I tried test.replace(a * w - b * w, collect(a * w - b * w, w)), but this does 
> not work.
>
> Many thanks in advance for your help.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sympy+unsubscr...@googlegroups.com.
> To 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/e14dd72b-ddc3-4280-93a3-faa42af092a3%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/CAHVvXxTAHh79YJG-9TF3M-nBARoqoTmtCcSNE7KBA3MwXGn77w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Help regarding location of labels of bugs

[Oscar Benjamin]

Unfortunately only "members" (those with merge access) can change the
labels on issues/PRs. I think that's just how Github works and cannot
be changed by us.

SymPy has used Easy-to-fix for some time but I note that Github now
suggests Good-first-issue in its hints. Rishik do you think that is a
better label to use?

I have seen a few cases where first time contributors have suggested
that "easy to fix" was misleading since they clearly did not find it
easy.

On Thu, 14 Feb 2019 at 06:39, Aaron Meurer  wrote:
>
> On the issues page you can click "labels" at the top.
>
> Here is the easy to fix label
> https://github.com/sympy/sympy/issues?q=is%3Aissue+is%3Aopen+label%3A"Easy+to+Fix;
>
> Aaron Meurer
>
> On Wed, Feb 13, 2019 at 10:50 PM  wrote:
> >
> > Hello I am Rishik and I am a beginner in open source so I would like to fix 
> > the bug of renaming the bug---"Easy-to-fix" to "good-first-issue".Please 
> > help me to find the location of labels file in your 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 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/b3f19a39-5287-4ede-9642-e2892256b468%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%3D6LjftBP6cAyuuAA4RzB4um75ZLEME6Od0jCcgSZX98eOw%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/CAHVvXxTOX%2BH%2BzvxYCAUs%2BRJg6fW60af-7mAPhP-wx6vE5%2Bbxhg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Start Contribution

[Oscar Benjamin]

Hi Vishesh,

Since you mentioned your experience with differential equations maybe
you would be interested in this issue (that I just opened):
https://github.com/sympy/sympy/issues/15881

If you have questions about it then probably best to ask on the issue.

On Mon, 28 Jan 2019 at 22:31, Vishesh Mangla  wrote:
>
> Hello everyone,
> My name is Vishesh Mangla, 2nd year student at Bits Pilani,Rajasthan,India 
> pursuing Msc.Chemistry + B Sc. Chemical Engineering (Duel Degree). I have 
> learned python from online sources and then I started solving problems on 
> Project Euler(Username : teutranian).I solved around 120 questions(took 
> around 3 months) but then realized it was not leading me anywhere. So,now I 
> would want to use whatever maths I know to produce a real product which can 
> be used by someone.But I haven't done anything in the open source world yet. 
> Being quite interested in maths(a lot more than chemistry) I would like to 
> start contributing to sympy and at least post a proposal for GSOC '19 this 
> year.I know maths and 'm willing to learn more of it.I am not a regular user 
> of Sympy but had computational chemistry and solving ODE's(using 
> laplace,bessel etc) as a math couse course last year which required solving 
> equation,determinants etc. by hand not computer but I used that as an 
> opportunity to work with a library of python ie Sympy to verify answers while 
> practicing. I looked at the easy bugs page but couldn't see if the bug was 
> unsolved or needs to be solved since in the comments there lead a link to 
> where in that conversation the bug seemed to be repaired.Please help!
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sympy+unsubscr...@googlegroups.com.
> To 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/81e17853-6872-45dc-82cb-3b50717d4322%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/CAHVvXxQQABG9SxwqjLJ0e%3D3WKLOLwLh0eGF1j00fTZ7Ca-FMuw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] rounding difference between Python 3 and SymPy

[Oscar Benjamin]

The fact that the numbers are stored in binary is significant:

In [16]: nums = [eval('1.%d5' % n) for n in range(10)]

In [17]: nums
Out[17]: [1.05, 1.15, 1.25, 1.35, 1.45, 1.55, 1.65, 1.75, 1.85, 1.95]

In [18]: [round(n, 1) for n in nums]
Out[18]: [1.1, 1.1, 1.2, 1.4, 1.4, 1.6, 1.6, 1.8, 1.9, 1.9]

Proper decimal rounding might look like:

In [20]: from decimal import Decimal

In [21]: nums = [Decimal('1.%d5' % n) for n in range(10)]

In [22]: nums
Out[22]:
[Decimal('1.05'),
 Decimal('1.15'),
 Decimal('1.25'),
 Decimal('1.35'),
 Decimal('1.45'),
 Decimal('1.55'),
 Decimal('1.65'),
 Decimal('1.75'),
 Decimal('1.85'),
 Decimal('1.95')

In [23]: [round(n, 1) for n in nums]
Out[23]:
[Decimal('1.1'),
 Decimal('1.2'),
 Decimal('1.3'),
 Decimal('1.4'),
 Decimal('1.5'),
 Decimal('1.6'),
 Decimal('1.7'),
 Decimal('1.8'),
 Decimal('1.9'),
 Decimal('2.0')]

Or with half-even rounding:

In [24]: from decimal import getcontext

In [25]: getcontext().rounding = 'ROUND_HALF_EVEN'

In [26]: [round(n, 1) for n in nums]
Out[26]:
[Decimal('1.0'),
 Decimal('1.2'),
 Decimal('1.2'),
 Decimal('1.4'),
 Decimal('1.4'),
 Decimal('1.6'),
 Decimal('1.6'),
 Decimal('1.8'),
 Decimal('1.8'),
 Decimal('2.0')]

The binary floats don't work out correct because some are above and
some are below the number suggested by the original float literal.

On Thu, 11 Apr 2019 at 02:03, Chris Smith  wrote:
>
> That floats are stored in binary is an implementation detail which need not 
> prevent base-10 rounding to still work. The 2nd argument to round is intended 
> to tell at which base-10 digit the rounding is to take place. By shifting 
> that digit to the ones position and then doing the rounding one can easily 
> detect whether what follows is above or below a half.
>
> >>> .345.as_integer_ratio()
> (1553741871442821, 4503599627370496)
> >>> (_*100).as_integer_ratio()
> (69, 2)
>
> "round to even" means "if what follows the digit to which you are rounding is 
> 5 then round so your digit is even". As is shown in the integer ratios above, 
> what follows the 4 is exactly 1/2 so we can round to the even 4 (as in .34) 
> instead of the odd 5 (as in .35) just like round(0.75,1) rounds to 0.8 while 
> round(0.25) rounds to 0.2.
>
> On Wednesday, April 10, 2019 at 7:29:18 PM UTC-5, Aaron Meurer wrote:
>>
>> Doesn't Python do rounding based on the binary representation of the float?
>>
>> I'm a little confused what "round to even" means in that case.
>>
>> Aaron Meurer
>>
>> On Wed, Apr 10, 2019 at 6:16 PM Chris Smith  wrote:
>> >
>> > Python 3 implements "round to even on tie" logic so `round(12.5)` -> 12,  
>> > not 13. I have updated, in #16608, the round function but there is a 
>> > difference in how ties are detected. I shift the desired position to the 
>> > ones position and then check for a tie so 12.345 is shifted to 1234.5 and 
>> > rounded to 1234 then is divided by 100 to give 12.34. Python doesn't do 
>> > this. I suspect it adds 0.05 and then detects that12.395 > 12395/1000 and 
>> > rounds up to 12.35
>> >
>> >
>> > >>> Rational(*.345.as_integer_ratio())-Rational(345,1000)  # .345 < 
>> > >>> 345/1000
>> > -3/112589990684262400
>> > >>> Rational(*.395.as_integer_ratio())-Rational(395,1000)  # .395 > 
>> > >>> 395/1000
>> > 1/56294995342131200
>> >
>> >
>> > >>> round(12.345,2)  # 12.345 rounds up b/c a tie is not detected
>> > 12.35
>> >
>> >
>> >
>> > Does anyone have objections to the proposed rounding?
>> >
>> > /c
>> >
>> > --
>> > 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 sy...@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/a84085c6-aa90-437c-b063-a87f909beac4%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/7873bfe6-6f91-4d39-af6f-9f4039714fa8%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 

Re: [sympy] rounding difference between Python 3 and SymPy

[Oscar Benjamin]

I think that Python's float.__round__ is correct. AIUI it rounds
correctly based on the true value represented by the float:

In [4]: round(1.05, 1)
Out[4]: 1.1

In [5]: import decimal

In [6]: decimal.Decimal(1.1)
Out[6]: Decimal('1.100088817841970012523233890533447265625')

That's surprising just because the true exact value isn't what we
thought it should be. There is a rounding error but it happens in the
literal 1.1 that doesn't give us the float we think it should. It's
extra confusing because str(1.1) gives '1.1' making it seem like the
exact number we requested. The behaviour of round is mathematically
correct here though given the input received: it is computing the true
exact result correctly rounded (where "correctly rounded" refers to
the decimal to binary rounding at the end).

For decimals that can be exactly represented in binary the results are
as we would intuitively expect:

In [7]: round(1.25, 1)
Out[7]: 1.2

In [8]: round(1.75, 1)
Out[8]: 1.8

(Of course 1.2 and 1.8 are not exactly representable in binary
floating point but we have the floats that result from correctly
rounding the true numbers 1.2 and 1.8.)

--
Oscar

On Thu, 11 Apr 2019 at 05:29, Chris Smith  wrote:
>
> I am aware of how the numbers are stored but was overly optimistic that the 
> shift could resolve this in all cases. It can't (and thanks for the 
> correction).
> But my suggested alternative makes a significant difference in how often the 
> problem arises:
>
> >>> bad=[]
> >>> for i in range(1,1000):
> ...  n = str(i)+'5'
> ...  if int(str(round(int(n)/10**len(n),len(n)-1))[-1])%2!=0:bad.append(i)  # 
> e.g. round(0.1235, 3)
> ...
> >>> len(bad)
> 546
>
>
> >>> bad=[]
> >>> for i in range(1,1000):
> ...  n = str(i)+'5'
> ...  if round(int(n)/10**len(n)*10**(len(n)-1))%2!=0:bad.append(i)  # e.g. 
> round(0.1235*1000)
> ...
> >>> len(bad)
> 8
> >>> bad  # e.g. 0.545*100 != 54.5
> [54, 57, 501, 503, 505, 507, 509, 511]
>
>> So the question is whether we want to do better and keep the SymPy algorithm.
>
> --
> 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/b50c0504-ec96-4583-84b1-d5a3902277c2%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/CAHVvXxS8kCZRXuXpoHJCWiXOZUjxeAMhY%3DRQPthEKkA_A_tdCQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] ArrayComprehension or List

[Oscar Benjamin]

In normal Python the main purpose of list is to be mutable. When you
want an immutable list you can use tuple.

If SymPy had List would it be mutable? If so then it couldn't be a
Basic subclass. If not what purpose would it serve?

On Tue, 4 Jun 2019 at 04:46, Chris Smith  wrote:
>
> From discussion at #16926 where I suggest that perhaps we should be naming 
> ArrayComprehension as List and it was said,
>
> > [ArrayComprehension] is supposed to be a multidimensional list comprehension
>
> It looks like an unevaluated List to me: `List(i + j, (i,0,3), (j,0,4))` is 
> the unevaluated form of `[i + j for i in range(4) for j in range(5)]`. (For 
> comparison, Integral and Sum are examples of an unevaluated Expr, which, 
> after a doit and the right conditions, lose the wrapper and become other 
> Expr.)
>
> An evaluated form would be `List([1, 2, 3, 4])` where the `[]` would be 
> necessary to distinguish between the evaluated and comprehension form.
>
> Are we going to regret introducing an object that is so closely related to a 
> list or will we always want a list to be an unsympified object in SymPy?
>
> /c
>
> --
> 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/f98dd475-7c90-4d3f-827e-f14480272693%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/CAHVvXxQkrpKeZKboUQdvZ%3Dd3HQ_U2BOht_9VfSP1pszhWKxQ1Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Prevent expression evaluation in repr()/latex()

[Oscar Benjamin]

Hi Jean,

What version of SymPy are you using?

This seems to work fine on SymPy master and with the most recent version (1.4):

In [1]: repr(Mul(-1, 2, 5, evaluate=False))
Out[1]: '-2*5'

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

Re: [sympy] f`(0)

[Oscar Benjamin]

Yeah, it would be nice to be able to do that. Unfortunately SymPy has
no notion of the derivative of an unapplied function. I'd like to have
a differential operator so you could do something like `D(sin) == cos`
etc. I believe there are some long-standing issues on Github about
this.

--
Oscar

On Tue, 4 Jun 2019 at 18:44, David Bailey  wrote:
>
> The ability to expand an expression containing unknown functions, about some 
> point, is obviously very valuable, and it is nice that this is possible using 
> SymPy, however if I expand f(x) about 0 I get this:
>
> f(0) + x*Subs(Derivative(f(_x), _x), _x, 0) + x**2*Subs(Derivative(f(_x), 
> (_x, 2)), _x, 0)/2 + O(x**3)
>
> Is there any way to reduce that to something neater and more like textbook 
> maths such as
>
> f(0)+x*f`(0)+x**2*f```(0)/2 + O(x**3)
>
> I chose f` rather than f' because as far as I know, the '`' character is not 
> used in Python.
>
> Outputting the expression as Latex cleans it up a bit, but it is still not as 
> neat as the usual notation for the derivative of a function notation.
>
> 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 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/5bca2aa1-8b2b-4a3f-af18-6f9a42dc87cd%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/CAHVvXxQ-7iEgovJtmqaNm_5rudpwc2vdMObYkRqV71u5PhjFSg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Problem in solving non linear equation equation

[Oscar Benjamin]

SymPy will find the solution eventually I think.

This is a polynomial of order 8 having only even powers so with a
substitution omega**2 -> x it's a quartic in x with complicated
symbolic coefficients. The general formula for a quartic is horrendous
and in this case your coefficients are already large expressions.

What this means is that the solution will take a while to compute and
will probably be too complicated to be useful when done anyway. Really
complicated analytic expressions can be difficult to use without
substituting numeric values in and it's much easier to find the roots
if you substitute the numbers in first.

I'm not sure why it is so slow though. You can get to the solutions
for omega^2 like this:

In [39]: coeffs = Poly(omega_nf_eq.rhs.subs(omega, sqrt(x)),
x).coeffs()

In [40]: a, b, c, d, e = symbols('a, b, c, d, e')

In [41]: p = Poly(a*x**4+b*x**3+c*x**2+d*x+e, x)

In [42]: rs = solve(p, x)

Print the first root:

In [43]: rs[0].subs(zip((a,b,c,d,e), coeffs))

(output omitted as it's long and complicated)


My suggestion is to consider why you need the solutions to this
equation. There may be a better way to reach your actual end goal then
getting the solutions in explicit analytic form.

--
Oscar

On Fri, 7 Jun 2019 at 00:13, pull_over93  wrote:
>
> Hi everybody, I'm tring to solve this equation without succes: omega_nf_eq = 0
>
> import sympy as sym
> m,J_d,J_p,y,Y,omega,Omega,phi,Phi,z,Z,theta,Theta,k_yy,k_zz,k_phiphi,k_yphi,k_ztheta,k_thetatheta,plane_xy1,plane_xy2,plane_xz1,plane_xz2
>  = 
> sym.symbols('m,J_d,J_p,y,Y,omega,Omega,phi,Phi,z,Z,theta,Theta,k_yy,k_zz,k_phiphi,k_yphi,k_ztheta,k_thetatheta,plane_xy1,plane_xy2,plane_xz1,plane_xz2',
>  real  = True)
> t, omega_nf = sym.symbols('t, omega_nf', real = True)
>
> omega_nf_eq = sym.Eq(omega_nf, -J_d**2*k_yy*k_zz*omega**4 + 
> 0.382*J_d**2*k_yy*omega**6 + 0.382*J_d**2*k_zz*omega**6 - 
> 0.145924*J_d**2*omega**8 + J_d*k_phiphi*k_yy*k_zz*omega**2 - 
> 0.382*J_d*k_phiphi*k_yy*omega**4 - 0.382*J_d*k_phiphi*k_zz*omega**4 + 
> 0.145924*J_d*k_phiphi*omega**6 + J_d*k_thetatheta*k_yy*k_zz*omega**2 - 
> 0.382*J_d*k_thetatheta*k_yy*omega**4 - 0.382*J_d*k_thetatheta*k_zz*omega**4 + 
> 0.145924*J_d*k_thetatheta*omega**6 - J_d*k_yphi**2*k_zz*omega**2 + 
> 0.382*J_d*k_yphi**2*omega**4 - J_d*k_yy*k_ztheta**2*omega**2 + 
> 0.382*J_d*k_ztheta**2*omega**4 + J_p**2*Omega**2*k_yy*k_zz*omega**2 - 
> 0.382*J_p**2*Omega**2*k_yy*omega**4 - 0.382*J_p**2*Omega**2*k_zz*omega**4 + 
> 0.145924*J_p**2*Omega**2*omega**6 - k_phiphi*k_thetatheta*k_yy*k_zz + 
> 0.382*k_phiphi*k_thetatheta*k_yy*omega**2 + 
> 0.382*k_phiphi*k_thetatheta*k_zz*omega**2 - 
> 0.145924*k_phiphi*k_thetatheta*omega**4 + k_phiphi*k_yy*k_ztheta**2 - 
> 0.382*k_phiphi*k_ztheta**2*omega**2 + k_thetatheta*k_yphi**2*k_zz - 
> 0.382*k_thetatheta*k_yphi**2*omega**2 - k_yphi**2*k_ztheta**2)
>
> solution = sym.solve(omega_nf_eq.rhs, omega, dict = True , force=True, 
> manual=True, set=True)
>
> Even after half an hour, sympy is unable to give a solution.
> I also tried sage math, but I had the same failure.
> Suggestions?
>
> --
> 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/a4ebc67b-3e40-448b-b6a3-5500f6b9dab3%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/CAHVvXxSfe3rvn9V38YkJ%3DsZgnmeN1bFpu6j5wV0f%3DhBmbWtsWg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Concatenate Matrix

[Oscar Benjamin]

Hi Lucy,

The point of a block-matrix is that it is composed of smaller matrices
that we keep as whole objects. If you want to flatten this to an
explicit matrix you can use as_explicit:

In [6]: sym.BlockMatrix([[a], [phi], [theta]]).as_explicit()
Out[6]:
⎡ 0 ⎤
⎢   ⎥
⎢ 0 ⎥
⎢   ⎥
⎢ 0 ⎥
⎢   ⎥
⎢φ₀₀⎥
⎢   ⎥
⎢φ₁₀⎥
⎢   ⎥
⎢φ₂₀⎥
⎢   ⎥
⎢θ₀₀⎥
⎢   ⎥
⎢θ₁₀⎥
⎢   ⎥
⎢θ₂₀⎥
⎢   ⎥
⎢θ₃₀⎥
⎢   ⎥
⎣θ₄₀⎦

Your calculations should come out correctly with or without flattening
though e.g.:

In [7]: A = MatrixSymbol('A', 2, 2)

In [8]: B = MatrixSymbol('B', 2, 2)

In [9]: A
Out[9]: A

In [10]: A.as_explicit()
Out[10]:
⎡A₀₀  A₀₁⎤
⎢⎥
⎣A₁₀  A₁₁⎦

In [11]: A*B
Out[11]: A⋅B

In [12]: (A*B).as_explicit()
Out[12]:
⎡A₀₀⋅B₀₀ + A₀₁⋅B₁₀  A₀₀⋅B₀₁ + A₀₁⋅B₁₁⎤
⎢⎥
⎣A₁₀⋅B₀₀ + A₁₁⋅B₁₀  A₁₀⋅B₀₁ + A₁₁⋅B₁₁⎦

In [13]: A.as_explicit() * B.as_explicit()
Out[13]:
⎡A₀₀⋅B₀₀ + A₀₁⋅B₁₀  A₀₀⋅B₀₁ + A₀₁⋅B₁₁⎤
⎢⎥
⎣A₁₀⋅B₀₀ + A₁₁⋅B₁₀  A₁₀⋅B₀₁ + A₁₁⋅B₁₁⎦

--
Oscar

On Wed, 19 Jun 2019 at 17:39, Lucy Jackson  wrote:
>
> Hi Oscar,
>
> I am using version 1.3.
>
> The introduction of the extra [] brackets now makes the shape 11,1. However, 
> when the variable is viewed it is as follows:
>
> Matrix([
> [Matrix([
> [0],
> [0],
> [0]])],
> [ phi],
> [   theta]])
>
>
> What I really want is a single matrix with:
> Matrix([[0]
> [0]
> [0]
> phi[0,0]
> phi[1,0]
> phi[2,0]
> theta[0.0]
> theta[1,0]
> theta[2,0]
> theta[3,0]
> theta[4,0] ])
>
> Is this how sympy has stored it even though it does not display it like this?
>
> Thanks,
>
> Lucy
>
> On Wed, 19 Jun 2019 at 16:51, Oscar Benjamin  
> wrote:
>>
>> Hi Lucy,
>>
>> Running on master I get this:
>>
>> In [13]: sym.BlockMatrix([[a], [phi], [theta]])
>> Out[13]:
>> ⎡⎡0⎤⎤
>> ⎢⎢ ⎥⎥
>> ⎢⎢0⎥⎥
>> ⎢⎢ ⎥⎥
>> ⎢⎣0⎦⎥
>> ⎢   ⎥
>> ⎢ φ ⎥
>> ⎢   ⎥
>> ⎣ θ ⎦
>>
>> In [14]: sym.BlockMatrix([[a], [phi], [theta]]).shape
>> Out[14]: (11, 1)
>>
>> Note that I've used extra square brackets to indicate that I want
>> these combined column-wise. Without those I get:
>>
>> In [11]: sym.BlockMatrix([a, phi, theta])
>> Out[11]:
>> ⎡⎡0⎤  ⎤
>> ⎢⎢ ⎥  ⎥
>> ⎢⎢0⎥  φ  θ⎥
>> ⎢⎢ ⎥  ⎥
>> ⎣⎣0⎦  ⎦
>>
>> In [12]: sym.BlockMatrix([a, phi, theta]).shape
>> Out[12]: (3, 3)
>>
>> It's unfortunate that the sizes aren't checked there since those are
>> inconsistent.
>>
>> It looks like the main problem you're having is fixed in master. What
>> version of SymPy are you using?
>>
>>
>> --
>> Oscar
>>
>> On Wed, 19 Jun 2019 at 15:15, Lucy Jackson  
>> wrote:
>> >
>> > Hi,
>> >
>> > I am looking to concatenate three matrices (shown below) using 
>> > BlockMatrix, however, the output has the wrong dimensions.
>> >
>> > theta = sym.MatrixSymbol('theta', 5, 1)
>> > phi = sym.MatrixSymbol('phi', 3, 1)
>> > a = sym.Matrix([[0],[0],[0]])
>> >
>> > X = sym.BlockMatrix([a, phi, theta])
>> >
>> > With this code I get the following output:
>> >
>> >  X = Matrix([
>> >
>> > [  0],
>> > [  0],
>> > [  0],
>> > [  phi[0, 0]],
>> > [theta[0, 0]]])
>> >
>> >
>> > However, I am expecting an output thats 11 x 1. I am also unable to check 
>> > the shape of X as X.shape yields the following error:
>> >
>> >
>> > AttributeError: 'Zero' object has no attribute 'shape'
>> >
>> >
>> > Any help would be greatly appreciated!
>> >
>> >
>> > Many Thanks,
>> >
>> >
>> > Lucy
>> >
>> >
>> >
>> > --
>> > 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/76c6868d-b014-4b87-a514-f60a574ad7bd%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 unsubsc

Re: [sympy] Concatenate Matrix

[Oscar Benjamin]

Hi Lucy,

Running on master I get this:

In [13]: sym.BlockMatrix([[a], [phi], [theta]])
Out[13]:
⎡⎡0⎤⎤
⎢⎢ ⎥⎥
⎢⎢0⎥⎥
⎢⎢ ⎥⎥
⎢⎣0⎦⎥
⎢   ⎥
⎢ φ ⎥
⎢   ⎥
⎣ θ ⎦

In [14]: sym.BlockMatrix([[a], [phi], [theta]]).shape
Out[14]: (11, 1)

Note that I've used extra square brackets to indicate that I want
these combined column-wise. Without those I get:

In [11]: sym.BlockMatrix([a, phi, theta])
Out[11]:
⎡⎡0⎤  ⎤
⎢⎢ ⎥  ⎥
⎢⎢0⎥  φ  θ⎥
⎢⎢ ⎥  ⎥
⎣⎣0⎦  ⎦

In [12]: sym.BlockMatrix([a, phi, theta]).shape
Out[12]: (3, 3)

It's unfortunate that the sizes aren't checked there since those are
inconsistent.

It looks like the main problem you're having is fixed in master. What
version of SymPy are you using?


--
Oscar

On Wed, 19 Jun 2019 at 15:15, Lucy Jackson  wrote:
>
> Hi,
>
> I am looking to concatenate three matrices (shown below) using BlockMatrix, 
> however, the output has the wrong dimensions.
>
> theta = sym.MatrixSymbol('theta', 5, 1)
> phi = sym.MatrixSymbol('phi', 3, 1)
> a = sym.Matrix([[0],[0],[0]])
>
> X = sym.BlockMatrix([a, phi, theta])
>
> With this code I get the following output:
>
>  X = Matrix([
>
> [  0],
> [  0],
> [  0],
> [  phi[0, 0]],
> [theta[0, 0]]])
>
>
> However, I am expecting an output thats 11 x 1. I am also unable to check the 
> shape of X as X.shape yields the following error:
>
>
> AttributeError: 'Zero' object has no attribute 'shape'
>
>
> Any help would be greatly appreciated!
>
>
> Many Thanks,
>
>
> Lucy
>
>
>
> --
> 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/76c6868d-b014-4b87-a514-f60a574ad7bd%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/CAHVvXxT3Tzw44EEt7JjbsKaBfNwNONBGNJ%2BbYEmjFuHFCrdgcw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[sympy] Using the mechanics API

[Oscar Benjamin]

Hi all,

I haven't really looked much at SymPy's mechanics module even though
mechanics is very much one of my interests and something that I like
to think I know a bit about. Today I finally took a look at it and I
found the whole API surprisingly complicated. I teach mechanics to
undergraduate students but I'm not sure if I would know how to teach
my students to use the mechanics module as it is now...

Firstly I looked through the documentation here:
https://docs.sympy.org/latest/modules/physics/mechanics/index.html
Is there any other guide/documentation that explains the general ideas
more simply with examples?

Suppose that I want to think about a simple 2D problem with a disc
rolling down a surface inclined at angle beta with (Coulomb) friction
coefficient mu. I want to know when/whether the disc will stick or
slip and get the equations of motion for each case. How would I go
about doing that using the mechanics module?

--
Oscar

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+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/CAHVvXxQXtAd_HGwTqaKrpDqQC_mNcyZAFgPrVe8Sq_hPwT6H0w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Using the mechanics API

[Oscar Benjamin]

Thanks Jason. Those links helped.

I guess if the module is not intended for simpler problems then that
makes sense. I would say though that the documentation could benefit
from more of a tutorial somewhere.

I'll try to use it for a real problem at some point and then see what I think...

--
Oscar

On Tue, 14 May 2019 at 18:32, Jason Moore  wrote:
>
> Oscar,
>
> Also a specific answer to:
>
> > Suppose that I want to think about a simple 2D problem with a disc
> rolling down a surface inclined at angle beta with (Coulomb) friction
> coefficient mu. I want to know when/whether the disc will stick or
> slip and get the equations of motion for each case. How would I go
> about doing that using the mechanics module?
>
> This is way too simple of a problem to really use the mechanics module for. 
> If I were teaching this I would just use the base sympy features to do the 
> math. The mechanics module is not really geared towards things you find in 
> introductory mechanics in physics and dynamics courses. It is geared toward 
> dynamics of multibodies, 2D and 3D. Most schools teach this at the graduate 
> level or some advanced upper level courses in engineering and physics.
>
> I have another package called "resonance" that is aligned more for 2D 
> dynamics and simulation. I do teach the students to derive equations of 
> motion symbolically with sympy and use the resonance interface to do the 
> simulation and analysis. This is here: 
> https://github.com/moorepants/resonance/
>
> Jason
> moorepants.info
> +01 530-601-9791
>
>
> On Tue, May 14, 2019 at 8:59 AM Jason Moore  wrote:
>>
>> Oscar,
>>
>> There are some rolling disc examples here: 
>> https://github.com/pydy/pydy/tree/master/examples Note that the PyDy project 
>> started as an independent thing build on top of SymPy, then the symbolics 
>> were merged into sympy as the mechanic module and the numerics are now in 
>> the standalone PyDy package.
>>
>> Also, I teach an entire graduate class using the module that include 20+ 
>> lecture videos and accompanying notebooks: 
>> https://moorepants.github.io/mae223/
>>
>> There are also several scipy/pycon tutorials on the package:
>>
>> http://www.moorepants.info/portfolio/pydy.html
>>
>> The module may be complicated, but that may just reflect that 3D multibody 
>> rigid body mechanics is complicated. We've worked on some layers on top of 
>> the core code that have been merged or are in open PRs to help provide 
>> simpler interfaces that give a way to "assemble" bodies as you would in 
>> reality (with joints, etc) but it is still not polished for production. I 
>> could imagine a layer that makes it simpler to do 2D mechanics too, among 
>> other things.
>>
>> I'll be working on things this summer because I am teaching the 
>> aforementioned course in the fall. Feel free to open issues for discussion 
>> on improvements.
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791
>>
>>
>> On Mon, May 13, 2019 at 1:42 PM Oscar Benjamin  
>> wrote:
>>>
>>> Hi all,
>>>
>>> I haven't really looked much at SymPy's mechanics module even though
>>> mechanics is very much one of my interests and something that I like
>>> to think I know a bit about. Today I finally took a look at it and I
>>> found the whole API surprisingly complicated. I teach mechanics to
>>> undergraduate students but I'm not sure if I would know how to teach
>>> my students to use the mechanics module as it is now...
>>>
>>> Firstly I looked through the documentation here:
>>> https://docs.sympy.org/latest/modules/physics/mechanics/index.html
>>> Is there any other guide/documentation that explains the general ideas
>>> more simply with examples?
>>>
>>> Suppose that I want to think about a simple 2D problem with a disc
>>> rolling down a surface inclined at angle beta with (Coulomb) friction
>>> coefficient mu. I want to know when/whether the disc will stick or
>>> slip and get the equations of motion for each case. How would I go
>>> about doing that using the mechanics module?
>>>
>>> --
>>> Oscar
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "sympy" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to sympy+unsubscr...@googlegroups.com.
>>> To post to this group, send email to sympy@googlegroups.com.
>>> Visit this group at htt

Re: [sympy] Using the mechanics API

[Oscar Benjamin]

Hi Vishesh,

I have no plans to work on anything here but of course you can feel
free to contribute. Take a look at the module and see if there is
something that you think can be improved. There's always something
that can be improved so it's just a question of finding something that
is worth doing and that you can do yourself.

--
Oscar

On Mon, 13 May 2019 at 21:48, Vishesh Mangla  wrote:
>
> Hey,I also love physics and math and would like to work on the changes which 
> you want to include.Can I get included in this?I ‘ve chemistry as my subject 
> in university but that too deals with a lot of physics Hermitian mostly but I 
> know lagrangian too.So please let me make it. If you remember you helped me 
> merge my first pull request but still one was not enough to get me enough 
> experience to get good with it and I require help to get a few more merged.
>
>
>
> Sent from Mail for Windows 10
>
>
>
> From: Oscar Benjamin
> Sent: 14 May 2019 02:12
> To: sympy
> Subject: [sympy] Using the mechanics API
>
>
>
> Hi all,
>
>
>
> I haven't really looked much at SymPy's mechanics module even though
>
> mechanics is very much one of my interests and something that I like
>
> to think I know a bit about. Today I finally took a look at it and I
>
> found the whole API surprisingly complicated. I teach mechanics to
>
> undergraduate students but I'm not sure if I would know how to teach
>
> my students to use the mechanics module as it is now...
>
>
>
> Firstly I looked through the documentation here:
>
> https://docs.sympy.org/latest/modules/physics/mechanics/index.html
>
> Is there any other guide/documentation that explains the general ideas
>
> more simply with examples?
>
>
>
> Suppose that I want to think about a simple 2D problem with a disc
>
> rolling down a surface inclined at angle beta with (Coulomb) friction
>
> coefficient mu. I want to know when/whether the disc will stick or
>
> slip and get the equations of motion for each case. How would I go
>
> about doing that using the mechanics module?
>
>
>
> --
>
> Oscar
>
>
>
> --
>
> You received this message because you are subscribed to the Google Groups 
> "sympy" group.
>
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sympy+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/CAHVvXxQXtAd_HGwTqaKrpDqQC_mNcyZAFgPrVe8Sq_hPwT6H0w%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sympy+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/5cd9d817.1c69fb81.1bcd0.8bad%40mx.google.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To 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/CAHVvXxT7kOReOW477jy-pRU1SYAQCArKdkr1QsSMGY91zth6XQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Interested in working on SymPy's quantum physics module

[Oscar Benjamin]

Hi Tilman,

It's great that you're interested in doing this!

I don't know the quantum module very well myself but it probably does
need work. As far as I know no one is really working on it right now.
A good place to start thinking about improving it would probably be
looking over the open issues:
https://github.com/sympy/sympy/issues?q=is%3Aopen+is%3Aissue+label%3Aphysics.quantum
Some of those might be easy to fix and that's a good way to get
experience contributing. In any case the issues show the problems
people have had using the module in the past which helps to think
about what is a useful improvement.

As for whether this makes a good University project that's a hard
question to answer. I'm sure it's possible to make a good project out
of this but I have no idea whether it would meet the expectations of
your University (you have to talk to them about that).

One difficulty in particular with the quantum module is that I'm not
sure if there are any active contributors who know it well. That means
that it might be difficult to get guidance with it and it might also
be hard to get your patches reviewed. On the flip side it means that
an active contributor is definitely wanted and there is the
opportunity to really take ownership of it.

Please let us know what happens after you talk to your University
about this. In any case finding a simple bug to fix is probably a good
start.

--
Oscar

On Sun, 19 May 2019 at 02:29, Tilman Roeder  wrote:
>
> Hello,
>
> My name is Tilman. Me (and a friend of mine) are interested in working on 
> extending and polishing the quantum physics module in SymPy as part of a 
> university project. We both study Physics (currently in our 2nd year) at 
> Imperial College London. The project work would be during the next academic 
> year (so from September). However, I think it would be valuable to get 
> started with some simple things to get aquatinted with the code base and 
> process (as well as allowing plenty time to read up on the relevant subjects).
>
> From looking through the documentation etc. I get the impression that the QM 
> module is currently very much a work in progress (especially the quantum 
> information/ computation bits). From what I can tell, a good thing to get 
> started on might be adding a few analytic solutions. There is one for the 
> infinite square well, but none e.g. the harmonic oscillator. Starting with 
> something very simple like this could be a really good way of getting to know 
> the process, while focussing on the code etc., before tackling something more 
> challenging.
>
> My friend and I are meeting someone in the physics department next week to 
> discuss if this kind of work would be suitable for our project, and it would 
> be really helpful to get the opinion of someone more closely involved with 
> SymPy on this matter. (Note that I am also interested in contributing, should 
> this turn out to not be suitable as part of my university work.)
>
> We are currently writing exams, but in about a month I would love to get 
> started on some simple things to get a head start on the main project work.
>
>
> TL;DR (useful pieces of information):
>
> - Interested to work on QM module
> - Good experience with Python, especially for scientific computing, as well 
> as some experience using SymPy to do hard integrals. See specifically these 
> two repos on my GitHub: https://github.com/dyedgreen/schroedinger, 
> https://github.com/dyedgreen/labs-ray-tracing
> - Experience with other languages like C, Golang, Ruby, JavaScript
> - Mathematics education level: 2nd year Theoretical Physics Undergraduate
> - I speak English and German
>
> Thanks for taking the time to read this :)
>
>
> Tilman
>
> --
> 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/cc0f0b4c-8d0e-478e-a11f-0aac972179bb%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/CAHVvXxQXMnUiRe-tr3YjM3rb6okxQ_q%2BcLL6a_F5eojYqh_yHw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] is compatibility builtins broken?

[Oscar Benjamin]

On Wed, 8 May 2019 at 22:38, Chris Smith  wrote:
>
> None of them work

That's what I get for not trying them out!

> >>> import sympy.core.compatibility.builtins as builtins
> Traceback (most recent call last):
>   File "", line 1, in 
> ImportError: No module named builtins
>
> >>> from sympy.core.compatibility.builtins import type
> Traceback (most recent call last):
>   File "", line 1, in 
> ImportError: No module named builtins

Yes that's because there is no builtins module in the compatibility
package. In fact compatibility is a module not a package.

> >>> sys.modules['builtins']=__builtin__
> Traceback (most recent call last):
>   File "", line 1, in 
> NameError: name '__builtin__' is not defined

This will work if you have imported __builtin__ first:

>>> import __builtin__
>>> import sys
>>> sys.modules['builtins'] = __builtin__
>>> import builtins

--
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/CAHVvXxQ59yzRzns5MHiqNmZz09Tx82B4aF_CnvidTwMGPA9E6Q%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]

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] Blog post about SymPy 1.4

[Oscar Benjamin]

On Thu, 2 May 2019 at 23:09, Ondřej Čertík  wrote:
>
> Once we drop Python 2.7, we should experiment with using the type annotation 
> and MyPy to statically check (eventually) the whole code base. I think this 
> will find bugs, improve the development experience and make it much easier to 
> understand from reading the code what kind of argument a function expects.

This would pick up bugs. It would also not be easy to introduce
because so many SymPy functions have inconsistent return types. I'm
not even sure what the full type spec for solve would be.

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

Re: [sympy] is compatibility builtins broken?

[Oscar Benjamin]

On Wed, 8 May 2019 at 08:23, Chris Smith  wrote:
>
> Am I doing something wrong here when running Python 2?
>
> >>> from sympy.core.compatibility import builtins
> >>> from builtins import type
> Traceback (most recent call last):
>   File "", line 1, in 
> ImportError: No module named builtins

There are two possible wrong things:

1) On Python 2 the module is called __builtin__:

>>> import __builtin__
>>> __builtin__.map


2) You've imported the name builtins so that it is available as a name
in the current global namespace. That does not mean that a subsequent
import statement will import from the resulting module object. An
import statement never looks at the names in the current namespace to
find anything. You can however do

import sympy.core.compatbility.builtins as builtins
builtins.type

Or

from sympy.core.compatibility.builtins import type

Not sure what you're aiming for but there is a hacky way to do it:

sys.modules['builtins'] = builtins

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

Re: [sympy] Grid in sympy plotting

[Oscar Benjamin]

Hi Lee,

SymPy's plotting module uses matplotlib so it is reasonable to use the
matplotlib API for adding a grid.

I just tried this and it works fine:

In [1]: plot(x**2)
Out[1]: 

In [2]: from matplotlib.pyplot import grid

In [3]: grid()

Oscar

On Wed, 26 Jun 2019 at 01:59, Lee Smith  wrote:
>
> Greetings:
>
> I want to display a grid in a sympy plot.
>
> The sympy.doc page only discusses mesh grids.
>
> On searching through Google, I found only one result that suggested using 
> matplotlib.pyplot in addition to the sympy.plot(...) method.
>
> This should be simple and I am surprised that it is not asked more.
>
> Thanks in advance,
> lee
>
> --
> 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/01a492c1-f8df-4810-b413-063f65ce4fa1%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/CAHVvXxRSY%3DJ4sLs6wfePiB921ThqpYazi8MWu88mQjMtia7iJQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Grid in sympy plotting

[Oscar Benjamin]

I guess it depends what environment you use (I used ipython). Looks like
you're using Jupyter and I'm not sure how to plotting works there.


On Thu, 27 Jun 2019 at 19:24, Lee Smith  wrote:

> Thank you !
>
> Actually I tried this and got TWO graphs.  One just the grid then the
> functions!
> Suggestions?
> [image: Sympy_grid.PNG]
>
> On Wed, Jun 26, 2019 at 3:26 AM Oscar Benjamin 
> wrote:
>
>> Hi Lee,
>>
>> SymPy's plotting module uses matplotlib so it is reasonable to use the
>> matplotlib API for adding a grid.
>>
>> I just tried this and it works fine:
>>
>> In [1]: plot(x**2)
>> Out[1]: 
>>
>> In [2]: from matplotlib.pyplot import grid
>>
>> In [3]: grid()
>>
>> Oscar
>>
>> On Wed, 26 Jun 2019 at 01:59, Lee Smith  wrote:
>> >
>> > Greetings:
>> >
>> > I want to display a grid in a sympy plot.
>> >
>> > The sympy.doc page only discusses mesh grids.
>> >
>> > On searching through Google, I found only one result that suggested
>> using matplotlib.pyplot in addition to the sympy.plot(...) method.
>> >
>> > This should be simple and I am surprised that it is not asked more.
>> >
>> > Thanks in advance,
>> > lee
>> >
>> > --
>> > 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/01a492c1-f8df-4810-b413-063f65ce4fa1%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/CAHVvXxRSY%3DJ4sLs6wfePiB921ThqpYazi8MWu88mQjMtia7iJQ%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/CAJTRwDpG6dT9ELCWcUaSP6dmTOznaFHKS6LXOmXsZY%2BpM%3D9wNw%40mail.gmail.com
> <https://groups.google.com/d/msgid/sympy/CAJTRwDpG6dT9ELCWcUaSP6dmTOznaFHKS6LXOmXsZY%2BpM%3D9wNw%40mail.gmail.com?utm_medium=email_source=footer>
> .
> 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/CAHVvXxQa5nseLq5v04U3Wz06sJnsYa9sNj_8zMPsJznSmB5mYw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Re: MatPow bug or inconsistency?

[Oscar Benjamin]

I don't have a computer to test but what happens if x is declared as an
integer? For non-integer (or non-real) x the result doesn't necessarily
hold.


On Thu, 11 Jul 2019, 19:39 Tomasz Pytel,  wrote:

> Yes, various, try it with [[0,1],[1,0]]
>
> On Thursday, July 11, 2019 at 1:30:45 PM UTC-3, Gagandeep Singh (B17CS021)
> wrote:
>>
>> Ah! I missed that.
>> Have you tried a matrix other than identity?
>
> --
> 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/def85976-42a2-4dd0-90a6-b65d7ea7b718%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/CAHVvXxQRfK3yC5yu2xgJAkBRhWfvrtO4cm4-_wbssfOhiF11Yg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Newbie: display product

[Oscar Benjamin]

Hi Gary,

I wonder if we are overcomplicating things here. Does this do what you want?

x, y = symbols('x, y')
a = x + y
b = x * y
print(a * b)

--
Oscar

On Tue, 9 Jul 2019 at 03:11, Gary Pajer  wrote:
>
> I'm sure I'm not the first person having trouble getting started.  If there 
> is a good tutorial, more detailed than the sympy docs tutorial, please point 
> me to it!
>
> I want to display the product of two expressions.  Suppose I have
>
> a, b, x, y = symbols('a b x y')
> ex1 = Eq(a, x + y)
> ex2 = Eq(b, x * y)
>
> How do I display a * b in terms of x and y?
>
> Thainks.
>
> --
> 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/2a6226b4-0928-4753-a691-a659a9035072%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/CAHVvXxSVN5f_-BNXgBda%3DWrRhbEiF9nc%2B32oCjDOT_6HGoQvwQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Newbie

[Oscar Benjamin]

Hi Tanvi,

It's great that you want to contribute!

Take a look here (I guess you already did):
https://github.com/sympy/sympy/wiki/introduction-to-contributing

Every part of SymPy can be improved in some way. You mention matrices
- there is a lot of work going on for matrices and many issues:
https://github.com/sympy/sympy/issues?utf8=%E2%9C%93=is%3Aopen+is%3Aissue+label%3Amatrices
https://github.com/sympy/sympy/issues?utf8=%E2%9C%93=is%3Aopen+is%3Aissue+label%3Amatrices.expressions

Also for calculus, are you familiar with differential equations? There
are lots of issues for those:
https://github.com/sympy/sympy/issues?utf8=%E2%9C%93=is%3Aopen+is%3Aissue+label%3Asolvers.dsolve

I would suggest to familiarise yourself with the parts of SymPy you
might want to work on and then find the easiest possible issue to work
on. You can ask on the issue to check if anyone else is working on it
and to confirm that it is easy. Some are marked "easy to fix" or "good
first issue" but sometimes those labels can be misleading...
https://github.com/sympy/sympy/issues?utf8=%E2%9C%93=is%3Aopen+is%3Aissue+label%3A%22Easy+to+Fix%22+
https://github.com/sympy/sympy/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22

--
Oscar

On Fri, 12 Jul 2019 at 10:06, Tanvi Singhal  wrote:
>
> I am Tanvi Singhal, a 4th year undergraduate from IIT Roorkee, India. I am 
> pursuing an Int. Mtech degree in Geology. I know basics of Python and I have 
> read Sympy Tutorial. I am familiar with calculus, trigonometry, Matrices and 
> I want to contribute. I found sympy perfect for Maths lovers. I would be glad 
> if you can guide me on how to proceed.
>
> --
> 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/52b74ef0-3156-4c57-9ac6-fd51f3e85ea1%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/CAHVvXxQ_ojzt5mp1nkmkUnL6W%3DgCJdopWRy2oE_tnyqjg%3DMVcA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Newbie: display product

[Oscar Benjamin]

On Sat, 13 Jul 2019 at 21:40, Gary Pajer  wrote:
>
> Oscar,
>
> That does seem to do what I want ... I think.
> What's the difference between this and Chris Smith's answer?

I think that both Chris and Gagandeep thought that you were trying to
do something more complicated than you actually were.

> I think I made a symbolic equation between symbols.  Didn't you make a 
> *pythonic*  assignment?   Then python did the right thing when using the 
> multiplication operation '*' (by overloading?)

So what happens if I break it down is this:

In [1]: x, y = symbols('x, y')

In [2]: x
Out[2]: x

In [3]: y
Out[3]: y

In [4]: a = x + y

In [5]: a
Out[5]: x + y

In [6]: b = x * y

In [7]: b
Out[7]: x⋅y

In [8]: a*b
Out[8]: x⋅y⋅(x + y)

Note that I haven't created any symbols called a and b because I don't
need to. They are Python variables. The line a = x + y creates an
expression object and assigns it to a (as a normal Python assignment).
Likewise for the line b = x * y. SymPy doesn't know that I have called
these objects a and b and it doesn't need to.

Since a (as a Python variable) refers to the expression x + y and b
refers to x*y when I multiply these two I get a new expression x*y*(x
+ y). This new expression is created by operator overloading.
Specifically SymPy's Expr class has a __mul__ method that does this
but that's more detail than you need.

I can also create equation (Eq) objects as in:

In [9]: z = Eq(x, 2*y)

In [10]: z
Out[10]: x = 2⋅

This creates a new equation object. You can pass that object to some
SymPy functions that will know how to interpret it for example if you
ask the solve function to to solve the equation for y:

In [11]: solve(z, y)
Out[11]:
⎡x⎤
⎢─⎥
⎣2⎦

However creating the equation object does not in itself cause SymPy to
understand *in general* that there is a relationship between x and y.
SymPy only looks at the equation object you have created if you pass
that object (e.g. z) to some SymPy function.

> I took things a little farther:
>
> q,r,s = symbols('q r s')

Here you create two symbols q and r which you assign to the Python
variables q and r. That's reasonable except that...

> q = x+y
> r = x*y

now you've reassigned the Python variables q and r to be different
expression objects. There was no need to create the symbols q and r
earlier if this was the intention.

> print(q*r)
> q*r
> s = q*r + 1
> s
> s.subs(x,3)
>
> Everything worked.

Great!

> Is it the case that I made things overly complicated from the beginning?

I think so.

> I'm confused. I don't know how Sympy works, and would appreciate a better 
> description than the tutorial.

Can you point to a particular part of the tutorial that is confusing?
That would help to improve it.

Generally it is a lot easier to understand SymPy if you are
experienced with Python. A lot of our users are new to both Python and
SymPy and I think that makes it hard to explain what's going on. Some
things would be cleaner for users if SymPy was not embedded within
Python and can be confusing unless you already know Python well and
can see why things are the way they are.

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

Re: [sympy] Re: Interested in working on SymPy's quantum physics module

[Oscar Benjamin]

Hi Tilman,

It's a shame the project didn't work out but I'm glad to hear you're
still interested in contributing. Let us know if you start working on
this and want any guidance/help.

--
Oscar

On Sat, 6 Jul 2019 at 18:20, Tilman Roeder  wrote:
>
> Hey everyone,
>
> After talking to the people at my university, it seems like it is unlikely 
> that I will be able to get involved as part of the university project. But 
> once I have some time, I will look through the open issues and see if there 
> is anything I can do :)
>
> Apologies for making you guys wait around so long, the process of talking to 
> people has been much more long-winded than I anticipated.
>
> Tilman
>
> On Sunday, May 19, 2019 at 2:29:01 AM UTC+1, Tilman Roeder wrote:
>>
>> Hello,
>>
>> My name is Tilman. Me (and a friend of mine) are interested in working on 
>> extending and polishing the quantum physics module in SymPy as part of a 
>> university project. We both study Physics (currently in our 2nd year) at 
>> Imperial College London. The project work would be during the next academic 
>> year (so from September). However, I think it would be valuable to get 
>> started with some simple things to get aquatinted with the code base and 
>> process (as well as allowing plenty time to read up on the relevant 
>> subjects).
>>
>> From looking through the documentation etc. I get the impression that the QM 
>> module is currently very much a work in progress (especially the quantum 
>> information/ computation bits). From what I can tell, a good thing to get 
>> started on might be adding a few analytic solutions. There is one for the 
>> infinite square well, but none e.g. the harmonic oscillator. Starting with 
>> something very simple like this could be a really good way of getting to 
>> know the process, while focussing on the code etc., before tackling 
>> something more challenging.
>>
>> My friend and I are meeting someone in the physics department next week to 
>> discuss if this kind of work would be suitable for our project, and it would 
>> be really helpful to get the opinion of someone more closely involved with 
>> SymPy on this matter. (Note that I am also interested in contributing, 
>> should this turn out to not be suitable as part of my university work.)
>>
>> We are currently writing exams, but in about a month I would love to get 
>> started on some simple things to get a head start on the main project work.
>>
>>
>> TL;DR (useful pieces of information):
>>
>> - Interested to work on QM module
>> - Good experience with Python, especially for scientific computing, as well 
>> as some experience using SymPy to do hard integrals. See specifically these 
>> two repos on my GitHub: https://github.com/dyedgreen/schroedinger, 
>> https://github.com/dyedgreen/labs-ray-tracing
>> - Experience with other languages like C, Golang, Ruby, JavaScript
>> - Mathematics education level: 2nd year Theoretical Physics Undergraduate
>> - I speak English and German
>>
>> Thanks for taking the time to read this :)
>>
>>
>> Tilman
>>
> --
> 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/1f25e83d-ed3f-4871-b0d3-d85fec617939%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/CAHVvXxSKcb6cxV8ZbU-K4b5uwOUozgkwgjgKvYgP692cXmp3JQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] simplifying large boolean expressions/equations

[Oscar Benjamin]

Can you show a (short) example of some code that you've tried?

‪On Sun, 7 Jul 2019 at 17:18, ‫רועי גרמיזו‬‎  wrote:‬
>
>  Hi, what is the best way to simplify a boolean equation with more than 8 
> variables? setting force to true on simplify_logic just takes too long, and 
> to_dnf sometimes takes too long or don't really change the expression. I 
> don't necessarily have to use sympy, but I belive it is the best (or least 
> worst) option for me right now
>
> --
> 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/1f2681fc-4973-4375-8839-819ac58e9112%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/CAHVvXxQvm%3DPuDo_X3ZWGfbcGLokBNvNyy29bWfFRZ6QDt1B0%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Newbie: display product

[Oscar Benjamin]

On Sun, 14 Jul 2019 at 13:29, David Bailey  wrote:
>
> On 13/07/2019 22:36, Oscar Benjamin wrote:
>
>
> Generally it is a lot easier to understand SymPy if you are
> experienced with Python. A lot of our users are new to both Python and
> SymPy and I think that makes it hard to explain what's going on. Some
> things would be cleaner for users if SymPy was not embedded within
> Python and can be confusing unless you already know Python well and
> can see why things are the way they are.
>
> --
> Oscar
>
> I am also fairly new to Python and sympy, but I think I have pushed through 
> this pain barrier.
>
> As far as I can see, you really need to use symbols() or var() to set up 
> variables which are going to be used as symbols in bits of algebra or 
> calculus, but you do not need to make a variable symbolic if it is just going 
> to be used to hold expressions or for some other pythonic purpose, such as a 
> counter. However, no harm is done (someone correct me if I am wrong) if you 
> create a lot of symbols, which you can do with :
>
> from sympy.abc import *
>
> because if, say, you subsequently assign X=42 that will harmlessly destroy 
> the sympy symbol attached to x which will become pythonic again, but you 
> obviously want to use it as a constant so that is fine.
>
> I think a good strategy is to either save some letters for use as pythonic 
> variables, or only use variables with more than one character as pythonic 
> variables (they don't look nice in expressions, anyway)
>
> If you want to use x in expressions, then it is probably best not to assign 
> it to 42 (as above) but to leave it symbolic, and use subs to replace it in 
> an expression by 42.

Everything you say here is correct. You need to have a clean
separation in your mind between the Python variable names and the
sympy Symbol objects. When you fully understand all of these things
the results below will not be surprising:
```
>>> z = Symbol('x')
>>> z
x
>>> x = z**2
>>> x
x**2
```
(I don't generally recommend writing code like that 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 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/CAHVvXxTJmhrApFgxjN6pfHEvM70gWD0AfabEATXhQisGm0qctQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Using commands from SymPy website

[Oscar Benjamin]

Hi David,

This isn't a trivial point. I just checked to see what you mean and it
is annoying. I think that there should be a way to copy to clipboard
or access the raw code. I don't see how to do it though...

Unless someone else knows I think you should open an issue.

--
Oscar

On Wed, 26 Jun 2019 at 23:15, David Bailey  wrote:
>
> Sorry for raising a rather trivial point, but I am often frustrated by the 
> fact that if you visit a page such as 
> https://docs.sympy.org/latest/tutorial/manipulation.html, and try to select 
> some of the code with a view to copy/pasting it, you are instantly moved to 
> the SymPy Live Shell.
>
> There is a button 'Hide SymPy Live Shell', but that just hides the shell 
> once, as soon as you try again and select something from the tutorial. it 
> reappears.
>
> Have I failed to notice a way to stop this happening, so I can cut/paste 
> directly where I intend?
>
> 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 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/4c0d8e66-54d8-08c4-bf00-025255d0bb84%40dbailey.co.uk.
> 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/CAHVvXxQJweV7mSPkBVjRpWpKBH%2BwfVshBQuVLf4Ud4iQKY%3DTng%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] given a plane equation to extract the coefficients a,b,c,d

[Oscar Benjamin]

I'm not sure exactly what you mean. Does this help?

In [1]: a, b, c, d, x, y, z = symbols('a, b, c, d, x, y, z')

In [2]: eq = a*x + b*y+ c*z - d

In [3]: eq
Out[3]: a⋅x + b⋅y + c⋅z - d

In [4]: eq.coeff(x)
Out[4]: a

In [5]: eq.coeff(y)
Out[5]: b

In [6]: eq.coeff(z)
Out[6]: c

On Tue, 25 Jun 2019 at 18:13, HGO HGO  wrote:
>
> hi
>
> is it possible given a plane equation to extract the coefficients a,b,c,d ?
>
> 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 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/c9d43645-b45e-4690-8997-98f5ea8763a9%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/CAHVvXxQZedJND3fDZw7e%3D2%2BBPiX69PC2Rn5eni-v1%2BbzOCfH3w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Saving large symbolic expressions

[Oscar Benjamin]

This seems to be a bug. I think I can reproduce it with:

In [9]: import pickle

In [10]: from sympy.physics.mechanics import dynamicsymbols

In [11]: q1 = dynamicsymbols('q1')

In [12]: pickle.dumps(q1)
---
PicklingError Traceback (most recent call last)
 in 
> 1 pickle.dumps(q1)

PicklingError: Can't pickle q1: it's not the same object as __main__.q1

Although the final error message is slightly different. Normal Symbol
works so it is to do with dynamicsymbol in some way.

Digging further:

In [13]: q1 = Function('q1')(Symbol('t'))

In [14]: pickle.dumps(q1)
---
PicklingError Traceback (most recent call last)
 in 
> 1 pickle.dumps(q1)

PicklingError: Can't pickle q1: it's not the same object as __main__.q1

In [15]: q1 = Function('q1')

In [16]: pickle.dumps(q1)
Out[16]: b'\x80\x03c__main__\nq1\nq\x00.'

That pickle for the unapplied function is too short. I think something
is wrong with pickling functions.


To fix your problem substitute the dynamicsymbols for normal symbols.


Oscar

On Wed, 14 Aug 2019 at 10:54, Ash  wrote:
>
> Hello,
> I have derived the equations of motion of a dynamic system symbolically. To 
> evaluate the Mass Matrix and Coriolis Vector which contain several derivative 
> terms, the program takes around 14 sec. These two are to be used for various 
> other places. I tried saving and loading using 'dill'
>
> import dill
> MassMatrix, Coriolis = get_mc()
> dill.dump(MassMatrix, open("MassMatrix", "wb"))
> # dill.dump(Coriolis, open("Coriolis", "wb"))
>
> The above results in
>
> Traceback (most recent call last):
>   File 
> "/snap/pycharm-professional/147/helpers/pydev/_pydevd_bundle/pydevd_exec2.py",
>  line 3, in Exec
> exec(exp, global_vars, local_vars)
>   File "", line 1, in 
>   File "/home/ar0058/Ash/venv3.6/lib/python3.6/site-packages/dill/_dill.py", 
> line 287, in dump
> pik.dump(obj)
>   File "/usr/lib/python3.6/pickle.py", line 409, in dump
> self.save(obj)
>   File "/usr/lib/python3.6/pickle.py", line 521, in save
> self.save_reduce(obj=obj, *rv)
>   File "/usr/lib/python3.6/pickle.py", line 610, in save_reduce
> save(args)
>   File "/usr/lib/python3.6/pickle.py", line 476, in save
> f(self, obj) # Call unbound method with explicit self
>   File "/usr/lib/python3.6/pickle.py", line 736, in save_tuple
> save(element)
>   File "/usr/lib/python3.6/pickle.py", line 521, in save
> self.save_reduce(obj=obj, *rv)
>   File "/usr/lib/python3.6/pickle.py", line 610, in save_reduce
> save(args)
>   File "/usr/lib/python3.6/pickle.py", line 476, in save
> f(self, obj) # Call unbound method with explicit self
>   File "/usr/lib/python3.6/pickle.py", line 751, in save_tuple
> save(element)
>   File "/usr/lib/python3.6/pickle.py", line 521, in save
> self.save_reduce(obj=obj, *rv)
>   File "/usr/lib/python3.6/pickle.py", line 610, in save_reduce
> save(args)
>   File "/usr/lib/python3.6/pickle.py", line 476, in save
> f(self, obj) # Call unbound method with explicit self
>   File "/usr/lib/python3.6/pickle.py", line 736, in save_tuple
> save(element)
>   File "/usr/lib/python3.6/pickle.py", line 521, in save
> self.save_reduce(obj=obj, *rv)
>   File "/usr/lib/python3.6/pickle.py", line 610, in save_reduce
> save(args)
>   File "/usr/lib/python3.6/pickle.py", line 476, in save
> f(self, obj) # Call unbound method with explicit self
>   File "/usr/lib/python3.6/pickle.py", line 736, in save_tuple
> save(element)
>   File "/usr/lib/python3.6/pickle.py", line 521, in save
> self.save_reduce(obj=obj, *rv)
>   File "/usr/lib/python3.6/pickle.py", line 610, in save_reduce
> save(args)
>   File "/usr/lib/python3.6/pickle.py", line 476, in save
> f(self, obj) # Call unbound method with explicit self
>   File "/usr/lib/python3.6/pickle.py", line 751, in save_tuple
> save(element)
>   File "/usr/lib/python3.6/pickle.py", line 521, in save
> self.save_reduce(obj=obj, *rv)
>   File "/usr/lib/python3.6/pickle.py", line 610, in save_reduce
> save(args)
>   File "/usr/lib/python3.6/pickle.py", line 476, in save
> f(self, obj) # Call unbound method with explicit self
>   File "/usr/lib/python3.6/pickle.py", line 736, in save_tuple
> save(element)
>   File "/usr/lib/python3.6/pickle.py", line 521, in save
> self.save_reduce(obj=obj, *rv)
>   File "/usr/lib/python3.6/pickle.py", line 610, in save_reduce
> save(args)
>   File "/usr/lib/python3.6/pickle.py", line 476, in save
> f(self, obj) # Call unbound method with explicit self
>   File "/usr/lib/python3.6/pickle.py", line 736, in save_tuple
> save(element)
>   File "/usr/lib/python3.6/pickle.py", line 521, in save
> self.save_reduce(obj=obj, *rv)
>   File "/usr/lib/python3.6/pickle.py", line 610, in save_reduce
> 

Re: [sympy] Should symbolic integration fail gracefully?

[Oscar Benjamin]

Hi David,

Can you open an issue on Github please. That's a bug that should be fixed.

Oscar

On Tue, 20 Aug 2019 at 21:08, David Bailey  wrote:
>
> It seems as though the symbolic integration process fails when it can't find 
> a solution:
>
>  integrate(sin(x**n),x)
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "C:\SymPyWorkbook\lib\site-packages\sympy\integrals\integrals.py", 
> line 1477, in integrate
> return integral.doit(**doit_flags)
>   File "C:\SymPyWorkbook\lib\site-packages\sympy\integrals\integrals.py", 
> line 541, in doit
> function, xab[0], **eval_kwargs)
>   File "C:\SymPyWorkbook\lib\site-packages\sympy\integrals\integrals.py", 
> line 1012, in _eval_integral
> h = meijerint_indefinite(g, x)
>   File "C:\SymPyWorkbook\lib\site-packages\sympy\integrals\meijerint.py", 
> line 1621, in meijerint_indefinite
> res = _meijerint_indefinite_1(f.subs(x, x + a), x)
>   File "C:\SymPyWorkbook\lib\site-packages\sympy\integrals\meijerint.py", 
> line 1684, in _meijerint_indefinite_1
> if b < 0 or f.subs(x, 0).has(nan, zoo):
>   File "C:\SymPyWorkbook\lib\site-packages\sympy\core\relational.py", line 
> 304, in __nonzero__
> raise TypeError("cannot determine truth value of Relational")
> TypeError: cannot determine truth value of Relational
>
> I suppose I expected it to return an unevaluated integral -  
> integral(sin(x**n),x)
>
> 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/b15c771c-5051-225d-bd0d-a655b6952de0%40dbailey.co.uk.

-- 
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/CAHVvXxTQHmn3WgR5UdaXaR7Cv5aedv_rUS8J6ecBk0YxbvsYCw%40mail.gmail.com.

Re: [sympy] Can't get sympy.functions.atan2 to work with _eval_evalf

[Oscar Benjamin]

There's a "return" missing:
$ git diff
diff --git a/sympy/functions/elementary/trigonometric.py
b/sympy/functions/elementary/trigonometric.py
index 635e7f2..b7a0ad1 100644
--- a/sympy/functions/elementary/trigonometric.py
+++ b/sympy/functions/elementary/trigonometric.py
@@ -3070,4 +3070,4 @@ def fdiff(self, argindex):
 def _eval_evalf(self, prec):
 y, x = self.args
 if x.is_extended_real and y.is_extended_real:
-super(atan2, self)._eval_evalf(prec)
+return super(atan2, self)._eval_evalf(prec)

Also it checks if the args are real so it looks like you might need to
declare your variables a and y with real=True. If you do that then the
result is caculated as: 0.785398163397448

Can you open an issue on Github for this?

On Tue, 20 Aug 2019 at 15:34, Ville Bergholm  wrote:
>
> I've been trying to use sympy.Symbol to implement a system where the 
> numerical value of a symbolic quantity is only fixed when it is evaluated 
> using evalf().
> To accomplish this I've redefined _eval_evalf() to return the aforementioned 
> value (a fixed 5.0 in the toy example below).
>
> This works fine with basic algebraic operations and most SymPy functions. 
> However, for some reason atan2 seems to behave differently and _eval_evalf is 
> never called.
> Is this a bug, or have I misunderstood the purpose of _eval_evalf?
>
>
> import sympy
> import sympy.functions as syf
>
> class A(sympy.Symbol):
> def _eval_evalf(self, prec):
> print('*')
> return sympy.Float(5.0)
>
> x = A('X')
> y = A('Y')
> print('polynomial:')
> print((2*x-4+y).evalf())  # works fine
> print('atan:')
> print(syf.atan(y / x).evalf())  # works fine
> print('beta:')
> print(syf.beta(y, x).evalf())  # works fine
> print('atan2:')
> print(syf.atan2(y, x).evalf())  # prints "atan2(Y, X)", does not call 
> A._eval_evalf
>
> --
> 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/4480befb-c8d3-48f1-a1be-b5e8bd55a0be%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/CAHVvXxSD2zW1%3DQ_H4%2BJX%3D3%2BTRRd%3DeKObMqW-udsRY-GSZnOX4A%40mail.gmail.com.

Re: [sympy] How to avoid automatic xi symbols appearing with diff of chained functions

[Oscar Benjamin]

I would say that you should use doit but I just tried that and it crashed:

In [*9*]: e=Function('g')(Function('f')(x1,x2),Function('h'
)(x1,x2)).diff(x1)


In [*10*]: e


Out[*10*]:

⎛ ∂  ⎞│⎛ ∂   ⎞│   ⎛
∂   ⎞│ ⎛ ∂

⎜───(f(ξ₁, x[2]))⎟│   ⋅⎜───(g(ξ₁, h(x[1], x[2])))⎟│ +
⎜───(g(f(x[1], x[2]), ξ₂))⎟│⋅⎜───(h(ξ₁

⎝∂ξ₁ ⎠│ξ₁=x[1] ⎝∂ξ₁  ⎠│ξ₁=f(x[1], x[2])
⎝∂ξ₂  ⎠│ξ₂=h(x[1], x[2]) ⎝∂ξ₁


⎞│

, x[2]))⎟│

⎠│ξ₁=x[1]


In [*11*]: e.doit()


Fatal Python error: Cannot recover from stack overflow.


Thread 0x7994b000 (most recent call first):

  File "/Users/enojb/.local/lib/python3.5/threading.py", line 293 in wait

  File "/Users/enojb/.local/lib/python3.5/threading.py", line 549 in wait

  File
"/Users/enojb/current/sympy/35venv/lib/python3.5/site-packages/IPython/core/history.py",
line 829 in run

  File
"/Users/enojb/current/sympy/35venv/lib/python3.5/site-packages/IPython/core/history.py",
line 58 in needs_sqlite

  File
"",
line 2 in run

  File "/Users/enojb/.local/lib/python3.5/threading.py", line 914 in
_bootstrap_inner

  File "/Users/enojb/.local/lib/python3.5/threading.py", line 882 in
_bootstrap


Current thread 0x7fffae5cf380 (most recent call first):

  File "/Users/enojb/current/sympy/sympy/sympy/core/symbol.py", line 284 in
assumptions0

  File "/Users/enojb/current/sympy/sympy/sympy/core/symbol.py", line 274 in
_hashable_content

  File "/Users/enojb/current/sympy/sympy/sympy/core/symbol.py", line 381 in
_hashable_content

  File "/Users/enojb/current/sympy/sympy/sympy/core/expr.py", line 133 in
__eq__

  File "/Users/enojb/current/sympy/sympy/sympy/core/basic.py", line 343 in
__eq__

  File "/Users/enojb/current/sympy/sympy/sympy/core/containers.py", line 97
in __eq__

  File "/Users/enojb/current/sympy/sympy/sympy/core/expr.py", line 134 in
__eq__

  File "/Users/enojb/current/sympy/sympy/sympy/core/cache.py", line 94 in
wrapper

  File "/Users/enojb/current/sympy/sympy/sympy/core/function.py", line 2291
in 

  File "/Users/enojb/current/sympy/sympy/sympy/core/function.py", line 2291
in _hashable_content

  File "/Users/enojb/current/sympy/sympy/sympy/core/expr.py", line 109 in
__hash__

  File "/Users/enojb/current/sympy/sympy/sympy/core/function.py", line 2286
in __hash__

  File "/Users/enojb/current/sympy/sympy/sympy/core/cache.py", line 94 in
wrapper

  File "/Users/enojb/current/sympy/sympy/sympy/core/expr.py", line 196 in
__mul__

  File "/Users/enojb/current/sympy/sympy/sympy/core/decorators.py", line
129 in binary_op_wrapper

  File "/Users/enojb/current/sympy/sympy/sympy/core/decorators.py", line 91
in __sympifyit_wrapper

  File "/Users/enojb/current/sympy/sympy/sympy/core/function.py", line 618
in _eval_derivative

  File "/Users/enojb/current/sympy/sympy/sympy/core/basic.py", line 1724 in
_visit_eval_derivative_scalar

  File "/Users/enojb/current/sympy/sympy/sympy/core/basic.py", line 1719 in
_accept_eval_derivative

  File "/Users/enojb/current/sympy/sympy/sympy/core/basic.py", line 1743 in
_eval_derivative_n_times

  File "/Users/enojb/current/sympy/sympy/sympy/core/function.py", line 1427
in __new__

  File "/Users/enojb/current/sympy/sympy/sympy/core/function.py", line 1598
in doit

  File "/Users/enojb/current/sympy/sympy/sympy/core/function.py", line 2242
in doit

  File "/Users/enojb/current/sympy/sympy/sympy/core/function.py", line 1600
in doit

  File "/Users/enojb/current/sympy/sympy/sympy/core/function.py", line 2242
in doit

  File "/Users/enojb/current/sympy/sympy/sympy/core/function.py", line 1600
in doit

  File "/Users/enojb/current/sympy/sympy/sympy/core/function.py", line 2242
in doit

  File "/Users/enojb/current/sympy/sympy/sympy/core/function.py", line 1600
in doit

  File "/Users/enojb/current/sympy/sympy/sympy/core/function.py", line 2242
in doit

  File "/Users/enojb/current/sympy/sympy/sympy/core/function.py", line 1600
in doit

  File "/Users/enojb/current/sympy/sympy/sympy/core/function.py", line 2242
in doit

...

  File "/Users/enojb/current/sympy/sympy/sympy/core/function.py", line 2242
in doit

  File "/Users/enojb/current/sympy/sympy/sympy/core/function.py", line 1600
in doit

  ...

Abort trap: 6

On Sun, 25 Aug 2019 at 01:13, Mathieu Lamarre 
wrote:

> Simple example of multivariate chain rule:
> print(Function('g')(Function('f')(x1,x2)).diff(x1))
>
> Gives the expected:
>
> [image: diff1.PNG]
>
> Derivative(f(x1, x2), x1)*Derivative(g(f(x1, x2)), f(x1, x2))
>
>
> Adding another function h:
>
> print(Function('g')(Function('f')(x1,x2),Function('h')(x1,x2)).diff(x1))
>
> Gives the expected answer but with extra _xi_1 and _xi_2 symbols:
>
> [image: diff.PNG]
>
> Derivative(f(x1, x2), x1)*Subs(Derivative(g(_xi_1, h(x1, x2)), _xi_1), _xi_1, 
> f(x1, x2)) + Derivative(h(x1, x2), x1)*Subs(Derivative(g(f(x1, x2), _xi_2), 
> _xi_2), _xi_2, h(x1, x2))
>
>
> 

Re: [sympy] Re: fcode example in documentation not working?

[Oscar Benjamin]

On Sat, 24 Aug 2019 at 01:29, manaxf  wrote:
>
> Has this issue been fixed?

I don't know but judging from Bjorn's comments maybe it isn't that
hard to fix. Are you interested in sending a PR?

-- 
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/CAHVvXxREkr7yO%3DUmQuXw5c1OuqjgbmDCj4gL2eAYSo%3Dgk1nmDQ%40mail.gmail.com.

Re: [sympy] Should symbolic integration fail gracefully?

[Oscar Benjamin]

On Wed, 21 Aug 2019 at 11:50, David Bailey  wrote:
>
> On 20/08/2019 21:10, Aaron Meurer wrote:
>
> "TypeError: cannot determine truth value of Relational" generally
> indicates a bug in SymPy. And yes, integrate() should always return
> unevaluated when it can't compute the integral.
>
> I imagine that symbolic integration may be littered by tricky problems of 
> this sort, and I wonder if the integrate code should be wrapped in some sort 
> of exception handler so that it exits and returns unevaluated.

I think that would hide all kinds of bugs. It's better to see the
exception and fix the code. Maybe after that check (if it didn't
raise) something more useful could be done than return unevaluated.

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/CAHVvXxTn1Qm0kOO%3DAbO3mFPPb-GgWG%3D0Zr6pk2tenf21jJsy7w%40mail.gmail.com.

Re: [sympy] Should symbolic integration fail gracefully?

[Oscar Benjamin]

I've opened an issue:
https://github.com/sympy/sympy/issues/17473

On Wed, 21 Aug 2019 at 12:11, Oscar Benjamin  wrote:
>
> On Wed, 21 Aug 2019 at 11:50, David Bailey  wrote:
> >
> > On 20/08/2019 21:10, Aaron Meurer wrote:
> >
> > "TypeError: cannot determine truth value of Relational" generally
> > indicates a bug in SymPy. And yes, integrate() should always return
> > unevaluated when it can't compute the integral.
> >
> > I imagine that symbolic integration may be littered by tricky problems of 
> > this sort, and I wonder if the integrate code should be wrapped in some 
> > sort of exception handler so that it exits and returns unevaluated.
>
> I think that would hide all kinds of bugs. It's better to see the
> exception and fix the code. Maybe after that check (if it didn't
> raise) something more useful could be done than return unevaluated.
>
> 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/CAHVvXxSd%2BqshV%2BYPmd0yXbi58rrMNg0Dsrwzwn44T_has4vUEQ%40mail.gmail.com.

Re: [sympy] solving simultaneous equations involving sine and cosine functions

[Oscar Benjamin]

This is a bug. Can you open an issue on github please?
https://github.com/sympy/sympy/issues

The error comes from:

In [2]: factor_terms(pi/4+oo*I)
---
TypeError: can't convert oo to int

Probably another error has left to that in the first place though.

I removed the floats from your problem since they aren't needed and
used check=False, simplify=False with solve to avoid calling simplify
(which is ultimately calling factor_terms). Then I get an answer
(using master):

⎡
  ⎛  ⎛   ⎛ang_zs(t)   π⎞⎞
⎢
  ⎜  ⎜tan⎜─ + ─⎟ + 1⎟
⎢⎛π -π ⎞  ⎛π 3⋅π⎞  ⎛3⋅π -π ⎞  ⎛3⋅π
3⋅π⎞  ⎜  ⎜   ⎝2   8⎠⎟  π
⎢⎜─, ang_ys(t), ───⎟, ⎜─, ang_ys(t), ───⎟, ⎜───, ang_ys(t), ───⎟,
⎜───, ang_ys(t), ───⎟, ⎜2⋅atan⎜──⎟, ─, ang
⎢⎝2  4 ⎠  ⎝2  4 ⎠  ⎝ 2   4 ⎠  ⎝ 2
 4 ⎠  ⎜  ⎜   ⎛ang_zs(t)   π⎞⎟  2
⎢
  ⎜  ⎜tan⎜─ + ─⎟ - 1⎟
⎣
  ⎝  ⎝   ⎝2   8⎠⎠

  ⎞  ⎛   ⎛   ⎛ang_zs(t)   π⎞⎞  ⎞⎤
  ⎟  ⎜   ⎜tan⎜─ + ─⎟ - 1⎟  ⎟⎥
  ⎟  ⎜   ⎜   ⎝2   8⎠⎟  π   ⎟⎥
_zs(t)⎟, ⎜-2⋅atan⎜──⎟, ─, ang_zs(t)⎟⎥
  ⎟  ⎜   ⎜   ⎛ang_zs(t)   π⎞⎟  2   ⎟⎥
  ⎟  ⎜   ⎜tan⎜─ + ─⎟ + 1⎟  ⎟⎥
  ⎠  ⎝   ⎝   ⎝2   8⎠⎠  ⎠⎦


Oscar

On Fri, 13 Sep 2019 at 11:00, Ash  wrote:
>
> Hello,
> I have the following minimal working example for solving a system of 
> simultaneous non-linear equations. Angles, ang_xs, ang_ys, and ang_zs are 
> dynamic in nature but for this particular instant, I am trying to solve A = 
> [0, 0, 0]^T. This returns an error "can't convert oo to int". Could anyone 
> suggest a solution please? Also, is there a way to set anything less than 
> 1e-6 to be zero?
>
> from sympy import *
> from sympy.physics.mechanics import *
>
>
> ang_xs, ang_ys, ang_zs = dynamicsymbols("ang_xs ang_ys ang_zs ")
> A = Matrix( [
>  [1.005e-14*sin(ang_zs + pi/4)*cos(ang_ys)],
>  [1.005e-14*sin(ang_zs + pi/4)*sin(ang_xs)*sin(ang_ys) - 
> 1.005e-14*cos(ang_zs + pi/4)*cos(ang_xs)],
>  [-1.005e-14*sin(ang_zs + pi/4)*sin(ang_ys)*cos(ang_xs) - 
> 1.005e-14*sin(ang_xs)*cos(ang_zs + pi/4)]
>  ])
> p = (ang_xs, ang_ys, ang_zs)
> eq1, eq2, eq3 = Eq(A[0]), Eq(A[1]), Eq(A[2])
> ang_xs, ang_ys, ang_zs = solve([eq1, eq2, eq3], p)
>
>
> Thanks
> Ash
>
> --
> 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/f1cbbc4f-ff1c-4410-bea1-7a3b3cb9676e%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/CAHVvXxSFwRVgw9rtRiHjiJa%3DgykyeGz0jiQwtwsspGNJBmbyXg%40mail.gmail.com.

Re: [sympy] Re: Query Regarding Contributing towards Sympy

[Oscar Benjamin]

Graph theory has already been ruled out for SymPy:
https://github.com/sympy/sympy/issues/8186
Most graph-theoretic algorithms are not symbolic and don't really have
any connection to the symbolic manipulation that SymPy does.

That being said there is plenty of scope to use graph theoretic
algorithms to improve the inner workings of SymPy:
https://github.com/sympy/sympy/issues/16174
https://github.com/sympy/sympy/issues/16207

The connect components algorithm was added here:
https://github.com/sympy/sympy/pull/16225

I didn't get round to actually making proper use of it although you
can some demonstrations of what it might be able to improve in the
links above. I have an open PR here for using this in solve
https://github.com/sympy/sympy/pull/16550
which I should really finish.

There are many possible applications of the idea in matrices:
eigenvalues, determinants, solving linear systems, inverses etc.

On Sun, 8 Sep 2019 at 14:34, Gagandeep Singh (B17CS021)
 wrote:
>
> In my opinion, SymPy is concerned about symbolic manipulation and 
> mathematics. The topics you suggested will be more appropriate for a data 
> structures and algorithms libraries. If other members agree on your 
> suggestion, then feel free to draft a issue for further discussion.
> In addition, I see that you are doing a specialisation in statistics, so 
> probably, `sympy.stats` can be the right module for you to contribute. I have 
> just completed my GSoC 2019 project which was related to statistics project. 
> So, if you are interested, you can continue from where I left.
> You can find the details of the previous work done at, 
> https://github.com/sympy/sympy/wiki/GSoC-2019-Report#gagandeep-singh-enhancement-of-statistics-module-francesco-bonazzi-sidhant-nagpal
>
> With regards,
> Gagandeep Singh
> Github - https://github.com/czgdp1807/
> Linkedin - https://www.linkedin.com/in/gdp1/
>
>
> On Sun, Sep 8, 2019 at 6:57 PM Aizen  wrote:
>>
>> All Right.
>> Topics such as Graph Theory( Creating Graph Data Structures, Standard Graph 
>> Algorithms such as BFS and DFS, Graph Analysis and even trivial things such 
>> as checking if a degree sequence is a graphic or not, etc) and Network 
>> Topology (Creating and testing).
>>
>> I am sorry for the delay in responding because of some personal reasons. I 
>> will try to be quick from here now.
>>
>> On Monday, September 2, 2019 at 7:04:05 PM UTC+5:30, Gagandeep Singh 
>> (B17CS021) wrote:
>>>
>>> Can you please give a rough idea(name of the topics from mathematics with 
>>> one or two line explanation) about the feature(S) you want to add to SymPy?
>>>
>>> With Regards,
>>> Gagandeep Singh
>>> Github - https://www.github.com/czgdp1807
>>> LinkedIn - https://www.linkedin.com/in/czgdp1807
>>>
>>> On Mon, 2 Sep, 2019, 6:26 PM Aizen,  wrote:

 I have spent time getting familiar with using Sympy regularly. I read the 
 page regarding `Introduction to Contributing`, and it says that I should 
 start by solving issues first(the easy ones). I would love to do that, but 
 the reason I want to contribute is, as I and my peers work in the related 
 stuff and we have to code from scratch every time on similar things. I 
 realized that a lot of people use the same things and it would help if 
 Sympy could provide that.
 I want to introduce some new functionality from another field of 
 mathematics which is not there in Sympy yet, but I believe would be a 
 great addition for people in mathematical and statistical analysis.
 How should I approach towards making a proposal for the same before I 
 start contributing to that functionality, I am no experience about 
 contributing at open source. Should I make an `issue` in the issues 
 section which could later be marked as 'feature-request' by the 
 administrators?
  Please guide me.

 Thanks

 On Saturday, August 10, 2019 at 9:23:34 PM UTC+5:30, Aizen wrote:
>
> Ok.
>
> Thank You for your response.
>
> I will do as suggested.
>
> Yash
>
> On Friday, August 9, 2019 at 2:27:21 PM UTC+5:30, Aizen wrote:
>>
>> Hello. I am Yash, and I am pursuing a Masters in Mathematics and 
>> Statistics from the Indian Insitute of Science Education and Research, 
>> Kolkata. I also work in Sentiment Analysis, Algorithmic Prediction, and 
>> Web Development.
>> I was looking for projects in Python and Mathematics in the Google 
>> Summer of Code Database and came across Sympy. I want to contribute to 
>> the development of this project. I am new to open source. Can anyone 
>> guide me towards the steps for it? How do I request to work on a new 
>> feature or new topic implementation in Statistics and Discrete 
>> Mathematics?
>> Thanks

 --
 You received this message because you are subscribed to the Google Groups 
 "sympy" group.
 To unsubscribe from this group and stop receiving 

Re: [sympy] SymPy project

[Oscar Benjamin]

Posting here is a good idea. There's probably somewhere on the wiki
that lists related projects. Otherwise perhaps mailing lists related
to Jupyter or Spyder might be relevant.

I suggest uploading it to pypi so it can be installed with pip first
though. That substantially lowers the barrier to someone trying it
out.

I just tried and found a problem with f(x) which seems to be
interpreted as f*x so you can't use it for solving ODEs e.g.:

In [2]: dsolve(f(x).diff(x)-x)
Out[2]:
 2
x
f(x) = C₁ + ──
2

Oscar

On Sat, 7 Sep 2019 at 14:59, Tomasz Pytel  wrote:
>
> Hi all, I've posted here before about a SymPy project I've been working on 
> for the past 6 months or so and I've gotten it to a point where I would not 
> feel embarrassed were it to be used by someone other than me.
> It is a YSWYG graphical symbolic scratchpad app (Windows or Linux), and I 
> wonder if anyone could give me some tips on any forums or sites it would be 
> appropriate to post it to in order to publicize it a little?
>
> The project itself is on GitHub: https://github.com/Pristine-Cat/SymPad
>
> Would really appreciate any ideas :)
>
> --
> 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/0af0ed58-ba74-4689-89a2-c8926beb3be0%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/CAHVvXxTFJzxWRDVj%3D6-QHVFnkOVvwoNrHeP%3DUwK%3DnJtjWh1rRg%40mail.gmail.com.

Re: [sympy] Coding guidelines

[Oscar Benjamin]

Preventing assignment isn't necessary for the internal workings of
SymPy. The only advantage it has is potentially avoiding confusion for
users. I don't particularly see users getting confused about this
though (although maybe that's because of the widespread use of
properties).

What I think is important is that any properties/attributes are
derivable from `.args` and not stored separately. Also I think it's
good to avoid using `.args` directly where possible so something like:

class MyThing(Basic):
def __new__(cls, one, another):
obj = Basic.__new__(cls, one, another)

@property
def one(self):
return self.args[0]

@property
def another(self):
return self.args[1]

def get_something(self):
return f(self.one)# Using one rather than .args[0]

Then apart from the properties none of the other methods should
directly access args. This makes it possible to easily subclass
MyThing and have a different args layout in the subclass. This is
common when creating a singleton subclass:

class MyThingZero(MyThin, Singleton):
def __new__(cls):
return Basic.__new__(cls)

@property
def one(self):
return 0

@property
def another(self):
return oo

Here MyThingZero doesn't need to have .args because its a singleton so
they couldn't mean anything. MyThingZero can inherit all of the
methods of MyThing and only needs to redefine the accessor properties
because nothing else touches .args directly.

Sometimes it is desirable to cache some property of the object as an
attribute in __new__ but this should only done if it is something
derivable from .args and actually I think it's better to do the
caching in a property.

class Bad(Basic):
def __new__(self, one, another):
obj = Basic.__new__(cls, another)
obj._one = one# <---  don't do this

This is bad because the `_one` attribute is stored outside of .args.
Once you've done this you've interrupted the machinery of Basic and
you'll end up being tempted to override __eq__, __hash__, .args,
.func, etc and there's no way you'll get all the details right so
there will be subtle bugs and things you haven't thought of like
pickling will break. You can try to fix these things one at a time but
by the time you're finished you will have reimplemented a good chunk
of Basic.

It might be desirable to cache an object as an attribute to avoid
recomputing it. As long as it is derived from .args that is okay:

class Okay(Basic)
def __new__(self, one, another):
obj = Basic.__new__(cls, one, another)
# This is derivable from args but expensive so we cache it
obj._attribute = expensive_function(one)

@property
def attribute(self):
return self._attribute

Better though is to put that caching inside the property so if we
don't need it then expensive_function is never called:

class Better(Basic):
def __new__(self, one, another):
obj = Basic.__new__(cls, one, another)

@property
def attribute(self):
val = getattr(self, '_attribute', None)
if val is not None:
return val
else:
val = self._attribute = expensive_function(self.one)
return val

I'm not sure if there is already a decorator that does this kind of
caching (it should be added if there isn't).

The examples of bad things I show above are all ones that I've seen in
SymPy's own codebase so please judge for yourself what is reasonable
rather than looking for precedents in the existing code. Currently the
codebase is inconsistent and there are a lot of Basic subclasses doing
dodgy things with attributes and args. I would like to clean that up
though.

Oscar

On Sun, 8 Sep 2019 at 11:49, Rybalka Denys  wrote:
>
> There are several ways to implement properties of sympy objects. The simplest 
> one is:
> ```
> def __new__(*args):
> obj = Basic(*args)
> obj.prop = 'some_property'
> ```
> A slightly more complicated one is:
> ```
> def __new__(*args):
> obj = Basic(*args)
> obj._prop = 'some_property'
>
> @property
> def prop(self):
> return self._prop
> ```
>
> The first method is simpler and shorter, but the second one explicitly 
> forbids assignments `obj.prop = ...`. I have tried looking into various sympy 
> modules and the practices are different. Which implementation is preferable? 
> And on a more general topic, is there a "coding guidelines" webpage, where 
> issues like this should be resolved once and for all? Maybe it makes sense to 
> create one? I believe it will improve both the code and user experience.
>
> Best Regards,
> Denys Rybalka
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sympy+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> 

Re: [sympy] Coding guidelines

[Oscar Benjamin]

I should clarify that what I said is opinionated (my opinion in
particular!) so it's possible others disagree. Certainly there is a
lot of code in SymPy that doesn't follow the advice above.

If we want a cached_property decorator then we can add this somewhere
in sympy/utilities or perhaps sympy/core/cache:

from functools import wraps

def cached_property(propfunc):

attrname = '_' + propfunc.__name__
sentinel = object()

@wraps(propfunc)
def accessor(self):
val = getattr(self, attrname, sentinel)
if val is sentinel:
val = propfunc(self)
setattr(self, attrname, val)
return val

return property(accessor)

class A:
@cached_property
def g(self):
print('foo')
return 'bar'

>From the SymPy codebase though most instances of storing attributes
outside of args not for this kind of caching. I think it's usually the
author deliberately trying to keep the attribute out of args. That
could be because the arg is unsympifiable or it could be because there
is too much code that relies on a particular args layout so the author
wants to emulate that. The latter reason is why it is best to have a
layer above args that defines properties (one and another in the
examples above) so other code doesn't need to access args directly.

Oscar

On Sun, 8 Sep 2019 at 14:56, Rybalka Denys  wrote:
>
> Great, that is exactly what I've been trying to find!
>
> By the way, there is caching property decorator called `@cached_property`,
> that does exactly what you suggested. It is, however, not in the standard
> library (https://pypi.org/project/cached-property/). Maybe it would be
> beneficial to add it to the standard sympy package? Unfortunately¸
> I have no idea how these things are done.
>
> Do you think it is worthwhile to create a page with the "coding guidelines",
> so that other authors can use this information? If yes, where?
>
> Denys
>
> --
> 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/a78f21b0-63c6-4b78-8b4d-e21a3e95968d%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/CAHVvXxSQOva21Pkeq5sVWHYTPzC8uz4x_w1f1NR4W3c3umvw0w%40mail.gmail.com.

Re: [sympy] New here,willing to contribute,tried to work on an issue(#17333)

[Oscar Benjamin]

Hi Dinesh,

It's great that you are interested in contributing to SymPy. If you want to
work on a particular issue then the best thing is to ask/comment on that
issue i.e. here:
https://github.com/sympy/sympy/issues/17333

Oscar

On Sun, 4 Aug 2019 at 17:38, Dinesh ch  wrote:

> Hello,
> I'm Dinesh ch pursuing computer science B.tech in NIT Andhra(India). I'm
> good at math and got some experience with python as I'm working as an
> intern at ATG.world to automate some test cases for their website using
> selenium module.I found Sympy and was excited to contribute to Sympy, out
> my love towards math and programming. I've read contributing
> guidelines,checked tutorials and docs.Then found this issue #17333 and
> tried working on it.
>
> I found that it is occurring because of Max function that is used to find
> norm(2) in the code(here's an image,where I tried find norm(2) with
> singular_values).How should I proceed further.It would be great  if someone
> can guide me.
>
> [image: ef92b7a8-3336-48d5-b688-ff5cc795d55e.jpg]
>
> Thanks,
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sympy+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/41501fb9-5907-47d4-9f22-7758f436b111%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/CAHVvXxT_eTYnmjm-VGL%2B144F7Mbx_-nnMhoUVjAxE18jqoiYDw%40mail.gmail.com.

Re: [sympy] can SymPy be more explicit about assumptions?

[Oscar Benjamin]

See also https://github.com/sympy/sympy/issues/17224


On Sun, 4 Aug 2019 at 13:32, Chris Smith  wrote:
>
> Symbols default to commutative=True but I wonder if we should also default to 
> `finite=True` since that is consistent with the behavior of `x - x` being 0. 
> (If x is infinite then `x - x` is nan.) In this discussion here I point out 
> how `x-x->0` without the correct assumption (that x is finite) is 
> inconsistent with unevaluation of `x**2 < 0`. The inequality remains 
> unevaluated because it would be an invalid comparison if `x` had real and 
> imaginary components and produced a comparison like `2*I < 0` when `x = 1 + 
> I`.
>
> I suspect that this might have minimal impact on the current behavior; I 
> suspect that making `real=True` a default assumption, too, would have a 
> greater impact. Without making the latter, all inequalities would continue to 
> be unevaluated for plain/vanilla symbols because they would have to entertain 
> the possibility of an invalid result. e.g. `Eq(1/x, 0)` for finite `x` would 
> not evaluate to True (even though `x` might be finite) when x is not known to 
> be real or imaginary.
>
> /c
>
> --
> 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/12753973-4620-4b2e-8046-8147b4ec2372%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/CAHVvXxTfRYeT8PGvFYBFQTVD%2B8ZX5LGhGnUsVSyYauFJujBx%3Dg%40mail.gmail.com.

Re: [sympy] which AccumBounds result is correct

[Oscar Benjamin]

I guess this is the dependency problem in interval arithmetic:
https://en.wikipedia.org/wiki/Interval_arithmetic#Dependency_problem
(Note that x**2+x is the example used there)

The issue is that we have to know the identity of the intervals. For
example if x and y are distinct intervals both [-1,1] then x*y is
[-1,1]. However x**2 has to be [0, 1].

On Sat, 20 Jul 2019 at 11:34, Chris Smith  wrote:
>
> Which result is correct? The second is a refactoring of the first:
>
> >>> AccumBounds(-1, 1) + AccumBounds(-1, 1)**2
> AccumBounds(-1, 2)
> >>> AccumBounds(-1, 1)*(1 + AccumBounds(-1, 1))
> AccumBounds(-2, 2)
>
> --
> 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/e9b71b7d-8239-4851-8358-23b1249dbd7a%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/CAHVvXxSbb4VLZa01JU92c3%3DuA8gxQdcZZirXF5b9D%3DCsnxng4Q%40mail.gmail.com.

Re: [sympy] Symbolic integrator using a neural network

[Oscar Benjamin]

Neural nets are trained for a particular statistical distribution of
inputs and in the paper they describe their method for generating a
particular ensemble of possibilities. There might be something
inherent about the examples they give that means they are all solved
using a particular approach. From their description I could imagine
writing a pattern-matching integrator that would explicitly try to
reverse the way the examples are generated.

Perhaps the examples from e.g. the SymPy test suite would in some ways
represent a more "natural" distribution since they are written by
humans and show the kinds of problems that humans wanted to solve. It
would be interesting to see how the accuracy of the net looks on that
distribution of inputs (although any comparison with SymPy on that
data would be unfair).

Oscar

On Sat, 28 Sep 2019 at 07:30, Aaron Meurer  wrote:
>
> On Fri, Sep 27, 2019 at 11:56 PM Ondřej Čertík  wrote:
> >
> > On Fri, Sep 27, 2019, at 12:48 PM, Aaron Meurer wrote:
> > > There's a review paper for ICLR 2020 on training a neural network to
> > > do symbolic integration. They claim that it outperforms Mathematica by
> > > a large margin. Machine learning papers can sometimes make overzealous
> > > claims, so scepticism is in order.
> > >
> > > https://openreview.net/pdf?id=S1eZYeHFDS
> > >
> > > The don't seem to post any code. The paper is in double blind review,
> > > so maybe it will be available later. Or maybe it is available now and
> > > I don't see it. If someone knows, please post a link here.
> > >
> > > They do cite the SymPy paper, but it's not clear if they actually use 
> > > SymPy.
> >
> > They wrote:
> >
> > "The validity of a solution itself is not provided by the model, but by an 
> > external symbolic framework (Meurer et al., 2017). "
> >
> > So that seems to suggest they used SymPy to check the results.
> >
> > >
> > > I think it's an interesting concept. They claim that they generate
> > > random functions and differentiate them to train the network. But I
> > > wonder if one could instead take a large pattern matching integration
> > > table like RUBI and train it on that, and produce something that works
> > > better than RUBI. The nice thing about indefinite integration is it's
> > > trivial to check if an answer is correct (just check if
> > > diff(integral(f)) - f == 0), so heuristic approaches that can
> > > sometimes give nonsense are tenable, because you can just throw out
> > > wrong answers.
> > >
> > > I'm also curious (and sceptical) on just how well a neural network can
> > > "learn" symbolic mathematics and specifically an integration
> > > algorithm. Another interesting thing to do would be to try to train a
> > > network to integrate rational functions, to see if it can effectively
> > > recreate the algorithm (for those who don't know, there is a complete
> > > algorithm which can integrate any rational function). My guess is that
> > > this sort of thing is still beyond the capabilities of a neural
> > > network.
> >
> > I saw this paper too today. My main question is whether their approach is 
> > better than Rubi (say in Mathematica, as it doesn't yet work 100% in SymPy 
> > yet). They show that their approach is much better than Mathematica, but so 
> > is Rubi.
>
> It actually isn't clear to me yet that they've shown it. I want to see
> what their test suite of functions looks like.
>
> Aaron Meurer
>
> >
> > The ML approach seems like a brute force. So is Rubi. So it's fair to 
> > compare ML with Rubi. On the other hand, I feel it's unfair to compare 
> > brute force with an actual algorithm, such as Risch.
> >
> > Ondrej
> >
> > --
> > 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/db41cf67-acc9-4a84-8267-2742b748de4d%40www.fastmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sympy+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sympy/CAKgW%3D6JExav6cUscxJbv%2B9QhY_S2AP52L9ycNzA%2Be2jtgdGSQQ%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAHVvXxTMoxh6fG8Yb%2B3%3Dgmr1bqt9tQXf_rWMTkLAAThRnW-wyw%40mail.gmail.com.

Re: [sympy] Can SymPy's existing set implementation handle parameterized curves?

[Oscar Benjamin]

Yes, you can do that with ImageSet:

In [11]: ImageSet(Lambda(t, (t, t)), Interval(0, 1))
Out[11]: {(t, t) | t ∊ [0, 1]}

In [14]: ImageSet(Lambda(t, (t**2, t, 1-t)), Interval(0, 1))
Out[14]:
⎧⎛ 2  ⎞ ⎫
⎨⎝t , t, 1 - t⎠ | t ∊ [0, 1]⎬
⎩   ⎭

On Tue, 1 Oct 2019 at 22:58, EKW  wrote:
>
> For example if I wanted to represent the line segment from (0,0) to (1,1) 
> (f(t) = (t, t) for t in (0, 1))- can this be done with an image set? How? Or 
> a curve in 3d space (for example, f(t) = (t^2, t, 1 - t) for t in (0, 1)).
>
> --
> 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/8d96f817-802e-412e-948f-a3fc18361419%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/CAHVvXxSqefKtjfLa-NpVpSQ4NXvBPCKp81kanUkQSrdwU03Nzg%40mail.gmail.com.

Re: [sympy] Re: Can SymPy's existing set implementation handle parameterized curves?

[Oscar Benjamin]

Yeah, a lot of work is needed in sets.

I see that error on master but not on my PR:
https://github.com/sympy/sympy/pull/17593

There it doesn't raise but just returns unevaluated:
In [3]: simplify(a.intersect(b))
Out[3]: {(t, t) | t ∊ [0, 1]} ∩ {(1 - t, t) | t ∊ [0, 1]}

There is no code to handle intersections of this kind of ImageSet yet.

Oscar

On Tue, 1 Oct 2019 at 23:30, EKW  wrote:
>
> OK, I wasn't sure if that was the intended way, since using tuples quickly 
> leads to errors such as:
>
> >>> a = ImageSet(Lambda(t, (t, t)), Interval(0, 1))
> >>> a
> ImageSet(Lambda(t, (t, t)), Interval(0, 1))
> >>> (0,0) in a
> True
> >>> b = ImageSet(Lambda(t, (1 - t, t)), Interval(0, 1))
> >>> b
> ImageSet(Lambda(t, (1 - t, t)), Interval(0, 1))
> >>> a.intersect(b)
> Intersection(ImageSet(Lambda(t, (t, t)), Interval(0, 1)), ImageSet(Lambda(t, 
> (1 - t, t)), Interval(0, 1)))
> >>> simplify(a.intersect(b))
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/home/eward/se/sympy/simplify/simplify.py", line 582, in simplify
> return done(expr)
>   File "/home/eward/se/sympy/simplify/simplify.py", line 541, in done
> rv = e.doit() if doit else e
>   File "/home/eward/se/sympy/core/basic.py", line 1691, in doit
> for term in self.args]
>   File "/home/eward/se/sympy/core/basic.py", line 1691, in 
> for term in self.args]
>   File "/home/eward/se/sympy/sets/fancysets.py", line 460, in doit
> return SetExpr(base_set)._eval_func(f).set
>   File "/home/eward/se/sympy/sets/setexpr.py", line 84, in _eval_func
> res = set_function(func, self.set)
>   File "/home/eward/se/sympy/sets/sets.py", line 2255, in set_function
> return _set_function(f, x)
>   File "/home/eward/se/sympy/multipledispatch/dispatcher.py", line 198, in 
> __call__
> return func(*args, **kwargs)
>   File "/home/eward/se/sympy/sets/handlers/functions.py", line 70, in 
> _set_function
> sing = [i for i in singularities(expr, var)
>   File "/home/eward/se/sympy/calculus/singularities.py", line 83, in 
> singularities
> if not expression.is_rational_function(symbol):
> AttributeError: 'Tuple' object has no attribute 'is_rational_function'
>
> On Tuesday, October 1, 2019 at 2:58:20 PM UTC-7, EKW wrote:
>>
>> For example if I wanted to represent the line segment from (0,0) to (1,1) 
>> (f(t) = (t, t) for t in (0, 1))- can this be done with an image set? How? Or 
>> a curve in 3d space (for example, f(t) = (t^2, t, 1 - t) for t in (0, 1)).
>
> --
> 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/9124ca80-5099-4f44-9441-f82af3f9de12%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/CAHVvXxShAd6W_Uj_vB%3DSYvDStqtPvQy7Z%2B%2BXstofNsP5P2ssPA%40mail.gmail.com.

Re: [sympy] PROPOSAL: ban explicit class constructors in SymPy

[Oscar Benjamin]

I do plan to do this after the next release. There are some details to
work through in making something that works for all of Basic.

The Function model with eval works well but I'm not sure that it would
work for everything else. I think that we need to move the logic that
is currently in __new__ methods into an instance method so that a full
instance is created and then doit is called. The problem with
Function.eval is that it is a class method so it isn't easy for
subclasses to override its behaviour without completely rewriting the
method.

On Fri, 8 Nov 2019 at 22:36, Aaron Meurer  wrote:
>
> This is related to the discussion here
> https://github.com/sympy/sympy/issues/17280.
>
> I like the idea. The implementation of __new__ is often quite
> confusing, and it isn't always clear if you are doing it correctly.
> That's not to mention that most people aren't used to using __new__ in
> Python. We already do basically this for Function subclasses, and it
> works quite well.
>
> I would start by consolidating the __new__ logic and introducing the
> new method (maybe we should reuse the eval() name from Function?).
> Then once we have that working, we can look at adding new automatic
> behavior to __new__ like the things you mentioned.
>
> Aaron Meurer
>
> On Fri, Nov 8, 2019 at 3:21 PM Francesco Bonazzi
>  wrote:
> >
> > Constructors are being overloaded many times in SymPy.
> >
> > The way a constructor is supposed to be written is quite standard, but 
> > there are so many ways they are being written and mis-written.
> >
> > Should we rather replace __new__ with something different (like, for 
> > example, _eval_new?)
> >
> > Advantages:
> >
> > external control over evaluate=True/False,
> > standardized way of creating properties and storing variables,
> > automatic sympification for all args,
> > type checks at construction can be easily introduced.
> >
> > --
> > 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/7270b2d3-f3d6-4f5e-98c8-dec79154f88a%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/CAKgW%3D6L1DPdnGbixKkiReGWfutUWiq%2Btxm0v48nTNX83dLPUjQ%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAHVvXxRoYJYF%2BMcLzj4jCTKc_f07gpHk5X8nCyC9i98%3DnGsT8g%40mail.gmail.com.

Re: [sympy] How to release SymPy more often

[Oscar Benjamin]

On Sun, 17 Nov 2019 at 05:01, Aaron Meurer  wrote:
>
> Thinking more about the automation, I think we need to have the
> release be 100% automated. Right now it is 90% automated (not counting
> the problem of fixing blocker issues).
>
> Oscar, it will be a good idea to make a note of anything in the
> release process that isn't automated that should be.

I will make notes and rewrite the release/README afterwards. To be
honest though the reason it has taken 5 days to get to the point of
having a beta release is actually not because of the *lack* of
automation. It has taken that long because I needed to figure out what
was going on in the release script which is very slow to run and the
only way to try and fix anything is to go through a PR with full
Travis tests etc.

I am in the process of getting the right permissions to be able to use
docker at work which will speed things up but for now I am running
this on a laptop at home with a relatively slow internet connection.
The first time the release script runs it needs to get the docker
containers. Each time the release script runs (and multiple times
within each run) it needs to download a lot of files from conda. It
also runs the whole sympy test suite in between doing the other tasks.

For me right now it takes around 2 hours to run the release script.
Once the script fails it takes about 5 minutes to write the code that
fixes it but that needs to be sent back to github and it takes 1.5
hours to run the tests before they can be merged and the release
script can start again. That means that any issue in the release
script has a 4 hour turn around time to detect the problem and attempt
something to fix it.

What would make all of this faster is if the elements of the release
script were split out as separate scripts that could be tested locally
without going through a PR and docker etc. This is the case for the
mailmap script but not for others like testing the tarball whitelist.

> One thing I forgot about is the release notes. It looks like you already 
> added the
> deprecations. We should figure out how to automate that. Maybe the bot
> can do it.

I've added deprecations that I knew about that weren't listed and I
used git grep to find any deprecation warnings with the 1.5 version.
That can be automated but that only catches things that are
deprecated. The backward compatibility breaks that don't/can't have a
deprecation warning are the more important ones to document here and I
don't see any way to pick up on those automatically.

Perhaps changing the PR template so that there is an explicit backward
compatibility release notes section would help.

> The highlights can't be automated because they are human
> curated, so I think that means those should just be removed. Unless
> there is some way we can do it with the bot as well (maybe by letting
> people tag a PRs notes as a "highlighted note"?).
>
> The AUTHORS/.mailmap isn't automated either. I think they only way
> around that would be to run the authors/mailmap scripts as part of the
> Travis tests, so that we require any PR with a new new author or new
> git metadata to update those files. The main problem with that is that
> it puts an extra burden on new contributors, by definition. So I don't
> know if there's a better way to do it, or if it's worth doing at all.
> It isn't difficult to do and it also can be done at any time, not just
> during a release. Maybe we could add it to the CI but as an allowed
> failure, that way it isn't a requirement to merge, but it will alert
> people when it gets out of date.

Fixing the mailmap isn't a big problem. If we had more regular
releases there wouldn't be so much to update there. It wold be good to
split out the part of the release script that shows the authors though
because that only happens at the end whereas the update_mailmap.py
script runs at the beginning.

> The only other thing I can remember that isn't automated is various
> updates that you have to do to the release script, like updating the
> tarball whitelist. But if we run the script on CI that will not be a
> problem because it will be updated when it needs to be, instead of
> when the release happens.

This is a straight-forward thing to fix but it would be quicker and
easier to do if it could be checked before running the full release
script.

Full automation is a possibility here but I also think that it can be
made a lot more efficient as a mostly automated process.

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/CAHVvXxS9XUS_unw844q4C-jC%2B-4EL6Hd9Gqnj%2BU8rBNUWkRK5A%40mail.gmail.com.

[sympy] SymPy 1.5 Beta 1 released

[Oscar Benjamin]

Hi SymPy users and contributors,

It is my pleasure to announce the *beta release* of SymPy 1.5. This is
is intended for advance testing rather than production use.

I have just made version 1.5b1 available to install as a pre-release
from PyPI. You can install this with

$ pip install --pre sympy

This will not be a long-lasting beta phase. The final release of 1.5
is expected in a few weeks. I hope that making a beta release
available via pip will encourage as many people as possible to try
this out and report any regressions before the final release.

The release notes for SymPy 1.5 can be found here:
https://github.com/sympy/sympy/wiki/Release-Notes-for-1.5

Note that there are some features that are deprecated and also some
changes that are not backwards compatible. We try to ensure backwards
compatibility and to use a deprecation process wherever possible.
However it is not always possible to avoid potentially breaking
changes.

Note also that SymPy 1.5 drops support for Python 3.4 and most
importantly will be the last release of SymPy that supports Python
2.7. This makes it especially important to try and avoid regressions
in this release so I hope that it gets as much pre-release testing as
possible.

Issues with the release should be reported on Github (make sure to
specify if the issue is a regression since 1.4):
https://github.com/sympy/sympy/issues

The SHA256 hashes for the release files are:
ce87ab3ffe55ba1954fafdfa53980b247aa7390bb9bde169a4163a696873c368
sympy-1.5b1-py2.py3-none-any.whl
62fa5cd81d4afc62535657b1edf2132d08806c677a4e787c8f0f095d49d848ff
sympy-1.5b1.tar.gz

Happy testing,
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/CAHVvXxQmfyrxZU82rAq2oBc8Dse43wAwKaqjv8M-mk_zD76Q_A%40mail.gmail.com.