[sympy] Reviewing PRs and old SymPy issues
Hi all, There are currently a large number of new contributors opening various pull requests and commenting on issues in the SymPy repo. This is great to see, and I want to thank everyone who has been contributing. I would like to highlight though that opening pull requests is not the only way to contribute to SymPy. There are many other ways to contribute. In fact more important than opening pull requests is *reviewing* pull requests and issues. For example if you can see that a pull request likely needs some changes, then it is helpful to comment on the pull request and suggest what changes are needed until it looks ready to merge. I am sure that some of the new contributors could tell quite quickly what changes would be needed in many of the recently opened pull requests. In fact one of the most useful things that a relatively new contributor can do is to review old issues. The SymPy repo currently has over 4000 open issues. Many of these are old and are no longer relevant or already fixed. You can often review these issues just by testing the code in them. If the issue seems to be fixed then a pull request with a test could be opened to close the issue. If you do want to review old issues then I suggest using the issue labels to focus on a particular area of the code base like "integrals" or "solvers" etc. This sort of work is actually much more helpful to the project than opening pull requests for "easy to fix" issues. -- 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/CAHVvXxQFLH7L%3DjO8EosasVETJn1fCmWaCvbYp%3DMbxvQmg1pB9Q%40mail.gmail.com.
Re: [sympy] Proposal for Enhancements to the Pow Class in SymPy
On Sat, 2 Mar 2024 at 17:16, Mariyala Rohith wrote: > > Dear Sympy Mentors, > > I hope this message finds you well! > I am writing to propose a couple of enhancements to the Pow class > in SymPy that I believe could extend its functionality and usefulness. > > 1. Roots of Unity: I propose to add a method to the Pow class that checks > if an expression represents a root of unity. This would involve checking if a > complex number, when raised to some positive integer power, equals 1. This > feature could be useful in various areas of mathematics, including numbers > theory and algebra. There is already a way to do this in SymPy although it is perhaps not obvious: In [52]: is_root_of_unity = lambda e: minpoly(e, polys=True).is_cyclotomic In [53]: is_root_of_unity(-sqrt(5)/4 - S(1)/4 - I*sqrt(S(5)/8 - sqrt(5)/8)) Out[53]: True In [54]: is_root_of_unity(sqrt(5)) Out[54]: False 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/CAHVvXxSiR9VRR1b%2Bq%2BmOf8g%3DLVhj9LuGCNBM_FsoSUaKGhqFyA%40mail.gmail.com.
Re: [sympy] Add some links to README.md
You don't need to worry about those errors. They are not related to the changes in your PR and any PR can be merged even if those tests fail. It looks like those same errors are showing on all PRs right now. The errors that you see are in the numpy nightly test job. This is a job that runs the sympy tests with both numpy and scipy installed from their nightly wheel build. I added these tests because the upcoming release of numpy 2.0 is likely to break some things that sympy depends on. The jobs are currently failing most likely because of a change in numpy or scipy rather than any change in sympy. I just tried installing the nightly builds locally and running the matrices tests and I see one failure in test_issue_14943: > assert array(M, dtype=float).dtype.name == 'float64' E TypeError: MatrixBase.__array__() got an unexpected keyword argument 'copy' It looks like numpy now passes copy= when calling __array__ but sympy's Matrix.__array__ method does not expect the copy argument. My guess is that this is coming from here: https://github.com/numpy/numpy/pull/25168 There is already a numpy issue about this: https://github.com/numpy/numpy/issues/25916 That error is still not the segfault seen in CI though... On Sun, 3 Mar 2024 at 11:09, Spiros Ts wrote: > > Author: Spiros Tsioupros > Github: https://github.com/Spiros7bit > email: tsiouprosspi...@gmail.com > > Hello community, I made a pull request to add some links to README.md. While > 63/68 checks are passed, 5 errors about test and test_optional_dependencies > are thrown. I had read in the Development Workflow Process that we should > write tests when making pull requests for code changes. > > My question is: Do we have to write a test when we make changes to README.md > or is the problem elsewhere? > > pull request link is here. > > Yours sincerely. > > -- > 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/0d348c35-8350-4f7c-a787-89d7ac7ea89fn%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/CAHVvXxRMwf8eyiCKJ7jCdXVqv64zNzj_7g%3D8Ha_FEaOm9YgwHg%40mail.gmail.com.
[sympy] In memory of Kalevi Suominen
Hi all SymPy community, It is with great sadness that I bring the news that Kalevi Suominen (@jksuom on GitHub) passed away on the 4th of March. Kalevi's son Risto passed on this news to me and some others by email yesterday. I never met Kalevi in person but we had many conversations online over many years. Kalevi was an outstanding SymPy contributor and was involved with the project long before me and so there are others here who have known him much longer than I have. Kalevi guided many SymPy contributors and supervised many GSOC students over many years. Looking in the git history his earliest commit was from almost exactly 10 years ago. Personally I learnt a huge amount from Kalevi and I am very grateful for the time he took to teach me and others and to guide the project generally. Kalevi's expertise in many areas of Mathematics and across the full depth of many parts of the SymPy codebase was unmatched within the community. Interacting through GitHub I guess that many of us did not realise that Kalevi's health was in decline. He continued to be involved including most recently reviewing a pull request just 6 weeks ago. A few weeks ago he sent me some files with what he was most recently working on but was no longer able to finish. I will try to complete that work and submit it as Kalevi's final pull request. Kalevi's passing is a huge loss to SymPy but I don't want to dwell on that. Instead I invite those of us who have known Kalevi to share their thoughts and memories 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 view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxTRWVQp_N_0%3DNnf-yBJwSu373sw-NB7UKuZCks2HTHGaA%40mail.gmail.com.
Re: [sympy] Addin sympy to SPEC 0?
Hi Anton, What difference does it make to you in practice whether or not SymPy is listed in SPEC 0? SymPy does not really support old versions with maintenance releases so it does not really have a "support cycle" in the sense that SPEC 0 seems to describe. There can be a bugfix release shortly after a feature release to fix some obvious regressions but that is basically it. SymPy itself broadly tries to have wide version support for other packages like numpy just because without listing them as hard dependencies there is no way to indicate which versions sympy is compatible with. There is no way to put version constraints on optional dependencies in pip/PyPI land. Oscar On Sun, 10 Mar 2024 at 14:24, Anton Akhmerov wrote: > > Hi all, > > There is now SPEC 0, a SciPy-community-wide standard for versions of > different packages that developers should aim supporting, see > https://scientific-python.org/specs/spec-/ > > I believe Sympy is the biggest package missing from SPEC 0, and I've asked > the maintainers of SPEC 0 what is the best way to proceed > (https://discuss.scientific-python.org/t/spec-0-include-sympy/975?u=akhmerov). > They appear to welcome the idea and recommended to reach out via this > mailing list. > > So here's the question I'd like to know (as someone authoring software that > depends on Sympy): would Sympy like to join SPEC 0? > > Thank you for your consideration, > Anton > > -- > 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/e21d2db6-8ac4-4b01-a92c-7e49eb591146n%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/CAHVvXxS%2Bh1foa1G3dfKA58Osp%3D%3DZ9W69gjRygjzphkcstqTarw%40mail.gmail.com.
Re: [sympy] Addin sympy to SPEC 0?
Hi Anton, To be clear I am not against adding SymPy to SPEC 0. I just want to understand what this means in practice. Presumably if SymPy is added there then people will have some expectation that it means something somehow. I don't really know how to answer the question "which versions of SymPy should I try to support within my package that has SymPy as a dependency" because I am not sure what the benefit would be of supporting more than 1 version of SymPy. Is there a reason that someone would need to combine a newer version of your package with an older version of SymPy? Oscar On Sun, 10 Mar 2024 at 15:18, Anton Akhmerov wrote: > > Hi Oscar, > > I want to be able to answer a question: "which versions of SymPy should I try > to support within my package that has SymPy as a dependency". It doesn't make > a big difference whether this question is answered by SPEC 0 or by SymPy > itself, except for SPEC 0 being a central point of reference. I realized that > SymPy has no support cycle, but I think the question is still useful > regardless. > > Anton > On Sunday 10 March 2024 at 15:48:13 UTC+1 Oscar wrote: >> >> Hi Anton, >> >> What difference does it make to you in practice whether or not SymPy >> is listed in SPEC 0? >> >> SymPy does not really support old versions with maintenance releases >> so it does not really have a "support cycle" in the sense that SPEC 0 >> seems to describe. There can be a bugfix release shortly after a >> feature release to fix some obvious regressions but that is basically >> it. >> >> SymPy itself broadly tries to have wide version support for other >> packages like numpy just because without listing them as hard >> dependencies there is no way to indicate which versions sympy is >> compatible with. There is no way to put version constraints on >> optional dependencies in pip/PyPI land. >> >> Oscar >> >> On Sun, 10 Mar 2024 at 14:24, Anton Akhmerov wrote: >> > >> > Hi all, >> > >> > There is now SPEC 0, a SciPy-community-wide standard for versions of >> > different packages that developers should aim supporting, see >> > https://scientific-python.org/specs/spec-/ >> > >> > I believe Sympy is the biggest package missing from SPEC 0, and I've asked >> > the maintainers of SPEC 0 what is the best way to proceed >> > (https://discuss.scientific-python.org/t/spec-0-include-sympy/975?u=akhmerov). >> > They appear to welcome the idea and recommended to reach out via this >> > mailing list. >> > >> > So here's the question I'd like to know (as someone authoring software >> > that depends on Sympy): would Sympy like to join SPEC 0? >> > >> > Thank you for your consideration, >> > Anton >> > >> > -- >> > You received this message because you are subscribed to the Google Groups >> > "sympy" group. >> > To unsubscribe from this group and stop receiving emails from it, send an >> > email to sympy+un...@googlegroups.com. >> > To view this discussion on the web visit >> > https://groups.google.com/d/msgid/sympy/e21d2db6-8ac4-4b01-a92c-7e49eb591146n%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/abcea775-f3aa-45c0-883e-ceec9482cc6cn%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/CAHVvXxRk_ZZmbXig0fTJ3rQ_dn0Ecu4FfO_Nv9qG%3Dzd9Jy8AWg%40mail.gmail.com.
Re: [sympy] SymPy, Flint, and sparse polynomial representations
Hi Jake, I would be happy to meet (online) with you and your supervisor at some point if that helps. Oscar On Tue, 12 Mar 2024 at 11:49, Jake Moss wrote: > > Thank you for such a detailed reply! Seems like there will be plenty for me > to do. > > I'll reach out to David Einstein on GitHub later this week after meeting with > my supervisor and solidifying a plan of sorts. > > Regards, > Jake > > On Monday, March 11, 2024 at 11:45:33 PM UTC+10 Oscar wrote: > > On Mon, 11 Mar 2024 at 13:06, Jake Moss wrote: > > > > Hi, > > Hi Jake, > > > I'm looking at SymPy and Flint, and their sparse polynomial representations > > under the direction of my supervisor for an Honours thesis at the > > University of Queensland, Australia and I was wondering about the status of > > the existing integrations of Flint and recommendations from Oscar > > Benjamin's blog posts. > > That would be fantastic. > > > I've seen that SymPy is now able to use Flint as the ground type for dense > > univariate polynomials from PR #25722. Is there a similar PR for > > multivariate polynomials? I haven't seen one myself but perhaps it is > > hiding from me. I assume any integration work is pending the merging of > > Adding Fmpz mpoly #59 on python-flint. Is this PR blocked? > > The current status is that SymPy can use Flint for: > > - The ground domains ZZ, QQ and GF(p). > - Dense univariate polynomials over ZZ, QQ. > - Dense matrices over ZZ and QQ. > - Dense rational functions over ZZ and QQ. > - Algebraic number fields like QQ(sqrt(2)). > > There is a PR to use of Flint for polynomials and matrices over GF(p) > here for which I am waiting review: > > https://github.com/sympy/sympy/pull/25940 > > Currently python-flint does not expose any of Flint's multivariate > polynomial types so it is not possible for SymPy to use them yet. The > PR that you have identified is by David Einstein: > > https://github.com/flintlib/python-flint/pull/59 > > The PR is not blocked. I think that David just has not found the time > to complete it yet. I have been intending to take over when I could > find time. Don't let either of us stop you if you want to have a go at > it though. I am sure that David won't mind (although best to mention > something on the PR if you are going to start work on it). > > > Additionally is there any on going work on the sparse polynomial > > representations? From the existing PRs and Flints documentation I've only > > been able to find mention of sparsity in the gr_mpoly_t section, which is > > not mentioned in any of the pending PRs that I've seen. > > Perhaps "sparse" is the wrong term to use here. In SymPy there are > sparse and dense polynomial representations. The corresponding Flint > types are called fmpz_mpoly etc with m for "multivariate". The > intention would be to use Flint's multivariate polynomials in SymPy in > place of SymPy's sparse and dense multivariate polynomials. > > Specifically there are two wrapper classes that I would want to have > to adapt the Flint types at different levels within SymPy: > > One would be an analogue of the DUP_Flint type which is for Flint's > univariate polynomials to have something like DMP_Flint for > multivariate polynomials (see sympy/polys/polyclasses.py). These would > be used by SymPy's Poly as the internal type when the domain is > something that is supported by python-flint (currently ZZ, QQ or > GF(p)). > > The other place we would want to use Flint's mpoly types is for > polynomial ring domains like QQ[x,y] etc. In this case we would want a > wrapper class that provides an interface that is compatible with > SymPy's PolyElement type. Then SymPy could make use of Flint at the > domain level as well as the Poly level. > > That would be the simplest way for SymPy to use python-flint's > multivariate polynomials. Longer term it might be better to have a > general refactor of all of this code to make it more suitable for a > design that can swap Flint in and out. > > > Is this type of work of interest? If it is I'd be happy to pick up the Fmpz > > mpoly python-flint PR and work on integrating that into SymPy. I have > > plenty of (painful) experience with Cython and integrating it with existing > > C and Python libraries from my day job. > > Yes, this is absolutely of interest. I agree that Cython is sometimes > painful... > > > As this would be part of a year long thesis I'd also be interested in there > > are any more research-y type questions in this area. I'm currently > > considering an analysis of SymPys existing systems and comparison to Flints > > along side some profiling and investigation into Flints cache efficiency > > and current areas for improvement from a HPC side but am open to other > > ideas. > > There are all sorts of things that could be done here both in terms of > implementation and research. There are many more things in Flint that > are not exposed in python-flint and there are many more parts of SymPy > that would be improved
Re: [sympy] SymPy, Flint, and sparse polynomial representations
On Mon, 11 Mar 2024 at 13:06, Jake Moss wrote: > > Hi, Hi Jake, > I'm looking at SymPy and Flint, and their sparse polynomial representations > under the direction of my supervisor for an Honours thesis at the University > of Queensland, Australia and I was wondering about the status of the existing > integrations of Flint and recommendations from Oscar Benjamin's blog posts. That would be fantastic. > I've seen that SymPy is now able to use Flint as the ground type for dense > univariate polynomials from PR #25722. Is there a similar PR for multivariate > polynomials? I haven't seen one myself but perhaps it is hiding from me. I > assume any integration work is pending the merging of Adding Fmpz mpoly #59 > on python-flint. Is this PR blocked? The current status is that SymPy can use Flint for: - The ground domains ZZ, QQ and GF(p). - Dense univariate polynomials over ZZ, QQ. - Dense matrices over ZZ and QQ. - Dense rational functions over ZZ and QQ. - Algebraic number fields like QQ(sqrt(2)). There is a PR to use of Flint for polynomials and matrices over GF(p) here for which I am waiting review: https://github.com/sympy/sympy/pull/25940 Currently python-flint does not expose any of Flint's multivariate polynomial types so it is not possible for SymPy to use them yet. The PR that you have identified is by David Einstein: https://github.com/flintlib/python-flint/pull/59 The PR is not blocked. I think that David just has not found the time to complete it yet. I have been intending to take over when I could find time. Don't let either of us stop you if you want to have a go at it though. I am sure that David won't mind (although best to mention something on the PR if you are going to start work on it). > Additionally is there any on going work on the sparse polynomial > representations? From the existing PRs and Flints documentation I've only > been able to find mention of sparsity in the gr_mpoly_t section, which is not > mentioned in any of the pending PRs that I've seen. Perhaps "sparse" is the wrong term to use here. In SymPy there are sparse and dense polynomial representations. The corresponding Flint types are called fmpz_mpoly etc with m for "multivariate". The intention would be to use Flint's multivariate polynomials in SymPy in place of SymPy's sparse and dense multivariate polynomials. Specifically there are two wrapper classes that I would want to have to adapt the Flint types at different levels within SymPy: One would be an analogue of the DUP_Flint type which is for Flint's univariate polynomials to have something like DMP_Flint for multivariate polynomials (see sympy/polys/polyclasses.py). These would be used by SymPy's Poly as the internal type when the domain is something that is supported by python-flint (currently ZZ, QQ or GF(p)). The other place we would want to use Flint's mpoly types is for polynomial ring domains like QQ[x,y] etc. In this case we would want a wrapper class that provides an interface that is compatible with SymPy's PolyElement type. Then SymPy could make use of Flint at the domain level as well as the Poly level. That would be the simplest way for SymPy to use python-flint's multivariate polynomials. Longer term it might be better to have a general refactor of all of this code to make it more suitable for a design that can swap Flint in and out. > Is this type of work of interest? If it is I'd be happy to pick up the Fmpz > mpoly python-flint PR and work on integrating that into SymPy. I have plenty > of (painful) experience with Cython and integrating it with existing C and > Python libraries from my day job. Yes, this is absolutely of interest. I agree that Cython is sometimes painful... > As this would be part of a year long thesis I'd also be interested in there > are any more research-y type questions in this area. I'm currently > considering an analysis of SymPys existing systems and comparison to Flints > along side some profiling and investigation into Flints cache efficiency and > current areas for improvement from a HPC side but am open to other ideas. There are all sorts of things that could be done here both in terms of implementation and research. There are many more things in Flint that are not exposed in python-flint and there are many more parts of SymPy that would be improved by making more use of domains, Poly etc. Once SymPy has Flint's multivariate polynomials for the polynomial domains that means that SymPy's DomainMatrix will use Flint for matrices with polynomial or rational functions entries. Most algorithms for Matrix and DomainMatrix can be reworked and there is plenty to explore in terms of best algorithms, benchmarking etc. Another thing that SymPy should do is build a new implementation of algebraic number fields based on multivariate polynomials and Groebner bases rather than univariate polynomials and primitive elements. Similar approaches can be used to handle things like QQ[sin(x),cos(x)]
Re: [sympy] In memory of Kalevi Suominen
Hi Jason, I checked with Kalevi's son just to be sure and yes, that is the same Kalevi. He completed his PhD in 1966: https://www.genealogy.math.ndsu.nodak.edu/id.php?id=20539=1 Then after a long career teaching Mathematics at the University of Helsinki he got involved with SymPy development as a retired Maths professor. Given his breadth of knowledge I had always assumed that his background was something like this although I never thought to go and look it up. Oscar On Sun, 10 Mar 2024 at 16:59, Jason Moore wrote: > > Hi Oscar, > > That is very sad to hear. I did not know Kalevi other than through SymPy but > it looks like he was an Emeritus mathematics professor from the University of > Helsinki. This page shows a photo of him: > > https://wiki.helsinki.fi/xwiki/bin/view/mathstatHenkilokunta/Henkil%C3%B6t/Suominen%2C%20Kalevi/ > > His contributions to SymPy will live on. I believe he mentored GSoC students. > If anyone knows more about Kalevi and can share, that would be much > appreciated. > > Sincerely, > > Jason > moorepants.info > +01 530-601-9791 > > > On Sun, Mar 10, 2024 at 5:31 PM Oscar Benjamin > wrote: >> >> Hi all SymPy community, >> >> It is with great sadness that I bring the news that Kalevi Suominen >> (@jksuom on GitHub) passed away on the 4th of March. Kalevi's son >> Risto passed on this news to me and some others by email yesterday. >> >> I never met Kalevi in person but we had many conversations online over >> many years. Kalevi was an outstanding SymPy contributor and was >> involved with the project long before me and so there are others here >> who have known him much longer than I have. Kalevi guided many SymPy >> contributors and supervised many GSOC students over many years. >> Looking in the git history his earliest commit was from almost exactly >> 10 years ago. >> >> Personally I learnt a huge amount from Kalevi and I am very grateful >> for the time he took to teach me and others and to guide the project >> generally. Kalevi's expertise in many areas of Mathematics and across >> the full depth of many parts of the SymPy codebase was unmatched >> within the community. >> >> Interacting through GitHub I guess that many of us did not realise >> that Kalevi's health was in decline. He continued to be involved >> including most recently reviewing a pull request just 6 weeks ago. A >> few weeks ago he sent me some files with what he was most recently >> working on but was no longer able to finish. I will try to complete >> that work and submit it as Kalevi's final pull request. >> >> Kalevi's passing is a huge loss to SymPy but I don't want to dwell on >> that. Instead I invite those of us who have known Kalevi to share >> their thoughts and memories 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 view this discussion on the web visit >> https://groups.google.com/d/msgid/sympy/CAHVvXxTRWVQp_N_0%3DNnf-yBJwSu373sw-NB7UKuZCks2HTHGaA%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/CAP7f1AgzKoA5-P_OH0GZwFOjd4M5ipFPVV14RgSaHL73qwxYCQ%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/CAHVvXxTuJA%2BMZ7ZJs0piPCeJkDipoeLaQuGnE6k_kSJZjqHM5Q%40mail.gmail.com.
Re: [sympy] SymPy Wedge Product Question
I don't know enough about this topic bur there is also galgebra which
is a library that depends on SymPy:
https://galgebra.readthedocs.io/en/latest/tutorials/algebra.html
Does that do what is needed?
On Sun, 28 Apr 2024 at 09:37, 'Carsten' via sympy
wrote:
>
> HI,
>
> I almost do not follow this mailing list since a while but I just stumbled on
> this thread.
>
> Several years ago I had some trouble in learning to calculate with
> differential forms and and back then the sympy support was not sufficient for
> me (dont know about the current state). Thus I implemented my own package (on
> top of sympy): "pycartan" [1]. As it is typical for research code, it served
> its purpose (doing some calculations related to control theory), and after
> this it lays around without attention (and with almost no docs).
>
> Maybe it is still useful for some people. Unfortunately the "best"
> documentation available for this package is the collection of unittests [2].
>
> If there is serious interest in this package I might be motivated to put some
> time/effort in it. For reaching out I suggest to contact me via [3].
>
> [1] https://github.com/TUD-RST/pycartan/
> [2]
> https://github.com/TUD-RST/pycartan/blob/master/pycartan/tests/test_pycartan.py
> [3] https://wwwpub.zih.tu-dresden.de/~knoll/en/
>
> Best,
> Carsten
>
> Gesendet: Dienstag, 26. März 2024 um 19:37 Uhr
> Von: "Tomás Silva"
> An: "sympy"
> Betreff: Re: [sympy] SymPy Wedge Product Question
> I'm facing a similar issue. I think SymPy is not treating correctly the sum
> of (co)vectors.
> In this question I exemplify my issue
> https://stackoverflow.com/questions/78226587/sympy-manipulation-of-wedge-products
> Could anyone shed a light on how to properly sum differential forms?
> Thanks in advance,
> Tomás
> On Monday, March 25, 2024 at 12:06:45 AM UTC Samith Kavishke wrote:
>>
>> I could not find the problem that you are stating in the video lecture
>>
>> On Thursday, March 21, 2024 at 9:21:52 PM UTC+5:30 kushwahas...@gmail.com
>> wrote:
>>>
>>> Can you please specify what purpose you are using it for. I do not know its
>>> use yet but would like to get back to you after researching on its usage .
>>>
>>> _ _ _ _ _ _ _
>>> Shishir
>>>
>>> On Tuesday 19 March 2024 at 22:54:42 UTC+5:30 giovanni...@gmail.com wrote:
Can anyone help me with this, please?
On Mon, Mar 11, 2024, 06:06 Giovanni Sutanto wrote:
>
> Hi SymPy Community,
>
> I am now trying to understand what happens when I perform WedgeProduct
> operations on SymPy.
>
> So, I understand how to use the SymPy's Wedge Product to some extent,
> i.e. I was the one who responded to the question on Stack Overflow:
> https://stackoverflow.com/questions/76981303/computing-the-wedge-product
>
> However, when I have:
> '''
> my_matrix = Matrix([[2, 0, 5], [0, 7, 0]])
> r2_r_oneforms = R2_r.base_oneforms()
> r2_r_vectors = R2_r.base_vectors()
>
> cols = [None] * 3
> for j in range(3):
> cols[j] = 0
> for i in range(2):
> cols[j] += my_matrix[i, j] * r2_r_vectors[i]
>
> cols_wedge_product = WedgeProduct(*r2_r_oneforms)(*cols)
> print('cols_wedge_product = ', cols_wedge_product)
> '''
> What I get is:
> cols_wedge_product = -42
>
> Where does the number -42 come from?
>
> On the other hand, if:
> my_matrix = Matrix([[1, 0, 1], [0, 1, 0]])
> I get:
> cols_wedge_product = 0
> What computation leads to 0 here?
>
> Can any of you please explain it, e.g. in the terms of the example in the
> video lecture https://youtu.be/xRf9-hdxB0w?feature=shared=2961 ?
>
> Thanks so much in advance for your time!
>
>
> Best Regards,
>
> Giovanni
>
>
>
> --
> 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/-MAK_y6-9Yc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> sympy+un...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/b7fb6f7e-232d-4414-b938-1cdbab35cd76n%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/fabd8204-3f56-4aed-b8e4-065f2d361ba0n%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
>
