Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 12 2022 01:39

    anutosh491 on GSoC_Pr4.2_Implementing_leading_term_and_series_methods_for_the_frac_function

    (compare)

  • Sep 11 2022 12:19

    anutosh491 on GSoC_Pr4.2_Implementing_leading_term_and_series_methods_for_the_frac_function

    Implemented leading term and ns… (compare)

  • Sep 10 2022 03:21

    anutosh491 on GSoC_Pr4.2_Implementing_leading_term_and_series_methods_for_the_frac_function

    made changes (compare)

  • Sep 08 2022 06:28

    anutosh491 on GSoC_Pr4.2_Implementing_leading_term_and_series_methods_for_the_frac_function

    added tests for leading terms f… (compare)

  • Sep 08 2022 03:43

    anutosh491 on GSoC_Pr4.2_Implementing_leading_term_and_series_methods_for_the_frac_function

    Changed the outputs being retur… (compare)

  • Sep 07 2022 09:34

    anutosh491 on GSoC_Pr4.2_Implementing_leading_term_and_series_methods_for_the_frac_function

    Changed leading term being ret… (compare)

  • Sep 07 2022 07:27

    anutosh491 on GSoC_Pr4.2_Implementing_leading_term_and_series_methods_for_the_frac_function

    Removed Redundant block from le… (compare)

  • Sep 07 2022 02:44

    anutosh491 on GSoC_Pr4.3_Implementing_some_series_method_for_uppergamma_lowergamma_expint_and_other_errors_functions

    Implemented some series methods… (compare)

  • Sep 06 2022 16:44

    anutosh491 on GSoC_Pr4.2_Implementing_leading_term_and_series_methods_for_the_frac_function

    Removed Order term (compare)

  • Sep 06 2022 11:39

    anutosh491 on GSoC_Pr4.2_Implementing_leading_term_and_series_methods_for_the_frac_function

    added test cases for limits and… (compare)

  • Sep 06 2022 10:51

    anutosh491 on GSoC_Pr4.2_Implementing_leading_term_and_series_methods_for_the_frac_function

    Implemented leading term and ns… (compare)

  • Sep 06 2022 10:40

    anutosh491 on GSoC_Pr4.1_Implementing_few_series_methods_for_bessel_functions

    (compare)

  • Sep 06 2022 04:13

    anutosh491 on GSoC_Pr4.1_Implementing_few_series_methods_for_bessel_functions

    This commit does the following … Refactored mrv_leadterm in grun… Fixed errors arising for limits… and 3 more (compare)

  • Sep 06 2022 02:08

    anutosh491 on GSoC_Pr4.1_Implementing_few_series_methods_for_bessel_functions

    fix(integrals): handle degenera… functions: Generalised Dirichle… author: update Megan Ly in .mai… and 23 more (compare)

  • Sep 05 2022 14:16

    anutosh491 on GSoC_Pr4.1_Implementing_few_series_methods_for_bessel_functions

    Changed if condition for bessel… (compare)

  • Sep 05 2022 02:49

    anutosh491 on GSoC_Pr4.1_Implementing_few_series_methods_for_bessel_functions

    Improved code quality (compare)

  • Sep 03 2022 10:24

    anutosh491 on GSoC_Pr4.1_Implementing_few_series_methods_for_bessel_functions

    changed is function to equality… (compare)

  • Sep 03 2022 10:14

    anutosh491 on GSoC_Pr4.1_Implementing_few_series_methods_for_bessel_functions

    fixed failing tests (compare)

  • Sep 01 2022 12:23

    anutosh491 on GSoC_Pr4.1_Implementing_few_series_methods_for_bessel_functions

    Fixed code quality (compare)

  • Sep 01 2022 12:00

    anutosh491 on GSoC_Pr4.1_Implementing_few_series_methods_for_bessel_functions

    Added case where number of term… (compare)

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
no
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
Kalevi Suominen
@jksuom
I think that metrics should not be built into indices. Contraction (covariant -- contravariant) is independent of metric. If metrics are needed, they could be introduced explicitly.
Francesco Bonazzi
@Upabjojr
@jksuom we have to distinguish the case of symmetric and anti-symmetric metrics. Anti-symmetric metrics are currently supported. They create two different kinds of contractions. The tensor module has a tensor canonicalization algorithm, that is sensible to the symmetry/antisymmetry/asymmetry of the metric.