sympy/sympy

A computer algebra system written in pure Python http://sympy.org/ . To get started to with contributing https://github.com/sympy/sympy/wiki/Introduction-to-contributing

Ayushman Koul

@ayushmankoul

Hello @jksuom @asmeurer @moorepants I would like to work on this sympy/sympy#15178.Please let me know how can we check the actual speed of execution of these methods and do we need to alter the code for solve method so it does not return inverse of matrix ?

(Lazard) S.Y. Lee

@sylee957

@sudz123
I had introduced some changes to test_plot.pyrecently, but I am unsure about your issue though.
I think you should open up a new issue about that, before any new bumps on this thread shadows.

Sudarshan Kamath

@sudz123

Sure @sylee957 I'll open up an issue.

Aaron Meurer

@asmeurer

@sylee957 we don't really have mock tests in SymPy. It's better to just test the behavior, via some input that failed before but works now.

Unless it is just a performance improvement. In that case, you can add a benchmark to the benchmarks repo. Or if it's a major improvement you can add a test that runs quickly without the improvement but would hang without the improvement, so any regression would easily be noticed.

Henry S. Harrison

@hsharrison

Hi, I've been getting this error with autowrap using the f2py backend:

error: Command "/usr/bin/gfortran -Wall -g -fno-second-underscore -fPIC -O3 -funroll-loops -I/tmp/tmps06bd4m5/src.linux-x86_64-3.7 -I/home/hen/miniconda/envs/py37/lib/python3.7/site-packages/numpy/core/include -I/home/hen/miniconda/envs/py37/include/python3.7m -c -c wrapped_code_1.f90 -o /tmp/tmps06bd4m5/wrapped_code_1.o" failed with exit status 1
wrapped_code_1.f90:54:13:

 REAL*8 :: Mod
             1
Error: Symbol ‘mod’ at (1) already has basic type of REAL

I was in here a couple months ago and it was suggested it could be a Windows issue, so I finally tried it out on Linux. Same problem

I tracked it down to a duplicated line in the generated code

...
REAL*8, parameter :: pi = 3.1415926535897932d0
REAL*8 :: Mod
REAL*8 :: Mod
...

So, I guess my questions are: where to look in SymPy for the source of this problem? Probably over my head to try to fix it, I have zero familiarity with the interals, but I could try.

Or, what's the easiest way to work around this, i.e. intercept the code and modify it before the compilation step

Any advice would be appreciated

Aaron Meurer

@asmeurer

Looks like a bug in the code generator if that's invalid fortran

Jason K. Moore

@moorepants

@hsharrison I suggest opening an issue on the sympy repository with the input sympy expression that causes this. Include example input and output.

Srinidhi Krishna

@kss682

Hi, I am new to sympy . I have worked with python and know basic mathematics .How can I get started? Thanks

Kalevi Suominen

@jksuom

@kss682 This is for getting started.

Srinidhi Krishna

@kss682

@jksuom Thanks.

Yathartha Joshi

@Yathartha22

Git Query:
How do I rebase my branch (say test) built on top of master to 1.3. Seems git rebase 1.3 does not work.

Henry S. Harrison

@hsharrison

@moorepants thanks, done. #15230

Aaron Meurer

@asmeurer

@Yathartha22 you have to use the --onto flag. I can never remember which branch goes where. If you look at the --onto section git help rebase you can figure it out.

Or if it's just one commit it's easier to just create a new branch off of 1.3 and cherry-pick it.

Yathartha Joshi

@Yathartha22

Alright thanks @asmeurer I will have a look at it.

Sidhant Nagpal

@sidhantnagpal

Is it possible to specify keyword arguments for Function evaluation?
For example, computing bell(6, 2, symbols('x:6')[1:]) by including keywords k_sym and symbols.
(The eval method for bell has the signature def eval(cls, n, k_sym=None, symbols=None).)

Kalevi Suominen

@jksuom

It is not possible (because of this). It seems that k_sym and symbols should be considered as parameters with a default value, not as keyword parameters.

Sidhant Nagpal

@sidhantnagpal

Right. The context was actually if stirling should be a class inheriting from Function. Since, it is not possible to include kwargs while Function evaluation, the interpretation of args might become harder for stirling, if it is made a class.

Aaron Meurer

@asmeurer

Would those flags just affect the evaluation or should they be stored in the args?

Sidhant Nagpal

@sidhantnagpal

They could be stored as args but calls like stirling(8, 5, kind=1), stirling(8, 5, kind=2, signed=True) might no longer work.

Francesco Bonazzi

@Upabjojr

In SymPy we have many different representations for arrays and tensors

I'm currently pondering on an API to connect them

do you think that the current .rewrite( ) API is good enough?

Kalevi Suominen

@jksuom

I was looking at your PR on latex printing. Have you tested how LaTeX will deal with latex(H(i, j)) which becomes 'H^{i}^{j}'?

Francesco Bonazzi

@Upabjojr

I'm actually fixing that PR

In [9]: latex(H(i, j))
Out[9]: 'H^{i}^{j}'

do you think I should change it?

Kalevi Suominen

@jksuom

I don't know. Maybe it will work OK.

Francesco Bonazzi

@Upabjojr

I know chemical elements have forms like {}^6 H

You're right

! Double superscript.
l.6 H^{i}^
          {j}

Aaron Meurer

@asmeurer

rewrite will work if it's a simple transformation between the types

Francesco Bonazzi

@Upabjojr

the problem arises when the transformation is not between types

Francesco Bonazzi

@Upabjojr

Do you think it makes sense to extend the new assumptions module for assumptions on symmetry/antisymmetry and similar stuff?

the current tensor module is really overloaded by ad-hoc types and properties, I was wondering whether the usage of external assumptions could help to make the API simpler.

Kalevi Suominen

@jksuom

I would try to work with tensor indices having no type info other than co/contravariance. The class TensorIndexType seems of limited utility to me and could probably be deprecated. The symmetry properties could be indicated by giving disjoint subsets of indices with respect to which the tensor is symmetric or alternating. Such properties do not fit well in the general assumptions scheme.

Francesco Bonazzi

@Upabjojr

TensorIndexType is mainly used to distinguish between tensors and spinors. Tensor contractions behave symmetrically (i.e. A^i_i = A_i^i), while spinor contractions are antisymmetrical (i.e. A^i_i = -A_i^i).

If we abolish TensorIndexType, I'm not sure where to add this information

Kalevi Suominen

@jksuom

Maybe there could also be SpinorIndex class?

Francesco Bonazzi

@Upabjojr

There is also the case of indices without specified metric, for which no assumptions between the two types of contraction exists.

I was also pondering on removing TensorIndex itself, as it make the API kind of complicated to use.

or maybe even using existing assumptions, like Symbol("i", commutative=False) for indices for which A^i_i != A_i^i

Where communities thrive

People

Repo info

Activity