Re: [sympy] Doubt Regarding .mailmap file
Yes i forgot to sync with the upstream before creating the changes , It is solved now . Thank you for your time and help . On Saturday 3 February 2024 at 04:01:06 UTC+5:30 Oscar wrote: > It's hard to tell from a screenshot. Do you have a link to the PR? > > On Fri, 2 Feb 2024 at 17:36, Shishir Kushwaha > wrote: > > > > Do I need to add my details everytime to thee .mailmap file when making > a PR , I did it in my first PR as mentioned in the documentation but when > creating a new comitt on another issue , the authro test was failing even > though my name is there in the file already . Any idea why this could > happen? > > > > > > -- > > 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/d9705b06-6ca2-49af-9648-e0f23499a6b7n%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/807b7561-5834-4aa5-ab66-5d9cdb5ba8e2n%40googlegroups.com.
Re: [sympy] Releasing SymPy 1.13
On Friday, February 2, 2024 at 2:28:43 PM UTC-8 Oscar wrote: > Although I'm wondering about Sage. Does Sage always install both SymPy > and python-flint? Sage always includes SymPy but not python-flint but it might do now that SymPy adds the optional dependency: https://github.com/sagemath/sage/pull/37224#issuecomment-1924466879 Sage already includes and uses Flint separately with its own wrapper but python-flint would be an additional package whose purpose for now would just be to be used by SymPy inside of Sage. I'll note that if python-flint is only declared as an optional dependency of SymPy, it is likely that we wouldn't make python-flint a standard package in Sage immediately. I hope that in future there will be some convergence between python-flint and Sage's Flint wrapper. It isn't possible for SymPy to use Sage's Flint wrapper (outside of Sage) but it could be possible in future for both to use python-flint or for the Sage wrapper to become something separate from Sage. FWIW, in https://github.com/sagemath/sage/pull/35095, I have been preparing a distribution package sagemath-flint, which has relatively modest requirements. See https://github.com/mkoeppe/sage/tree/t/32432/modularization_of_sagelib__break_out_a_separate_package_sagemath_polyhedra/pkgs/sagemath-flint I hope that these modularized distribution packages will become available in Q2 2024. Matthias -- 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/f7c92c84-f1f1-4c86-a82e-701e87c52f25n%40googlegroups.com.
Re: [sympy] Releasing SymPy 1.13
On Fri, 2 Feb 2024 at 22:36, Aaron Meurer wrote: > > On Fri, Feb 2, 2024 at 3:28 PM Oscar Benjamin > wrote: > > > > Without making python-flint a hard dependency there is no way to > > specify what versions should be acceptable in an install so I think > > that the safest thing for now is to keep an upper bound that is > > checked at runtime. We also definitely need a lower bound because so > > far SymPy (master branch) uses the latest python-flint features as > > they roll out. > > I don't know about pip, but conda does let you specify version pins > for optional dependencies (it won't install the dependency but if it > is installed it will make sure that version is satisfied). But I would > be careful with this because it would make it impossible for people to > upgrade python-flint in their environment. We used to pin the > antlr-python-runtime like this, but then it made it difficult for > other packages using antlr, so we removed it (see > https://github.com/conda-forge/sympy-feedstock/issues/46). It is not possible to do this in the PyPI package metadata. Either python-flint is a hard dependency or there is no version constraint. > Generally speaking, aggressive version pins can end up biting you. > There's a long blog post about this here if you are interested > https://iscinumpy.dev/post/bound-version-constraints/. My suggestion > at this point would be to not pin in the package metadata. If you're > really worried about it, you can add soft checks in the code, which > are either just warnings or can be overridden somehow like you > suggested. To be clear I am just talking about a runtime check for the version here: https://github.com/sympy/sympy/blob/0b25b279a5f089885cfd1b5e7685515338695f58/sympy/external/gmpy.py#L90-L147 Basically if the environment variable is not set then check if python-flint is installed with version 0.6.x and if so then use it. In future the same logic can apply but perhaps with a looser version check. -- 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/CAHVvXxTm5nHETvmYzWrfFmXt91WtmMrXJyn-M8v3MHUSdJA0mA%40mail.gmail.com.
Re: [sympy] Releasing SymPy 1.13
On Fri, Feb 2, 2024 at 3:28 PM Oscar Benjamin wrote: > > On Fri, 2 Feb 2024 at 21:52, Aaron Meurer wrote: > > > > On Fri, Feb 2, 2024 at 9:41 AM Oscar Benjamin > > wrote: > > > > > > I think that probably the right way to do this is just for SymPy to > > > use python-flint by default if it is installed but with an almost > > > exact version check like `python-flint == 0.6.x` because `0.6.0` is > > > the minimum version needed for the PR above but also the maximum > > > version that has been tested before release. It would be good to allow > > > the flexibility to have `0.6.1` though in case there is a small bugfix > > > release of python-flint. Over time if things seem more stable then we > > > could relax that version constraint. The environment variable could > > > still be used to override the version check but the default if no > > > environment variable is set should just be to use python-flint but > > > only the expected 0.6.x versions. > > > > > > Does anyone have any thoughts on how exactly to do this? > > > > I think it should just be enabled by default. Almost no one will have > > flint installed, so only people who go out of their way to install it > > will get the benefits, so requiring an opt-in is just an extra step > > for those people. The only way this wouldn't be the case is if we add > > flint as a dependency in the conda package like we do for gmpy, but it > > sounds like it's a bit early to do that. > > > > Although I'm wondering about Sage. Does Sage always install both SymPy > > and python-flint? > > Sage always includes SymPy but not python-flint but it might do now > that SymPy adds the optional dependency: > https://github.com/sagemath/sage/pull/37224#issuecomment-1924466879 Well if Sage is going to do that intentionally to enable Flint support in SymPy then we shouldn't worry about it. > > Sage already includes and uses Flint separately with its own wrapper > but python-flint would be an additional package whose purpose for now > would just be to be used by SymPy inside of Sage. I hope that in > future there will be some convergence between python-flint and Sage's > Flint wrapper. It isn't possible for SymPy to use Sage's Flint wrapper > (outside of Sage) but it could be possible in future for both to use > python-flint or for the Sage wrapper to become something separate from > Sage. > > > As for the verison checks, it depends on how likely you expect there > > to be breaking changes in python-flint. If that package is going to > > have a lot of breaking changes, it will make using it in SymPy a lot > > harder. > > I don't anticipate many breaking changes but python-flint is in a more > active development phase than SymPy and I doubt that we will want to > test all version combinations (just like we don't with mpmath or numpy > etc). > > Actually that reminds me that some of the changes in SymPy 1.13 are > needed for the next release of mpmath (whenever that happens). Now > that mpmath is also in a more active development phase than it has > been for a long time we should review the version checking there as > well. Currently SymPy checks for a 10 year old version of mpmath as > the minimum version: > https://github.com/sympy/sympy/blob/0b25b279a5f089885cfd1b5e7685515338695f58/setup.py#L37 > > Without making python-flint a hard dependency there is no way to > specify what versions should be acceptable in an install so I think > that the safest thing for now is to keep an upper bound that is > checked at runtime. We also definitely need a lower bound because so > far SymPy (master branch) uses the latest python-flint features as > they roll out. I don't know about pip, but conda does let you specify version pins for optional dependencies (it won't install the dependency but if it is installed it will make sure that version is satisfied). But I would be careful with this because it would make it impossible for people to upgrade python-flint in their environment. We used to pin the antlr-python-runtime like this, but then it made it difficult for other packages using antlr, so we removed it (see https://github.com/conda-forge/sympy-feedstock/issues/46). Generally speaking, aggressive version pins can end up biting you. There's a long blog post about this here if you are interested https://iscinumpy.dev/post/bound-version-constraints/. My suggestion at this point would be to not pin in the package metadata. If you're really worried about it, you can add soft checks in the code, which are either just warnings or can be overridden somehow like you suggested. Aaron Meurer > > I'll add a python-flint == 0.6.x check for now. In future I don't > think it will be necessary and in the meantime someone can use the > environment variable to force the use of python-flint if they want to > but have a different version. > > -- > Oscar > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving
Re: [sympy] Doubt Regarding .mailmap file
It's hard to tell from a screenshot. Do you have a link to the PR? On Fri, 2 Feb 2024 at 17:36, Shishir Kushwaha wrote: > > Do I need to add my details everytime to thee .mailmap file when making a PR > , I did it in my first PR as mentioned in the documentation but when creating > a new comitt on another issue , the authro test was failing even though my > name is there in the file already . Any idea why this could happen? > > > -- > 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/d9705b06-6ca2-49af-9648-e0f23499a6b7n%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/CAHVvXxToe%2BNycvLPWz-pd8Gn7X8Or7ttJHGn%2BekhF8ArSUY%3D8A%40mail.gmail.com.
Re: [sympy] Releasing SymPy 1.13
On Fri, 2 Feb 2024 at 21:52, Aaron Meurer wrote: > > On Fri, Feb 2, 2024 at 9:41 AM Oscar Benjamin > wrote: > > > > I think that probably the right way to do this is just for SymPy to > > use python-flint by default if it is installed but with an almost > > exact version check like `python-flint == 0.6.x` because `0.6.0` is > > the minimum version needed for the PR above but also the maximum > > version that has been tested before release. It would be good to allow > > the flexibility to have `0.6.1` though in case there is a small bugfix > > release of python-flint. Over time if things seem more stable then we > > could relax that version constraint. The environment variable could > > still be used to override the version check but the default if no > > environment variable is set should just be to use python-flint but > > only the expected 0.6.x versions. > > > > Does anyone have any thoughts on how exactly to do this? > > I think it should just be enabled by default. Almost no one will have > flint installed, so only people who go out of their way to install it > will get the benefits, so requiring an opt-in is just an extra step > for those people. The only way this wouldn't be the case is if we add > flint as a dependency in the conda package like we do for gmpy, but it > sounds like it's a bit early to do that. > > Although I'm wondering about Sage. Does Sage always install both SymPy > and python-flint? Sage always includes SymPy but not python-flint but it might do now that SymPy adds the optional dependency: https://github.com/sagemath/sage/pull/37224#issuecomment-1924466879 Sage already includes and uses Flint separately with its own wrapper but python-flint would be an additional package whose purpose for now would just be to be used by SymPy inside of Sage. I hope that in future there will be some convergence between python-flint and Sage's Flint wrapper. It isn't possible for SymPy to use Sage's Flint wrapper (outside of Sage) but it could be possible in future for both to use python-flint or for the Sage wrapper to become something separate from Sage. > As for the verison checks, it depends on how likely you expect there > to be breaking changes in python-flint. If that package is going to > have a lot of breaking changes, it will make using it in SymPy a lot > harder. I don't anticipate many breaking changes but python-flint is in a more active development phase than SymPy and I doubt that we will want to test all version combinations (just like we don't with mpmath or numpy etc). Actually that reminds me that some of the changes in SymPy 1.13 are needed for the next release of mpmath (whenever that happens). Now that mpmath is also in a more active development phase than it has been for a long time we should review the version checking there as well. Currently SymPy checks for a 10 year old version of mpmath as the minimum version: https://github.com/sympy/sympy/blob/0b25b279a5f089885cfd1b5e7685515338695f58/setup.py#L37 Without making python-flint a hard dependency there is no way to specify what versions should be acceptable in an install so I think that the safest thing for now is to keep an upper bound that is checked at runtime. We also definitely need a lower bound because so far SymPy (master branch) uses the latest python-flint features as they roll out. I'll add a python-flint == 0.6.x check for now. In future I don't think it will be necessary and in the meantime someone can use the environment variable to force the use of python-flint if they want to but have a different version. -- 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/CAHVvXxQUfFTsOyQVdVSL3a33auXZT%3D6u0zCXi8Z33SvHJXk8Fw%40mail.gmail.com.
Re: [sympy] Doubt Regarding .mailmap file
Is the name and email there the same as the one you added? If you changed the spelling of your name or the email, you have to add another entry to .mailmap. The point of .mailmap is to indicate when two different name/emails are actually the same person. Otherwise, I suspect the issue is that you have not synchronized the upstream master branch which contains your change to .mailmap. Normally, you should only ever need to add yourself to .mailmap once. After that, you never need to do it again, unless, like I said, you create commits with a different spelling of your name or a different email. Aaron Meurer On Fri, Feb 2, 2024 at 10:36 AM Shishir Kushwaha wrote: > > Do I need to add my details everytime to thee .mailmap file when making a PR > , I did it in my first PR as mentioned in the documentation but when creating > a new comitt on another issue , the authro test was failing even though my > name is there in the file already . Any idea why this could happen? > > > -- > 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/d9705b06-6ca2-49af-9648-e0f23499a6b7n%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%3D6JvrX_-OYL9s9RDM50exqwyi34T3eru73X%3D50_7ymQmWg%40mail.gmail.com.
Re: [sympy] Releasing SymPy 1.13
On Fri, Feb 2, 2024 at 9:41 AM Oscar Benjamin wrote: > > Hi all, > > It is past time that a new release of SymPy is needed. Let's get SymPy > 1.13 out ASAP. > > I had been meaning to put out a bugfix release of SymPy 1.12.1 because > of a few things that have been fixed since SymPy 1.12 but it didn't > happen. In particular compatibility with Python 12's ast module for > parsing string expressions was fixed and a few other small things. > Also some changes were recently made for compatibility with NumPy 2.0 > which is probably going to be released in a few months but we should > get out a SymPy release first. > > There are of course also many other improvements since SymPy 1.12. You > can see the release notes here: > https://github.com/sympy/sympy/wiki/Release-Notes-for-1.13 > > I've created a release issue here to track releasing 1.13: > https://github.com/sympy/sympy/issues/26169 > > Please say if there are any release blocker issues or other things > that should be resolved before the release. > > Here is one from me: > > After the 0.6.0 release of python-flint I would like to get this PR > merged to use Flint for polynomials and matrices over GF(p) as well as > ZZ and QQ: > https://github.com/sympy/sympy/pull/25940 > > A larger issue to be resolved is how exactly SymPy should use > python-flint. Currently with the SymPy master branch it is necessary > to set an environment variable SYMPY_GROUND_TYPES=flint to get SymPy > to use python-flint. That is not how it works with gmpy2 though, which > will just be picked up automatically when it is installed without the > need to set an environment variable. > > In principle the use of python-flint should not change the behaviour > of SymPy at all except that some particular things are made a lot > faster. Currently those things are: > > - Univariate polynomials over ZZ, QQ (and GF(p) if the PR above is > merged). This means various functions like `factor`, `gcd` etc are > faster. > - Algebraic extension fields like QQ.algebraic_field(sqrt(2)) since > their ANP type uses Flint's univariate polynomials as well now. > - The dense format of DomainMatrix when the domain is ZZ, QQ (or GF(p) > if the PR above is merged). > > These changes are very particular about what exactly is or is not made > faster but some particular operations are made much faster and for > others it makes no difference. In future Flint's multivariate > polynomials will be used and that will end up having a more noticeable > impact on the speed of higher-level operations for most end users. > > The question is whether to be conservative about making use of > python-flint by requiring an opt-in environment variable like this. > There are two possible downsides for a given user if SymPy starts > using python-flint automatically: > > 1. It is not yet that widely tested by many different people on > different computers etc so it is possible that there are unknown bugs. > 2 I expect that many things will change in python-flint over the next > few years. It is possible that a SymPy release of 1.13 now will not be > fully compatible with say a future release of python-flint in a few > years time. > > Note that python-flint is not as widely used or installed as SymPy by > a long way. I doubt that there are many people who just happen to have > python-flint and SymPy installed and would then be surprised that > SymPy started using python-flint. Probably most of the time the fact > that someone has installed both packages together is because they want > SymPy to use python-flint. > > I think that probably the right way to do this is just for SymPy to > use python-flint by default if it is installed but with an almost > exact version check like `python-flint == 0.6.x` because `0.6.0` is > the minimum version needed for the PR above but also the maximum > version that has been tested before release. It would be good to allow > the flexibility to have `0.6.1` though in case there is a small bugfix > release of python-flint. Over time if things seem more stable then we > could relax that version constraint. The environment variable could > still be used to override the version check but the default if no > environment variable is set should just be to use python-flint but > only the expected 0.6.x versions. > > Does anyone have any thoughts on how exactly to do this? I think it should just be enabled by default. Almost no one will have flint installed, so only people who go out of their way to install it will get the benefits, so requiring an opt-in is just an extra step for those people. The only way this wouldn't be the case is if we add flint as a dependency in the conda package like we do for gmpy, but it sounds like it's a bit early to do that. Although I'm wondering about Sage. Does Sage always install both SymPy and python-flint? As for the verison checks, it depends on how likely you expect there to be breaking changes in python-flint. If that package is going to have a lot of breaking
[sympy] Doubt Regarding .mailmap file
Do I need to add my details everytime to thee .mailmap file when making a PR , I did it in my first PR as mentioned in the documentation but when creating a new comitt on another issue , the authro test was failing even though my name is there in the file already . Any idea why this could happen? -- 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/d9705b06-6ca2-49af-9648-e0f23499a6b7n%40googlegroups.com.
[sympy] Releasing SymPy 1.13
Hi all, It is past time that a new release of SymPy is needed. Let's get SymPy 1.13 out ASAP. I had been meaning to put out a bugfix release of SymPy 1.12.1 because of a few things that have been fixed since SymPy 1.12 but it didn't happen. In particular compatibility with Python 12's ast module for parsing string expressions was fixed and a few other small things. Also some changes were recently made for compatibility with NumPy 2.0 which is probably going to be released in a few months but we should get out a SymPy release first. There are of course also many other improvements since SymPy 1.12. You can see the release notes here: https://github.com/sympy/sympy/wiki/Release-Notes-for-1.13 I've created a release issue here to track releasing 1.13: https://github.com/sympy/sympy/issues/26169 Please say if there are any release blocker issues or other things that should be resolved before the release. Here is one from me: After the 0.6.0 release of python-flint I would like to get this PR merged to use Flint for polynomials and matrices over GF(p) as well as ZZ and QQ: https://github.com/sympy/sympy/pull/25940 A larger issue to be resolved is how exactly SymPy should use python-flint. Currently with the SymPy master branch it is necessary to set an environment variable SYMPY_GROUND_TYPES=flint to get SymPy to use python-flint. That is not how it works with gmpy2 though, which will just be picked up automatically when it is installed without the need to set an environment variable. In principle the use of python-flint should not change the behaviour of SymPy at all except that some particular things are made a lot faster. Currently those things are: - Univariate polynomials over ZZ, QQ (and GF(p) if the PR above is merged). This means various functions like `factor`, `gcd` etc are faster. - Algebraic extension fields like QQ.algebraic_field(sqrt(2)) since their ANP type uses Flint's univariate polynomials as well now. - The dense format of DomainMatrix when the domain is ZZ, QQ (or GF(p) if the PR above is merged). These changes are very particular about what exactly is or is not made faster but some particular operations are made much faster and for others it makes no difference. In future Flint's multivariate polynomials will be used and that will end up having a more noticeable impact on the speed of higher-level operations for most end users. The question is whether to be conservative about making use of python-flint by requiring an opt-in environment variable like this. There are two possible downsides for a given user if SymPy starts using python-flint automatically: 1. It is not yet that widely tested by many different people on different computers etc so it is possible that there are unknown bugs. 2 I expect that many things will change in python-flint over the next few years. It is possible that a SymPy release of 1.13 now will not be fully compatible with say a future release of python-flint in a few years time. Note that python-flint is not as widely used or installed as SymPy by a long way. I doubt that there are many people who just happen to have python-flint and SymPy installed and would then be surprised that SymPy started using python-flint. Probably most of the time the fact that someone has installed both packages together is because they want SymPy to use python-flint. I think that probably the right way to do this is just for SymPy to use python-flint by default if it is installed but with an almost exact version check like `python-flint == 0.6.x` because `0.6.0` is the minimum version needed for the PR above but also the maximum version that has been tested before release. It would be good to allow the flexibility to have `0.6.1` though in case there is a small bugfix release of python-flint. Over time if things seem more stable then we could relax that version constraint. The environment variable could still be used to override the version check but the default if no environment variable is set should just be to use python-flint but only the expected 0.6.x versions. Does anyone have any thoughts on how exactly 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 view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxTb9K-2uLsCCzfZGHK9HmFekM1LKHQJYVbys60aPr25pg%40mail.gmail.com.
[sympy] python-flint 0.6.0 released
Hi all, Yesterday I pushed a new release of python-flint version 0.6.0 to PyPI. I expect that this release will appear in conda soon as well. The new release can be installed with pip install --upgrade python-flint As in previous releases there are binary wheels available for CPython 3.9-3.12 for Windows, OSX (intel and arm) and Linux. Conda has packages for other architectures and also for PyPy. Thanks to Matthias Koeppe python-flint 0.6.0 is now included in the list of packages available in pyodide so a WASM build of python-flint can be used in a web browser (I'm not sure if a new pyodide release is needed before that would actually work though...): https://pyodide.org/en/latest/usage/packages-in-pyodide.html After installing python-flint you can run the tests with python -m flint.test Please report any issues with python-flint to GitHub: https://github.com/flintlib/python-flint/issues The python-flint library is a Cython-based wrapper library providing Python bindings for Flint. More information here: https://github.com/flintlib/python-flint These docs are out of date but I will put up some new docs somewhere else (maybe readthedocs) soon: https://fredrikj.net/python-flint/ Changes in 0.6.0: - After the fmpz_mod and fmpz_mod_poly types were added in 0.5.0 the fmpz_mod_mat type was added in 0.6.0. This provides matrices of integers mod n for arbitrarily large n. Various other matrix methods were made complete/consistent across the different matrix types. - Division like a / b now means exact division for all non-field types so e.g. fmpz(4)/fmpz(2) gives fmpz(2) but fmpz(5)/fmpz(2) will raise DomainError. This applies to dividing fmpz, fmpz_mat/fmpz and all exact poly types (fmpz_poly, fmpq_poly, nmod_poly, fmpz_mod_poly). Previously most of these would just give TypeError but one or two cases would convert to fmpq implicitly. Now there are no such implicit conversions. - The version of Flint that is tested and bundled is now Flint 3.0.1 rather than Flint 3.0.0 but either version should work. Earlier versions of Flint (e.g. 2.9) are not supported. - python-flint now has a pyproject.toml as expected in modern Python packaging (thanks to Matthias Koeppe). This means that when building from source tools like pip can obtain the build dependencies automatically without needing to use --no-build-isolation. There are many other features in Flint not yet exposed in python-flint. Contributions are welcome from anyone who would like to see more added! -- 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/CAHVvXxRRd11f3DhoAZ_duaWM%2BYH8LAnbFVYja55hs9bOg4YJQw%40mail.gmail.com.
[sympy] Re: GSOC: Symbolic Control Systems
Hi Donald, Good to hear you enjoyed using SymPy and like to contribute back. I've updated the link in the GSoC idea. Since a few years, it is also possible to do a longer GSoC project. The minimum project span is 175 hours, which you can spread across 12 weeks and the maximum project span is 350 hours for which you can also take a bit longer. At least this is what I remember from doing my GSoC within SymPy two years ago. Kind regards, Timo Op zondag 28 januari 2024 om 21:56:04 UTC+1 schreef geo...@gmail.com: > Hi > > I am interested to work on Symbolic Control Systems project listed on the > GSOC Ideas Page. I study mathematics part-time at the Singapore University > of Social Science. > > I have been using Sympy to automate my mathematical procedures for > homework and exam over the last 2 semesters, so I truly appreciate the > great work the Sympy community has put up so far. As such, I want to > contribute back to the community. > > The textbook link from Caltech CDS is no longer valid. Any chance, is the > textbook called Feedback Systems by Karl Astrom and Richard Murray? I > believe the updated link is > http://www.cds.caltech.edu/~murray/books/AM08/pdf/fbs-public_24Jul2020.pdf > > I would like to know what does 175/350h mean since GSOC gives me the > impression that it would be a 12-week project. > > > Cheers > Donald > > > > > > > -- 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/3acbbd0c-ed1e-40a8-b5ac-9b4f0445f922n%40googlegroups.com.
