Re: [sage-devel] Removing the backend for mpmath provided by Sage
I find it quite difficult to understand the Sage code so I can't really review the PR. I will say though that I think that this is an important change to make. Both SymPy and Sage reach deeply into mpmath's internals which means that mpmath itself is hamstrung when it comes to future improvements. It would be easy to bring significant improvements in performance for mpmath just by making use of python-flint if it was easier to rearrange mpmath's internal code without breaking SymPy and Sage. I just removed one part of SymPy's usage of mpmath internals in: https://github.com/sympy/sympy/pull/26861 There is still plenty more to do though to reach the point where SymPy only uses mpmath's "public" interfaces though. -- Oscar On Sat, 27 Jul 2024 at 23:59, Matthias Koeppe wrote: > > https://github.com/sagemath/sage/pull/38113, needs review. > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/5c89a51c-e54b-411a-b631-24be8ccd5df7n%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxRvac6CAUjo_PswOxtpJV%3DkjgcudbJeTgx%2B%2BL6YdNjCTw%40mail.gmail.com.
Re: [sage-devel] Any tips for Maxima migrating to GitHub
Okay, so the public API can't do this. That explains why I couldn't see how to do it. I'll pass this on. Thanks David and Dima. On Thu, 11 Jul 2024 at 20:32, Dima Pasechnik wrote: > > The migration has to be performed by GitHub staff (or at least it was > the case 1.5 years ago). > You'll want to get in touch with https://github.com/abbycabs who's > leading these sort tasks at GitHub. > > So you'd need to write an exporter (that's the repo David links), and > debug it, before handing over to them, on a (trial) instance of GitHub > Enterprise server (you can install it for free and use for a month or > so - you'd need a Linux server to run it on). > > HTH, > Dima > > > > > On Thu, Jul 11, 2024 at 5:50 PM Oscar Benjamin > wrote: > > > > Hi all, > > > > There have been some discussions and tentative attempts to migrate > > Maxima from SourceForge to GitHub e.g.: > > https://sourceforge.net/p/maxima/mailman/message/58794267/ > > > > I'm wondering how Sage managed to migrate issues from trac to GitHub > > while still preserving things like who is the author of a comment or > > the timestamp of the comment etc. I don't see how in GitHub's API you > > can set those things. > > > > For example this issue was migrated: > > https://github.com/sagemath/sage/issues/33458 > > > > Somehow it shows my GitHub account opening the issue along with the > > GitHub handles for other people who commented and the timestamps are I > > assume those that were pulled from trac. I can't see how to make that > > happen with Github migration scripts that I have seen or from the REST > > API docs. > > > > If anyone has any tips for a good way to do this then I am sure that > > the Maxima developers would appreciate it. > > > > -- > > Oscar > > > > -- > > You received this message because you are subscribed to the Google Groups > > "sage-devel" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to sage-devel+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/sage-devel/CAHVvXxSs4gKgD_dPTkyNm6CiM7exMdoLBaA26m1G9N2f3%2BipxA%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxSvJ%3DHzAqA7B-eaMgmwtHxj%3DdHY8zebzkenNT4PE_gApA%40mail.gmail.com.
[sage-devel] Any tips for Maxima migrating to GitHub
Hi all, There have been some discussions and tentative attempts to migrate Maxima from SourceForge to GitHub e.g.: https://sourceforge.net/p/maxima/mailman/message/58794267/ I'm wondering how Sage managed to migrate issues from trac to GitHub while still preserving things like who is the author of a comment or the timestamp of the comment etc. I don't see how in GitHub's API you can set those things. For example this issue was migrated: https://github.com/sagemath/sage/issues/33458 Somehow it shows my GitHub account opening the issue along with the GitHub handles for other people who commented and the timestamps are I assume those that were pulled from trac. I can't see how to make that happen with Github migration scripts that I have seen or from the REST API docs. If anyone has any tips for a good way to do this then I am sure that the Maxima developers would appreciate it. -- Oscar -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxSs4gKgD_dPTkyNm6CiM7exMdoLBaA26m1G9N2f3%2BipxA%40mail.gmail.com.
Re: [sage-devel] Re: Python version support for SymPy/Sage
Thanks Matthias. On Wed, 5 Jun 2024 at 19:32, Matthias Koeppe wrote: > On Wednesday, June 5, 2024 at 5:31:30 AM UTC-7 Oscar Benjamin wrote: > > > Ordinarily SymPy would have dropped support for Python 3.8 by now > > anyway regardless of SPEC 0 or NEP 29. I can't remember where this was > > discussed but I think that the reason Python 3.8 is still supported is > > just because we thought it was needed by Sage. > > We dropped Python 3.8 in the Sage 10.2 cycle (August 2023). Okay, well we'll keep it in SymPy 1.13 for now. The release has already been delayed long enough so I don't want to change anything at this point. > > Following those specifications in coordination with other scientific > > Python packages would mean dropping both 3.8 and 3.9 now and then also > > dropping 3.10 in a few months. I don't propose to do this right now > > with the SymPy 1.13 release but once 1.13 is released I want to drop > > at least 3.8 if not also 3.9 > > No problem; by the time that SymPy 1.14 is ready, we'll likely have dropped > 3.9. Okay great. We'll drop both Python 3.8 and 3.9 then after sympy 1.13 is released. You haven't mentioned 3.10. I infer from this that it currently seems problematic for Sage to drop support for 3.10 in a few months (and that it might be awkward if SymPy did so). -- Oscar -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxSipFTSK7yGqBYeUw1aRX1NbEZqdM1WKHtBA5hSSgqFdg%40mail.gmail.com.
[sage-devel] Python version support for SymPy/Sage
Hi all, My question here is: would it be problematic for Sage if SymPy were to follow SPEC 0/NEP 29 which would mean dropping support for older Python versions more quickly? We are about to release SymPy 1.13 which will support Python 3.8 to 3.13. It has been asked on the SymPy mailing list whether SymPy could adopt SPEC 0 which is basically the same as NEP 29: https://groups.google.com/g/sympy/c/VNz2xJ1Sywo/m/0H1-KmaJAgAJ?utm_medium=email_source=footer https://scientific-python.org/specs/spec-/ There are older discussions about this as well: https://github.com/sympy/sympy/issues/21884 This relates to previous discussions on this list about Sage following NEP 29: https://groups.google.com/g/sage-devel/c/j1cwbTU8aOU/m/Ap_1pHlsBQAJ?utm_medium=email_source=footer https://groups.google.com/g/sage-devel/c/3Zoq0CNE1hE/m/m40v2e_cBwAJ Ordinarily SymPy would have dropped support for Python 3.8 by now anyway regardless of SPEC 0 or NEP 29. I can't remember where this was discussed but I think that the reason Python 3.8 is still supported is just because we thought it was needed by Sage. Following those specifications in coordination with other scientific Python packages would mean dropping both 3.8 and 3.9 now and then also dropping 3.10 in a few months. I don't propose to do this right now with the SymPy 1.13 release but once 1.13 is released I want to drop at least 3.8 if not also 3.9 and then ideally we would have a clear policy for this going forwards. It is not particularly difficult for SymPy itself to support a wide range of Python versions but it creates potential problems for other packages that depend on SymPy. For example when SymPy 1.13 is released (soon) any packages that depend on SymPy potentially need to put out updates for all of the same Python versions that the SymPy release claims support for. If the SymPy 1.13 update breaks something then pushing it out to as many Python versions as possible is like spreading the risk of breakage as far as possible. We need to be careful about this because besides direct end users or Sage there are also very widely used packages like pytorch that depend on SymPy which has forced us into rushing out fix releases recently: https://github.com/sympy/sympy/issues/26273 Personally I am in favour of SymPy coordinating with the rest of the scientific Python ecosystem by adopting SPEC 0/NEP 29 so that there is a clearly defined policy that is understood and depended on by everything downstream. Old versions of SymPy will continue to work with old versions of Python so people who like packaging old versions of everything (e.g. Linux distros) can do so. People who want to use the latest versions of Python packages should also use recent versions of Python. My recommendation to a user who just wants to use Python would generally be to install the second most recent version of Python i.e. currently Python 3.11 but soon 3.12. I would not recommend anyone to install Python 3.8 right now. For now I use pyenv to install different Python versions but hopefully in future it will become easier to install a particular Python version from binary on any OS. I expect that soon uv will be able to do this using the PyBI binaries at which point I will probably switch to using uv in replacement of both pyenv and pip. I expect that in future editors like vscode will be able to handle installing a particular Python version and all the packages automatically for users who will not even need to run uv/pip etc directly. Conda already makes it easy to install particular Python versions for people using conda. Windows/MacOS users will typically download the newest Python version from the python.org download page. Linux distros usually have ways of installing newer Python versions from repos and it's not hard to build Python on Linux anyway. It is not clear to me what the benefit is of supporting old Python versions especially for Sage: building/installing Sage is a vastly bigger issue than building/installing a new Python version. My question then is would SymPy adopting SPEC 0/NEP 29 be a problem for Sage? If SymPy 1.14 is released later this year and drops support for Python 3.8, 3.9 and 3.10 would that be a problem? Oscar -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxR0FpHr25XrZezE4sKFjjum3mO4xMF3PARc3UEWtBAj_g%40mail.gmail.com.
Re: [sage-devel] wasm
> > Since I am not a programmer and nobody in my team is a mathematician (so my
> > developers don't know Sage), I kindly ask on this list for any hints how we
> > could proceed?
> Sage mainly uses other open source C libraries to carry out these
> factorizations, so you would need to be able to port these to wasm as well.
To be clear, porting parts of Sage or the underlying C libraries to
WASM/pyodide is a formidable task even for a mathematical programmer.
That is why I suggested SymPy instead since it already works in
WASM/pyodide.
SymPy does not provide factorisation over as many different rings as
Sage does but is easy to install and use in WASM via pyodide:
https://pyodide.org/en/stable/
You can just micropip.install('sympy') and add a short snippet of
Python code to use SymPy from JS:
https://pyodide.org/en/stable/usage/loading-packages.html
The next release of SymPy (1.13) can make use of python-flint for
factorisation of some polynomials using the underlying Flint C
library. Also python-flint has been ported to pyodide so it should be
possible to use SymPy backed by Flint in WASM:
https://pyodide.org/en/latest/usage/packages-in-pyodide.html
In future if Sage becomes more usable from WASM/pyodide then I assume
that you would be able to use it in the same way via pyodide. As I
understand it though it is not possible right now to install enough
pieces of Sage in pyodide to be able to factorise a polynomial. I
imagine that making that work using Sage would require some
significant porting work that is likely out of scope for a team of
non-mathematicians who do not know Sage or its dependencies.
--
Oscar
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/CAHVvXxROpXVCCi_k4a%3D6gamq%2B%3DsN1jc1%3DMCfk7NVxYyLVQyybg%40mail.gmail.com.
Re: [sage-devel] wasm
Hi Doris, I believe some parts of Sage can be used in WASM (via pyodide) but others cannot so I am not sure if it is possible to get the functionality that you want from Sage in WASM. It is however possible to use SymPy in WASM (via pyodide) as demonstrated here using JupyterLite: https://live.sympy.org/ You should be able to test the following commands in SymPy Live which I assume is the functionality that you are looking for: factor(x**2 + 1, domain=QQ) factor(x**2 + 1, domain=ZZ_I) factor(x**2 + 1, domain=GF(2)) -- Oscar On Tue, 30 Apr 2024 at 08:29, 'Doris Behrendt' via sage-devel wrote: > > Hi all, > > My team is about to develop a webapp where we want to factor polynomials with > coefficients in ZZ. > We want to offer a dropdown menu where the user can select the base ring and > then the factorisation changes interactively. We use React and JavaScript and > also Web Assembly, e.g. for our Web-OpenSSL here: > https://www.cryptool.org/en/cto/openssl/ > > Sage offers the command change_ring, we did not find a JavaScript Library > that has this functionality. So I thought, perhaps we could look for > solutions where Sage is used together with web assembly. > > After some research I have the impression that there are some proofs of > concept, but there is nothing actively developed? > > Since I am not a programmer and nobody in my team is a mathematician (so my > developers don't know Sage), I kindly ask on this list for any hints how we > could proceed? > > Thanks in advance > Doris > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/08830539-4D13-4E63-80E0-4F1F788B1657%40me.com. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxTCFwv9JhQzcz-KzvZA%3Dx%3D%3DbYj%3DkonhcMBi7%2BWm%3DJ8%3D0w%40mail.gmail.com.
Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)
On Wed, 24 Apr 2024 at 15:37, Marc Culler wrote: > > I think that CyPari ;and CyPari2 provide a relevant example. > > Some background ... CyPari is a PyPi package with binary wheels which > predates and was the starting point for Sage's cypari2 (hence the 2 in the > name). The basis for CyPari was Sage's pari module. That module was > modified to make it independent from the rest of Sage so that Sage's Pari > support could be provided as a component of SnapPy. Binary wheels for CyPari > are available for Windows, macOS and manylinux. The current versions of > those wheels are statically linked against Pari 2.15.4 > > The binary wheel for CyPari weighs in at 7MB. Sage's CyPari2 is available as > a binay wheel for macOS and manylinux and the size is of the same order of > magnitude. When they are unpacked and installed the sizes of these python > packages are respectively 19MB and 7.5MB (cypari2 is linked against the > dynamic libraries libgmp and libpari, which together are about 12MB and which > are external to the python package). A full Sage installation is about 5 > gigabytes. With some significant omissions and compression of the > documentation, the macOS app squeezes that down to 3.4GB. > > So the size of this one significant self-contained component of sage is about > 200 times smaller than the full sage installation and it could be made > installable on Windows with some additional work which has already been done > for a very closely related package. Thanks Marc. This seems like a good example of a useful part of Sage that can be extracted to something much smaller than Sage. Presumably though a hypothetical person who wants CyPari2 but not all of Sage can already just use CyPari so that person is already well served. Is the plan that CyPari2 would effectively replace CyPari? Then the benefit is not needing to maintain CyPari separately from sagelib's CyPari2 dependency? I am wondering how representative the CyPari case is compared to other parts of Sage. There seems to be some disagreement about what parts of Sage would go where but not much discussion about what it means in terms of disk footprint, portability etc i.e. the factors that make the modularisation useful (maybe I misunderstand what the intended benefits are). I know that a full Sage install takes 5GB but I have no real understanding of what it is that takes up all that space or how that can break down into usable pieces with a smaller footprint. At least disk footprint is something that can be quantified though: what is the disk usage of different virtual environments that contain some useful collection of parts of Sage? -- Oscar -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxSuqEAk9pNz1P35e5CTB_-TGjO0sV-CbNgzcZvHwjhyiQ%40mail.gmail.com.
Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)
On Tue, 23 Apr 2024 at 15:27, Marc Culler wrote: > > The projects that will really benefit from modularization will be those that > provide their own limited mathematical context. Developers of such projects > will be able to choose which parts of Sage are relevant to their specific > context. Those parts of Sage can be provided for their users without having > to embed a huge monolithic environment into a relatively small project. Is the benefit in this case mainly about reduced disk/network usage? I could imagine other theoretical benefits like maybe some parts could be installed natively on Windows or some parts might be easier to provide binaries for etc. Are there any indicative numbers for what the size would be when installing some useful portion of Sage vs installing the whole of Sage? -- Oscar -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxQUanPY%3D1svhf7Q8xDFD5BroD9wTLRc1-wmFC3vQhBMRg%40mail.gmail.com.
Re: [sage-devel] Re: Degree of the zero polynomial ring for `LaurentPolynomialRing`
On Fri, 1 Mar 2024 at 11:51, 'Martin R' via sage-devel wrote: > On Friday 1 March 2024 at 12:15:36 UTC+1 John Cremona wrote: > On Fri, 1 Mar 2024 at 11:03, Dima Pasechnik wrote: > > OTOH, setting the degree of 0 to be -oo has an obvious advantage: it > automaticlly gives mathematically correct degree of fg, by using > degree(fg)=degree(f)+degree(g), regardless of f or g being 0. And checking > the degree is (or at least ought to be) faster than comparing for equality to > 0. > > It's a little dangerous to talk of -oo being "mathematically correct", but I > have given this definition myself in undergraduate course (and for the reason > you give) so that's ok, especially as in Sage we do have -oo as a possible > return value and no requiremt for the value to always be of the same type > (e.g. Integer). > > I would rather say that "-1" is in some cases "mathematically incorrect", in > particular for Laurent polynomials :-) What exactly is the "mathematically correct" meaning of "degree" for Laurent polynomials? I haven't seen other examples where this is defined except Matlab which defines it differently from Sage: https://uk.mathworks.com/help/wavelet/ref/laurentpolynomial.degree.html The Matlab definition is basically that deg(p(x)*x^m) = deg(p(x)). This means that for nonzero Laurent polynomials the degree is always nonnegative. Here deg(x^m) = 0 i.e. the degree of a unit is always 0. I haven't thought much about this but this definition of degree seems consistent with the notion of degree as a Euclidean function that can define Euclidean division. In the sympy polynomial code all uses of degree are in the polynomial division, gcd and factor code because the main use of degree is in defining division. Oscar -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxQErjrcvnCKk4j4c5-F%3DZDQ%3D6LpZ1OycaqEtBBx7wGfPA%40mail.gmail.com.
Re: [sage-devel] Re: Degree of the zero polynomial ring for `LaurentPolynomialRing`
On Fri, 1 Mar 2024 at 11:15, John Cremona wrote: > > On Fri, 1 Mar 2024 at 11:03, Dima Pasechnik wrote: >> >> On Fri, Mar 1, 2024 at 10:24 AM John Cremona wrote: >>> >>> On Fri, 1 Mar 2024 at 10:04, Dima Pasechnik wrote: On 1 March 2024 09:07:26 GMT, 'Martin R' via sage-devel wrote: >I'd be OK with raising an exception or with -oo, but it should be uniform, >and I think it should be the same for polynomials, Laurent polynomials and >in the same spirit for degree and valuation. > >It might be best to raise an exception, because this ensures that the zero >polynomial gets special treatment. Exceptions are expensive, performance-wise, and using them as a regular means of controlling the flow of the algorithm execution is not a good idea. A simple if/then/else is much cheaper. >>> >>> >>> Isn't this suggestion to have f.degree() raise an exception when f is zero, >>> but also then that any code which needs the degree to treat 0 as a special >>> case (where that makes sense)? To it would be the caller's responsibility >>> to do that with a test of f.is_zero() or whatever, rather than by seeing if >>> an exception is triggered. >> >> >> Letting degree(0) throw an exception means that every place where you want >> to test whether the degree of fg satisfies something needs a testing whether >> f or g is 0, in order to avoid an exception. > > > Fair enough. I had been assuming that for the types we are talking about > testing for equality with 0 would be fast, but perhaps it is not. If p.degree() can do this quickly then there is no reason that some other function couldn't be made to return the equivalent of p.degree() < 0 quickly. It would sometimes be a bit awkward though for deg(0) to raise an exception. I see examples of code in sympy where e.g. the degrees of polynomials are reduced in a loop and having deg(0) < 0 naturally captures the the control flow that is needed. >> OTOH, setting the degree of 0 to be -oo has an obvious advantage: it >> automaticlly gives mathematically correct degree of fg, by using >> degree(fg)=degree(f)+degree(g), regardless of f or g being 0. And checking >> the degree is (or at least ought to be) faster than comparing for equality >> to 0. Do you see examples where arithmetic with degree(0) is used in practice? When I looked for these in the sympy code I didn't find any even though the -oo convention was used. I just don't think it comes up in real code. > It's a little dangerous to talk of -oo being "mathematically correct", but I > have given this definition myself in undergraduate course (and for the reason > you give) so that's ok, especially as in Sage we do have -oo as a possible > return value and no requiremt for the value to always be of the same type > (e.g. Integer). There might not be any "requirement" for degree() to return objects of the same type but from a computational perspective it is generally better to use well defined types. Python allows mixing types up but that doesn't make it a good idea to do so especially in performance sensitive code. -- Oscar -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxRDh1y6h3PiRZNAzT50DJAfgLGMxzhdMVrV1SiNWHO24w%40mail.gmail.com.
Re: [sage-devel] Re: Degree of the zero polynomial ring for `LaurentPolynomialRing`
I recently reviewed cases in the sympy polys code that handle the degree of a zero polynomial: https://github.com/sympy/sympy/pull/25784 My conclusion is that it is sometimes useful that deg(0) < deg(p) for p != 0 but otherwise it is not really possible to use the value of deg(0) for anything meaningful in practice. Generally if deg(p) is needed then the zero polynomial needs special handling that no particular value of deg(0) helps with. I would prefer that deg(0) = -1 just so that the deg() function has a well defined type. For Laurent polynomials I am not sure that I would define a degree() method or if I did that it would be defined as the exponent of the leading term. It isn't clear to me when that notion of degree would be useful: it doesn't seem like it would generalise the ways that degree is typically used for ordinary polynomials. On Thu, 29 Feb 2024 at 10:57, Giacomo Pope wrote: > > There seem to be two things we could do here: > > 1. Have some form of vote / discussion on whether the degree of the zero > polynomial should *ever* be -1 > 2. Modify the degree calls for the LaurentSeries and LaurentPolynomialRing > (maybe other Laurent* which I am unfamiliar with) to have the zero polynomial > have degree -Infinity. > > Option 1 may be cleaner in the long run, but I assume will cause issues for > more people in the short term. Option 2 seems fairly harmless and there's no > good argument for degree -1 in this case. > > If anyone is interested in option 2, I will find time to make a PR to do > this, but I will not start this work without other people's input as this is > not code I am familiar with using and so I don't know what people could be > relying on. > On Wednesday, February 28, 2024 at 6:41:48 PM UTC Dima Pasechnik wrote: >> >> On Wed, Feb 28, 2024 at 5:00 PM Nils Bruin wrote: >>> >>> On Wednesday 28 February 2024 at 08:03:45 UTC-8 Giacomo Pope wrote: >>> >>> >>> I don't know the history of this choice or what we should be doing >>> generally. -1 for polynomials with only positive degree seems like a >>> computer science workaround, but for the LaurentPolynomialRing it just >>> seems wrong? >>> >>> >>> I think it's more than just a CS workaround. It has its roots in dimension >>> considerations: the space of polynomials of degree at most d is >>> (d+1)-dimensional. WIth that convention, 0 having degree -1 makes perfect >>> sense. >> >> >> well, it's the convention used in Singular. >> But GAP and Macaulay2 use -infinity. >> >> The arguments for -infinity: >> >> 1) degree of the product should be the sum of degrees; so it's got to be >> infinite. >> 2) it should be -infinity, to make sense of the rule that if you do division >> f/g with remainder r, >> the degree of the remainder should be less than the deg(r)<=deg(f), but if >> r=0 then the only way >> to get this is to use -infinity. >> >> Dima >> >>> >>> >>> For deg = - ord_infty it should definitely be -oo, though, and for Laurent >>> polynomials the dimension argument doesn't work. >>> >>> -- >>> >>> You received this message because you are subscribed to the Google Groups >>> "sage-devel" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to sage-devel+...@googlegroups.com. >>> >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/sage-devel/ac40d2e7-5e71-43e1-8914-869081f9bdd9n%40googlegroups.com. > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/6d95b253-fb17-4e2f-a61c-c723737774e8n%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxRe119u%3Dy-xk1O-BvWH_f1xxnHsuQCzZm_4xYRD-_NEFw%40mail.gmail.com.
Re: [sage-devel] Incorrect result for `sum(1/factorial(n**2),n,1,oo)`
Maxima's simplify_sum function produces something similar looking:
(%i4) load("simplify_sum");
(%o4) "/usr/share/maxima/5.45.1/share/solve_rec/simplify_sum.mac"
(%i5) sum(1/factorial(n^2), n, 1, inf), simpsum;
(%o5) 'sum(1/(n^2)!,n,1,inf)
(%i6) simplify_sum(%);
1/'product(n^2+%,%,1,2*n+1) non-rational term ratio to nusum
1/'product(n^2+%,%,1,2*n+1) non-rational term ratio to nusum
(%o6) %f[1,4]([1],[1-%i,%i+1,1-sqrt(2)*%i,sqrt(2)*%i+1],1)
--
Oscar
On Wed, 14 Feb 2024 at 17:52, Dima Pasechnik wrote:
>
> It appears to come from Maxima, but I have trouble reproducing this in Maxima.
> Perhaps it's a bug in the Maxima interface?
> Is there a direct way to see how Maxima is called in this instance?
>
> Dima
>
>
> On Mon, Feb 12, 2024 at 2:53 PM Georgi Guninski wrote:
>>
>> There is discussion about this on mathoverlow [1]:
>>
>> The closed form of `sum(1/factorial(n**2),n,1,oo)` doesn't appear
>> correct and it contradicts numerical computations, including verification
>> with mpmath.
>>
>> Session:
>>
>> sage: import mpmath
>> sage: su4=sum(1/factorial(n**2),n,1,oo);su4
>> hypergeometric((1,), (-I + 1, I + 1, -I*sqrt(2) + 1, I*sqrt(2) + 1), 1)
>> sage: CC(su4)
>> 1.17227289255719 - 7.88860905221012e-31*I
>> sage: mpmath.hyper((1,), (-I + 1, I + 1, -I*sqrt(2) + 1, I*sqrt(2) + 1), 1)
>> mpc(real='1.1722728925571919', imag='-6.9025329206838533e-31')
>> sage: su5=sum(1/factorial(i**2) for i in range(1,100))
>> sage: CC(su5)
>> 1.04166942239864
>>
>> sage: mpmath.nsum(lambda n: 1/mpmath.gamma(1+n**2),[1,mpmath.inf])
>> mpf('1.0416694223986369')
>>
>>
>> [1]:
>> https://mathoverflow.net/questions/463964/factorial-series-jd-sum-n-1-infty-frac1nd-and-hypergeometric-fu
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sage-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to sage-devel+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/sage-devel/CAGUWgD8FTWhurhrHbs5d_7DE0FL4f4bb_MCE6d7B%3DKZdsmC4Ew%40mail.gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/CAAWYfq2hSxdzoiaNvOLPCur3_AB1-mpPjsMFhdurTcUrz31T9Q%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/CAHVvXxTJNfBgjtjFCZJcd6rjizPVDn9bc7rhjS0FoTwd5tJ46g%40mail.gmail.com.
Re: [sage-devel] Re: Exception in sum((4*n+1)/factorial(n),n,1,oo)
The NoneType error is presumably a bug in the sage wrapper code.
Possibly related is that Maxima cannot compute the sum with its
default algorithm. It does have a simplify_sum function that can do it
though:
(%i19) load (simplify_sum);
(%o19) "/usr/share/maxima/5.45.1/share/solve_rec/simplify_sum.mac"
(%i20) sum((4*n + 1)/factorial(n), n, 1, inf), simpsum;
(%o20) 'sum((4*n+1)/n!,n,1,inf)
(%i21) simplify_sum(%);
(%o21) 4*gamma_incomplete_lower(2,-1)+10*sqrt(%e)*sinh(1/2)
This is an indirect representation of 5*e - 1 as returned by SymPy.
On Fri, 9 Feb 2024 at 14:42, Eric Gourgoulhon wrote:
>
> I confirm the bug with Sage 10.3.beta7. It seems to be linked with the Maxima
> interface.
> Meanwhile, a workaround is to use the SymPy interface:
>
> sage: sum((4*n+1)/factorial(n), n, 1, oo, algorithm='sympy')
> 5*e - 1
>
> Eric.
> Le vendredi 9 février 2024 à 11:57:08 UTC+1, Georgi Guninski a écrit :
>>
>> hi,
>>
>> var('n')
>> sum((4*n+1)/factorial(n),n,1,oo)
>>
>> TypeError: 'NoneType' object is not callable
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/824cbae6-d30d-4d27-8e08-38f787978bc4n%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/CAHVvXxT98NuVmbw4CUFVwdeSAmsqLbJCQ9Z4H2sjTZYz_0KnGw%40mail.gmail.com.
[sage-devel] 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 "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxRRd11f3DhoAZ_duaWM%2BYH8LAnbFVYja55hs9bOg4YJQw%40mail.gmail.com.
Re: [sage-devel] Re: Sage CI Failing in SymPy GitHub Actions
On Sun, 24 Sept 2023 at 22:10, Oscar Benjamin wrote: > > > On Sunday, September 24, 2023 at 11:46:05 AM UTC-7 Oscar Benjamin wrote: > > > >> Where would I send the PR for the Sage doctests? > > On Sun, 24 Sept 2023 at 20:48, Matthias Koeppe > wrote: > > > > I've added this to ci-sage.yml to explain what to do: > > > > # To test with a Sage PR, use this: > > #sage_ref: refs/pull/PR_NUMBER/merge > > So currently the SymPy Sage CI job points at: > https://github.com/sagemath/sage/pull/36276 > > So if there are doctest updates needed I guess the workflow is: > > - Open a PR against sagemath/sage with the needed (doctest or other) changes > - Make SymPy's Sage CI job point at that PR > > Then when the time comes for Sage to update its SymPy version someone > will incorporate the changes from that PR somehow? I have done this now: https://github.com/sagemath/sage/pull/36641 https://github.com/sympy/sympy/pull/25867 The SymPy CI testing with Sage all passes meaning that SymPy CI is all green on the master branch: https://github.com/sympy/sympy/commits/master Thank you Matthias for fixing up the CI config after Sage's GitHub migration. Is it worth changing the sage PR so that the Sage CI in the PR tests with SymPy's master branch? (I don't know how to do that.) -- Oscar -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxSJmimsVQ_w_C%2BQJWaysYjLjXhAH0cHnRbkuYJDxh2%2B3w%40mail.gmail.com.
[sage-devel] python-flint 0.5.0 released
Hi all, Earlier today I pushed a new release of python-flint version 0.5.0 to PyPI. I expect that this release will appear in conda soon as well. The new release can be installed with pip install python-flint There are binary wheels available for CPython 3.9-3.12 for Windows, OSX (intel and arm) and Linux. I'm not sure when conda will have python-flint 0.5.0 but for previous releases of python-flint conda has had packages for other architectures and also for PyPy. 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/ Important compatibility changes in 0.5.0: - python-flint 0.5.0 requires Flint 3.0.0 which was only released a few days ago so if building python-flint from source then you will certainly need to build Flint from source as well (this is not an issue if you install via pip/conda) - python-flint 0.5.0 adds support for Python 3.12 (setuptools is required when building for 3.12). New features in 0.5.0: - Flint's fmpz_mod type is added which provides arithmetic for integers modulo n for large n - Discrete logarithm calculations for fmpz_mod are added. - Flint's fmpz_mod_poly type is added which implements univariate polynomials over fmpz_mod. Previous releases of python-flint had Flint's nmod and nmod_poly types which are similar to fmpz_mod and fmpz_mod_poly but are only for "word size" modulus (n smaller than 2^64). The addition of the fmpz_mod and fmpz_mod_poly types extends this to arbitrarily large moduli. There were a few other smaller changes but I will just mention: - A bug giving wrong results when mixing types in a 3-arg pow like pow(int, int, fmpz) is fixed. - Some minor changes are made to the nmod type to make its arithmetic more complete. Many thanks to Giacomo (Jack) Pope and David Einstein who have been working on python-flint during the last few releases and also for 0.5.0. Just to note two big things: - David has completely refactored the codebase, reorganising everything into separate modules and developed a semi-automated way for generating the Cython bindings to Flint by parsing Flint's doc sources. - Jack added the fmpz_mod and fmpz_mod_poly types and the discrete log functionality. Ongoing work is that Jack is working on adding Flint's finite fields types (fq etc) to python-flint. Adding fmpz_mod and fmpz_mod_poly was a prerequisite for finite fields. David is working on adding Flint's multivariate polynomials, specifically fmpz_mpoly and fmpq_mpoly to python-flint although that is not quite ready for this release. It is also very likely that there will be some work soon on supporting Flint's generic ring types in python-flint. 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 "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxRxCRW%2BMuYwBML4cR%3DbkozkBu4OgYu95HQ6o6fMfa5SuA%40mail.gmail.com.
Re: [sage-devel] Re: Our github checks...
On Mon, 16 Oct 2023 at 23:22, Kwankyu Lee wrote: > > On Tuesday, October 17, 2023 at 12:50:27 AM UTC+9 tobia...@gmx.de wrote: > > I've now set some of the github checks as "required", so they get a small tag > in the checks list. That should take care of (2). > > I am not sure if that helps or makes things worse, as that is one more thing > to look and think. > > Having some checks with "Required" and some without makes things look more > complicated. What should we think of a check not passed and not "Required". > Should we ignore it? We should aim at "requiring" all checks passed (or > skipped). Marking checks as "required" is a fix for (5) not (2): > (5) Some checks are broken at the base. I have to check the check. If a job is required then a PR cannot be merged if the job fails with the changes in the PR. Longer term that should mean that you can depend on checks not being broken at the base because any PR that might have broken those checks would not have been merged into the base. In general I would suggest aiming for having a (smaller if necessary) set of checks that is always expected to pass unless a PR has broken something. That can gradually be expanded but it is better if the general expectation is that checks pass when nothing new is broken. Currently Sage CI is just all red crosses everywhere which makes it difficult to see whether any changes are fixing or breaking anything. -- Oscar -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxR5WtZyegV%2BHZpVRnJw8XYPtq-F7R%3DFcR1DiS3LaoEcwA%40mail.gmail.com.
Re: [sage-devel] Re: Sage CI Failing in SymPy GitHub Actions
On Sun, 24 Sept 2023 at 22:43, Matthias Koeppe wrote:
>
> On Sunday, September 24, 2023 at 2:10:26 PM UTC-7 Oscar Benjamin wrote:
>
> > On Sunday, September 24, 2023 at 11:46:05 AM UTC-7 Oscar Benjamin wrote:
> >
> >> Where would I send the PR for the Sage doctests?
>
> On Sun, 24 Sept 2023 at 20:48, Matthias Koeppe wrote:
> >
> > I've added this to ci-sage.yml to explain what to do:
> >
> > # To test with a Sage PR, use this:
> > #sage_ref: refs/pull/PR_NUMBER/merge
>
> So currently the SymPy Sage CI job points at:
> https://github.com/sagemath/sage/pull/36276
>
> Yes, this PR contains a hotfix for the build system (which missed its way
> into the currrent beta version 10.2.beta4).
That is a PR against the sagemath/sage develop branch.
Should any new PR with doctest updates be based off of that PR and set
to merge into develop?
There are some doctest failures:
https://github.com/sympy/sympy/actions/runs/6292982121/job/17082929352
Some are due to this printing change:
https://github.com/sympy/sympy/pull/25673#issuecomment-1719198065
I'm not sure yet that I like that printing change but also not sure
what Sage would want to do about it if SymPy keeps it. Would Sage just
want to accept that change in output?
An example failure is:
**
8567File "src/sage/doctest/forker.py", line 151, in
sage.doctest.forker.init_sage
8568Failed example:
8569 print(PrettyPrinter(settings={'wrap_line': True}).doprint(s))
8570Expected:
8571 29 28 27 26 25 24 23 22 21 20 19 18 17
8572 x + x + x + x + x + x + x + x + x + x + x + x + x +
8573
8574 16 15 14 13 12 11 10 9 8 7 6 5 4 3
8575 x + x + x + x + x + x + x + x + x + x + x + x + x + x + x
8576
8577 2
8578 + x
8579Got:
8580 29 28 27 26 25 24 23 22 21 20 19 18 17 ↪
8581 x + x + x + x + x + x + x + x + x + x + x + x + x + ↪
8582
8583 ↪ 16 15 14 13 12 11 10 9 8 7 6 5 4 3 ↪
8584 ↪ x + x + x + x + x + x + x + x + x + x + x + x + x + x + ↪
8585
8586 ↪ 2
8587 ↪ x + x
Basically some ↪ arrows are used when wrapping long output lines.
Another doctest failure is due to this change in hyper. The doctest
just needs updating:
https://github.com/sympy/sympy/pull/25641
Failed example:
8800 hypergeometric((5, 4), (4, 4), 3)._sympy_() # needs sage.symbolic
8801Expected:
8802 hyper((5, 4), (4, 4), 3)
8803Got:
8804 hyper((5,), (4,), 3)
There is another doctest failure that I don't understand:
File "src/sage/groups/finitely_presented.py", line 1771, in
sage.groups.finitely_presented.FinitelyPresentedGroup.characteristic_varieties
9400Failed example:
9401 G.characteristic_varieties(groebner=True)
9402Expected:
9403 [[(f1 - 1, f2 - 1, f3 - 1),
9404 (f1 + 1, f2 - 1, f3 - 1),
9405 (f1 - 1, f2 - 1, f3 + 1),
9406 (f3^2 + 1, f1 - f3, f2 - f3),
9407 (f1 - 1, f2 + 1, f3 - 1)],
9408 [(f1 - 1, f2 - 1, f3 - 1),
9409 (f1*f3 + 1, f2 - 1),
9410 (f1*f2 + 1, f3 - 1),
9411 (f2*f3 + 1, f1 - 1),
9412 (f2*f3 + 1, f1 - f2),
9413 (f2*f3 + 1, f1 - f3),
9414 (f1*f3 + 1, f2 - f3)]]
9415Got:
9416 [[(f1 - 1, f2 - 1, f3 - 1),
9417 (f1 + 1, f2 - 1, f3 - 1),
9418 (f1 - 1, f2 - 1, f3 + 1),
9419 (f3^2 + 1, f1 - f3, f2 - f3),
9420 (f1 - 1, f2 + 1, f3 - 1)],
9421 [(f2*f3 + 1, f1 - f2),
9422 (f2*f3 + 1, f1 - f3),
9423 (f2*f3 + 1, f1 - 1),
9424 (f1*f3 + 1, f2 - f3),
9425 (f1 - 1, f2 - 1, f3 - 1),
9426 (f1*f2 + 1, f3 - 1),
9427 (f1*f3 + 1, f2 - 1)]]
How exactly is Sage using SymPy in this calculation?
It looks like the order of the output has changed but I don't know
what caused that change or if that should be considered a bug (in
either SymPy or Sage). Does the order matter here?
Another doctest failure is just a change in the printing code:
File "src/sage/symbolic/expression.pyx", line 1196, in
sage.symbolic.expression.Expression._unicode_art_
14804Failed example:
14805 unicode_art(SR(1.3 - I))
14806Expected:
14807 1.3 - ⅈ
14808Got:
14809 1.3 - 1.0⋅ⅈ
The SymPy expression being printed here does have a 1.0 in it. I don't
know if it is intentional that Sage puts the 1.0 there but the
printing change is correct for SymPy. Either the docstring needs to be
updated or perhaps Sage should not be putting the 1.0 there (I don't
know what Sage intends to do in this context).
--
Oscar
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/CAHVvXxQ89s1e91RK1U88V78gOkqjMktPM2D%3DC26h-0eJf2gfJQ%40mail.gmail.com.
Re: [sage-devel] Re: Sage CI Failing in SymPy GitHub Actions
> On Sunday, September 24, 2023 at 11:46:05 AM UTC-7 Oscar Benjamin wrote: > >> Where would I send the PR for the Sage doctests? On Sun, 24 Sept 2023 at 20:48, Matthias Koeppe wrote: > > I've added this to ci-sage.yml to explain what to do: > > # To test with a Sage PR, use this: > #sage_ref: refs/pull/PR_NUMBER/merge So currently the SymPy Sage CI job points at: https://github.com/sagemath/sage/pull/36276 So if there are doctest updates needed I guess the workflow is: - Open a PR against sagemath/sage with the needed (doctest or other) changes - Make SymPy's Sage CI job point at that PR Then when the time comes for Sage to update its SymPy version someone will incorporate the changes from that PR somehow? -- Oscar -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxQ9W8Zr3Udf9MjxGjysXjwNASva77dS8Pib_7i4BQLkCQ%40mail.gmail.com.
Re: [sage-devel] Re: Sage CI Failing in SymPy GitHub Actions
On Sun, 24 Sept 2023 at 18:47, Matthias Koeppe wrote: > > PR https://github.com/sympy/sympy/pull/25728 updates the workflow. Apologies > for not submitting this fix earlier. > PRs updating the Sage doctests for changes in SymPy are very welcome. Thanks Matthias. Where would I send the PR for the Sage doctests? Previously there was an open Sage ticket that was for updating SymPy and was intended to be compatible with the SymPy master branch. If there was a doctest change because of e.g. a change in SymPy between 1.12 and master then the updated doctest just went into the ticket rather than being merged directly into Sage. Then the SymPy CI job would use that ticket so that it was testing the combination of SymPy changes since previous SymPy release with the changes that would also be needed in Sage to update to the next SymPy release. Now the CI job says: > sage_ref: develop Does that mean that I should send PRs to a Sage develop branch? Would that already test with SymPy's master branch? -- Oscar -- Oscar -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxTo78%3D-gNwEvEJgOOLYmKiW3befzx_SSu9G7iDuz5B03Q%40mail.gmail.com.
Re: [sage-devel] Re: Sage CI Failing in SymPy GitHub Actions
On Sun, 24 Sept 2023 at 09:50, Dima Pasechnik wrote: > > On Sun, Sep 24, 2023 at 9:21 AM Tirthankar Mazumder > wrote: > > > > Sorry to resurrect such an old thread, but the Sage CI is failing for SymPy > > again. This time, it looks to me like the issue is the fact that GitHub > > Actions is trying to pull the Sage code from trac, which shouldn't be > > happening because SageMath moved to GitHub some time back. > > Which actions are you referring to? Something here: > https://github.com/scipy/scipy/actions > ? > Somewhere else? > Please point out at concrete GitHub Actions where you see this. We're talking about this: https://github.com/sympy/sympy/blob/master/.github/workflows/ci-sage.yml https://github.com/sympy/sympy/actions/runs/628439/job/17065717301 Before the GitHub transition this CI job was set to test the master branch of SymPy against a particular trac ticket. The trac ticket would hold the changes needed for Sage to update to the next SymPy versions. When this CI job was working properly I submitted updates to the trac ticket (mostly just updating doctests) so that Sage was ready to update to the next SymPy version. The job is useful if it usually passes so that we can see when a change in SymPy breaks something but it just fails all the time right now. I'm not sure what the equivalent of that trac ticket would be now (a pull request somewhere?) or how to set up the CI job so that it can track that ticket. Mostly the changes needed before were to do with changes in SymPy's printing output and also Laplace transform calculations. The Laplace transform code in SymPy has largely been rewritten in recent releases including significant changes to inverse_laplace_transform since the last release that have not been tested against Sage as far as I know. Probably some Sage doctests need to be updated already. -- Oscar -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxTQ_eazEZyaM%3Dz4oZYoup4rEWfhg0BXFNyLZ9%3Dy7DDOXg%40mail.gmail.com.
Re: [sage-devel] Python return types
On Wed, 6 Sept 2023 at 18:24, John H Palmieri wrote: > > For a while now, Python has allowed return types to be specified in > signatures: > > def f() -> int: > > It is my understanding that this doesn't actually do any error-checking or > type-checking — see https://docs.python.org/3/library/typing.html. So this > works without error: > > def f() -> float: > return "hello" > > This is cropping up in the Sage library. The file combinat/permutation.py has > several methods that claim (according to their signature) to return an > `Integer` but actually return an `int`, and this has led to at least one > person being confused (a recent post on stackexchange cited in the github > issue). Anyway, I've opened https://github.com/sagemath/sage/issues/36198 for > one of these instances, and we should be aware of this. We have had this issue in SymPy as well. Contributors want to add the type hints because they think it is good practice and many Python editors even suggest these hints automatically now. The hints are actually very useful for end users because editors can interpret them and use them for autocomplete etc. I showed some examples here: https://github.com/sympy/sympy/pull/25103 The hints are also useful for picking up bugs if used uniformly throughout the codebase but it is difficult to get that benefit incrementally in a large codebase with lots of legacy code. The hints are worse than useless if they are not correct though. Without any checking the hints are very likely to be incorrect. I suggest disallowing hints unless there is actually a type-checker running that will reject incorrect hints. When I enabled mypy in SymPy's CI almost all of the work involved was fixing all of the incorrect type hints that had already been added so I suggest not allowing those to build up. I also suggest choosing pyright over mypy if wanting to use a typechecker because it is more principled and consistent (basically just better AFAICT) and also pyright is what is used in all the editors that are the main consumers of the hints anyway. -- Oscar -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxQYy_T_S0GH%3DS1OCq%2BZEOQZ8Nu8U_h2%3DEvuNYYMF9Ot9A%40mail.gmail.com.
Re: [sage-devel] remove definitions of __ne__?
On Sat, 2 Sept 2023 at 12:43, 'Martin R' via sage-devel wrote: > > Actually, it seems that I have already found an instance of the problem you > describe, except that I do not understand it. > > In sage/algebras/jordan_algebra.py we have two "def __ne__", one in > JordanAlgebraSymmetricBilinear and one in SpecialJordanAlgebra. > > If I remove them (moving the tests to those of __eq__), the following fails: > > sage: m = matrix([[0,1],[1,1]]) > sage: J. = JordanAlgebra(m) > sage: x = 4*a - b + 3*c > sage: x != J((4, (-1, 3))) > False > > I have no idea why, the element class is defined directly in the parent > JordanAlgebraSymmetricBilinear, and inherits only from AlgebraElement. > > Apparently, the problem also arises, if _richcmp_ is implemented in a > superclass. I think I knew that once... Oh, that's a good point. The cases in sympy where __ne__ was needed were from subclassing builtin types like dict. Probably that applies to any (Python or Cython?) subclass of a Cython class that implements __richcmp__ for exactly the same reason. Possibly that means that the situation is more complicated in Sage than in a pure Python codebase. There was also one other case in SymPy where __ne__ was needed although I don't remember where. Theoretically it should have been possible to remove the __ne__ method but it caused a test failure under PyPy. Let me dig it up... Oh here is the (most recent) PR. I remembered wrong and it was in fact never merged: https://github.com/sympy/sympy/pull/23321 The sticking point was that we never isolated the difference in behaviour between CPython and PyPy for UndefinedFunction.__ne__ (this will be something to do with metaclasses). PyPy might not be relevant for Sage but I think it does at least demonstrate that removing __ne__ methods is not as trivial as you might hope and quoting myself from the PR: > You need to understand that removing these __ne__ methods is really not a > high-priority improvement to the codebase. Literally nothing is fixed by > making this change but there is the potential to break something. Probably some contributors were a bit disheartened by this statement but it is true: literally nothing would be fixed by removing the __ne__ methods. We can shave 200 *probably* redundant lines from an 80 line codebase but that's about it and there is definitely a nonzero risk of introducing bugs. (The reason for the disheartening is that the issue had originally been labelled as "easy to fix" which is supposed to be an invitation for new contributors to be coached through submitting a simple PR but then as sometimes happens it turned out not to be as easy as expected because it is definitely not as trivial as just deleting all the __ne__ methods. When it turns out that investigating/reviewing a change is much harder than editing the code and making the tests pass the issue is no longer suitable for new contributors.) -- Oscar -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxRHo66ugbSivBem0%2BVZSOZEG8s3Mr3JHgKXF%3DMi1K27Pg%40mail.gmail.com.
Re: [sage-devel] remove definitions of __ne__?
On Sat, 2 Sept 2023 at 12:15, 'Martin R' via sage-devel wrote: > > On Saturday, 2 September 2023 at 11:39:12 UTC+2 Oscar Benjamin wrote: > > On Sat, 2 Sept 2023 at 08:44, 'Martin R' via sage-devel > wrote: > > ... > > It is easy for this sort of thing to be overlooked in test code and in fact > messing with __eq__/__ne__ (more so __eq__) can invalidate much of the > test suite so I would tread carefully. > > Could you provide an example? I would think that in such a case a doctest > should catch the problem - what other purpose would a doctest have? It is not so much an issue with doctests but in SymPy most tests are pytest-style tests that look something like: def test_A(): assert A(1) == A(10) assert A(2) == A(7) assert A(3) != A(5) ... Now if you change your class A to look like: class A: def __eq__(self, other): return True def __ne__(self, other): return True Then your test suite will pass regardless of what any of the rest of the code does because every == or != returns True all the time. Obviously you would not literally write "return True" but an undetected bug having that sort of effect could invalidate many of the tests so you have to be very careful how you write and test methods like __eq__ and __ne__. That would make me nervous about wholesale removal of __ne__ without some careful checking because it is not *always* the case that removing __ne__ will have no effect. The first contributor who submitted a PR for this in SymPy did not do careful checking and did not seem to understand all of the implications of removing __ne__ and so I did not trust the PR to be merged regardless of the tests eventually passing (when the __ne__ methods that were still needed were restored). Subsequently the PR was rewritten by a more experienced contributor and then merged. Some other contributors seemed not to appreciate my concern over this at the time but at least for SymPy removing some harmlessly redundant __ne__ methods brought close to zero benefit in exchange for a moderate risk of introducing bugs. -- Oscar -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxQrhhbDJSijpb5Mo4071FPsg6vU13TT_SbkPK%2B2O6GJLg%40mail.gmail.com.
Re: [sage-devel] remove definitions of __ne__?
On Sat, 2 Sept 2023 at 08:44, 'Martin R' via sage-devel wrote: > > If I understand correctly, in python3 it is no longer necessary to implement > __ne__, if it is simply the negation of __eq__. > > There are currently about 200 definitions of the form > > def __ne__(self, other): > return not (self == other) > > I think it would be good to remove them. SymPy removed most of its __ne__ methods but a few had to be kept. The exception is that if any superclass defines __ne__ then a subclass that overrides __eq__ must also override __ne__ to keep them consistent. Obviously if you control both classes then you can remove __ne__ from both but in SymPy's case some classes subclass builtin types that cannot be changed: class PolyElement(dict): def __eq__(self, other): # override dict.__eq__ def __ne__(self, other): # also need to override dict.__ne__ I don't know if that applies to any of the 200 __ne__ methods in Sage but I would check the mro in each case before removing __ne__. It is easy for this sort of thing to be overlooked in test code and in fact messing with __eq__/__ne__ (more so __eq__) can invalidate much of the test suite so I would tread carefully. -- Oscar -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxQ9Ab9FoFLT5Amn7NMErt43oO0CCeSDOWk4MTqDfbkGnQ%40mail.gmail.com.
Re: [sage-devel] Re: VOTE: Follow NEP 29: Recommended Python version
On Fri, 26 May 2023 at 16:19, William Stein wrote:
>
> On Fri, May 26, 2023 at 7:57 AM wrote:
> > > a) Sage has a dual role as a library ("project") and as a distribution.
> > > NEP
> > > 29 was designed for projects, and not for software distributions.
> >
> > No, Sage is just a project, with lots of dependencies (way too many).
> > It's not a software distribution in any way, it does not include
> > essential tools to build it (e.g. no C/C++ compiler on macos).
...
>
> In the nearly two decades since starting Sage, software distribution
> and the Python
> ecosystem have improved enough that there is hope that Sage could
> transition to just
> being a bunch of libraries, and all the distribution gets handled by some
> third party distribution such as conda (etc.). That's been discussed
> with great optimism
> recently on this list.
>
> I hope soon Sage isn't a distribution, but right now it still is.
Usually a distribution tries to include everything so that it can
constrain the versions. That would imply that if Sage is a
distribution then it should also distribute its own Python or the Sage
versions should be constrained by the Python versions. Then it would
not be necessary for any single version of Sage to have compatibility
with multiple versions of Python. A Linux distro does not try to
support many different Python versions using the same versions of
Python packages. Each version of the distro will update the Python
version and also the version of NumPy, SymPy etc simultaneously.
The intention of NEP 29 is for various libraries such as NumPy to
coordinate on ensuring that there exists some mutually consistent set
of versions that can be used together either right now or some time in
the future. It isn't necessary for newer NumPy versions to support
significantly older Python versions because if you want to use an
older version of Python then you can just use an older version of
NumPy (which is precisely what a distro would do in any case). There
are then two ways that those consistent versions get used:
- Some people will use Python packaging tools to install the latest
versions of things from PyPI and the most recent versions of packages
are designed to be consistent with the most recent versions of Python.
- Distributions like conda or Linux distros will use some consistent
set of older versions i.e. an older version of Python *and* older
versions of the packages.
It sounds to me like Sage is trying to live in between these two
things and potentially ends up trying to mix older and newer versions
together which will always be painful because no one else is trying to
make that work.
What is wrong with Sage just saying that an older version of an
operating system only works with an older version of Sage?
Maybe if you want to use the latest version of Sage on some old
version of Debian then you should just install a newer version of
Python first?
Sage 10 might be better than Sage 9 but Sage 9 was still good before
Sage 10 came along. Is it so bad that someone might need to wait until
they are ready to upgrade other things before getting the latest
version of Sage?
There are many different levels at which you can ask these questions
about exactly which new things should be compatible with which older
things. The purpose of NEP 29 is that there should exist some rolling
set of consistent package versions that aligns with the releases of
Python itself. It is then up to downstream to decide whether they want
the latest stuff fresh off the press today or if they would rather
wait and use 5 years old versions of things.
> There are follow up discussions, just like this one, by other projects, e.g.,
> for sympy here:
> https://github.com/sympy/sympy/issues/21884,
The situation for SymPy is very different from NumPy because it is
really not a big burden for SymPy to support Python 3.8 being only
pure Python. SymPy's release is just a single wheel that works on any
OS, all versions of Python, both CPython and PyPy etc. NumPy has to
provide and test many more binaries and also uses CPython's C API
which has bigger cost in compatibility problems across Python
versions.
That being said the cost to SymPy is not zero and in some ways
discussions like this about which version to support can just be time
wasted that could be spent on better things. In the SymPy issue
Matthias suggested that it is useful for Sage if SymPy continues to
have wider version support. Since it is not a big cost it is fine for
SymPy to do that. Otherwise though I would probably push for SymPy
adopting NEP 29 just because it is a documented policy and it is good
if everyone both in the project and downstream can see a clear policy
and knows what to expect.
--
Oscar
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web
Re: [sage-devel] Re: Problematic SR interpretation of radicals (and non-integer rational exponents) in Sage.
In the notebook you note that the results returned by sympy "do not check".
I suspect this is because sympy's solve function is being called with
check=False under the hood:
In [43]: x = symbols('x')
In [44]: eq = sqrt(x) + cbrt(x) + 2
In [45]: print(solve([eq], [x]))
[]
In [46]: print(solve([eq], [x], check=False))
[((1 + (3*sqrt(87) + 28)**(1/3) + (3*sqrt(87) +
28)**(2/3))**6/(729*(3*sqrt(87) + 28)**2),), ((-4 + (1 - sqrt(3)*I)*(2 - (1
- sqrt(3)*I)*(3*sqrt(87) + 28)**(1/3))*(3*sqrt(87) +
28)**(1/3))**6/(46656*(1 - sqrt(3)*I)**6*(3*sqrt(87) + 28)**2),), ((-4 + (1
+ sqrt(3)*I)*(2 - (1 + sqrt(3)*I)*(3*sqrt(87) + 28)**(1/3))*(3*sqrt(87) +
28)**(1/3))**6/(46656*(1 + sqrt(3)*I)**6*(3*sqrt(87) + 28)**2),)]
With radical equations like this sympy's solve will transform them to
polynomial equations and compute all solutions to the polynomial equations.
Transforming to polynomials introduces spurious solutions so solve then
checks to see which of the solutions satisfy the original radical
equations. Passing check=False means that the checking is disabled and so
you get all solutions to the polynomial equation which may or may not be
solutions to the radical equation.
--
Oscar
On Sat, 6 May 2023 at 10:28, Emmanuel Charpentier <
emanuel.charpent...@gmail.com> wrote:
> *Typo* in the preceding message : The polynomial system is of course |x2^2-x1,
> x3^3-x1, x2+x3+2]
>
> Sorry for the noise !
>
> Le samedi 6 mai 2023 à 11:25:07 UTC+2, Emmanuel Charpentier a écrit :
>
>> TLDR : Sage easily gets the roots of the polynomial system |x2^2-x1,
>> x3^4-x1, x2+x3+2] but interprets [image: \sqrt[3]{x}+\sqrt{x}+2]
>> inconsistently : this expression is *not* zero for the above roots.
>>
>> Details : see the enclosed Jupyter Lab sheet.
>>
>> This seems to be little discussed in Sage documentation. Is it worth to
>> discuss it ?
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/dc5d995c-e76c-4e5b-89f9-beb640a1b9e8n%40googlegroups.com
>
> .
>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/CAHVvXxSQUc5J%2B1eVAWYmNWdf4mg_NTeL%2BBWZ7L%3DRKCOLMOJTrQ%40mail.gmail.com.
Re: [sage-devel] What is the status of sympy in sagemath? In particular the integrator.
On Thu, 27 Apr 2023 at 06:25, 'Martin R' via sage-devel
wrote:
>
> On Wednesday, 26 April 2023 at 21:06:30 UTC+2 Oscar Benjamin wrote:
>>
>> One thing Sage could do with SymPy's RootSum is to call doit which
>> will expand using radical formulae if possible:
>>
>> x**2/(3*a**2 + 3*a*b*x**3) + RootSum(729*_t**3*a**4*b**2 + 1,
>> Lambda(_t, _t*log(81*_t**2*a**3*b + x)))
>>
>> In [37]: x, a, b, _t = symbols('x, a, b, _t')
>>
>> In [38]: expr = x**2/(3*a**2 + 3*a*b*x**3) +
>> RootSum(Poly(729*_t**3*a**4*b**2 + 1, _t), Lambda(_t,
>> _t*log(81*_t**2*a**3*b + x)))
>>
>> In [39]: print(expr)
>> x**2/(3*a**2 + 3*a*b*x**3) + RootSum(729*_t**3*a**4*b**2 + 1,
>> Lambda(_t, _t*log(81*_t**2*a**3*b + x)))
>>
>> In [40]: print(expr.doit())
>> x**2/(3*a**2 + 3*a*b*x**3) +
>> (-1/(a**4*b**2))**(1/3)*log(a**3*b*(-1/(a**4*b**2))**(2/3) + x)/9 +
>> (-(-1/(a**4*b**2))**(1/3)/18 -
>> sqrt(3)*I*(-1/(a**4*b**2))**(1/3)/18)*log(81*a**3*b*(-(-1/(a**4*b**2))**(1/3)/18
>> - sqrt(3)*I*(-1/(a**4*b**2))**(1/3)/18)**2 + x) +
>> (-(-1/(a**4*b**2))**(1/3)/18 +
>> sqrt(3)*I*(-1/(a**4*b**2))**(1/3)/18)*log(81*a**3*b*(-(-1/(a**4*b**2))**(1/3)/18
>> + sqrt(3)*I*(-1/(a**4*b**2))**(1/3)/18)**2 + x)
>
> If I recall correctly, this is what I did for the FriCAS interface. It would
> be nice to factor out any common functionality, if possible.
Obviously though the RootSum is better than the radicals which is why
it is used in the first place so the ideal solution would be to
preserve the RootSum. The simple case above already shows that it is
better but in others the radical formulae can explode and in more
complicated cases formulae won't even exist.
--
Oscar
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/CAHVvXxQVU9E_-JNtasmSc-McVbdts7tkQUhLBDjhKj11HDXMGg%40mail.gmail.com.
Re: [sage-devel] What is the status of sympy in sagemath? In particular the integrator.
One thing Sage could do with SymPy's RootSum is to call doit which
will expand using radical formulae if possible:
x**2/(3*a**2 + 3*a*b*x**3) + RootSum(729*_t**3*a**4*b**2 + 1,
Lambda(_t, _t*log(81*_t**2*a**3*b + x)))
In [37]: x, a, b, _t = symbols('x, a, b, _t')
In [38]: expr = x**2/(3*a**2 + 3*a*b*x**3) +
RootSum(Poly(729*_t**3*a**4*b**2 + 1, _t), Lambda(_t,
_t*log(81*_t**2*a**3*b + x)))
In [39]: print(expr)
x**2/(3*a**2 + 3*a*b*x**3) + RootSum(729*_t**3*a**4*b**2 + 1,
Lambda(_t, _t*log(81*_t**2*a**3*b + x)))
In [40]: print(expr.doit())
x**2/(3*a**2 + 3*a*b*x**3) +
(-1/(a**4*b**2))**(1/3)*log(a**3*b*(-1/(a**4*b**2))**(2/3) + x)/9 +
(-(-1/(a**4*b**2))**(1/3)/18 -
sqrt(3)*I*(-1/(a**4*b**2))**(1/3)/18)*log(81*a**3*b*(-(-1/(a**4*b**2))**(1/3)/18
- sqrt(3)*I*(-1/(a**4*b**2))**(1/3)/18)**2 + x) +
(-(-1/(a**4*b**2))**(1/3)/18 +
sqrt(3)*I*(-1/(a**4*b**2))**(1/3)/18)*log(81*a**3*b*(-(-1/(a**4*b**2))**(1/3)/18
+ sqrt(3)*I*(-1/(a**4*b**2))**(1/3)/18)**2 + x)
A more precise instruction would be:
expr.replace(lambda e: isinstance(e, RootSum), lambda e: e.doit(deep=False))
--
Oscar
On Wed, 26 Apr 2023 at 19:26, Dima Pasechnik wrote:
>
> Thanks for showing this. As far as I know, the problem is that Sage does not
> support RootSum expressions - although they are very useful for integration
> in particular.
>
>
> On Wed, 26 Apr 2023, 19:22 'Nasser M. Abbasi' via sage-devel,
> wrote:
>>
>> I use sagemath to run the independent CAS integrations tests for Fricas,
>> Giac and Maxima, since it is much easier to use the same script to all CAS
>> systems instead of learning how to use each separate CAS. The result is put
>> on this page.
>>
>> I found that sympy now can be used from sagemath.
>>
>> So I said, great. Instead of having separate script for sympy in python will
>> use the same sagemath script and just change the name of the algorithm to
>> 'sympy'. Makes life easier.
>>
>> But when I tried this on one test file, I found many integrals now fail,
>> where they work using sympy directly in Python.
>>
>> I am not sure if this is because sympy is not yet fully yet supported in
>> sagemath or if this is just a bug and overlooked support.
>>
>> For example, on this one file, sympy used to score 84.66% passing score
>> when used directly, but now in sagemath it scores 65.64%.
>>
>> This translates to about 30 more integrals failing in this file of 163
>> integrals.
>>
>> Below will give one example. All seem to give the same exception
>>
>> NotImplementedError('conversion to SageMath is not implemented')
>>
>> Here is one example in sagemath 9.8
>>
>> var('A B a alpha b beta m n x ')
>> integrate(x/((b*x^2+a)^m),x, algorithm='sympy')
>>
>> ---
>> NotImplementedError Traceback (most recent call last)
>> Cell In [2], line 1
>> > 1 integrate(x/(b*x**Integer(3)+a)**Integer(2),x, algorithm='sympy')
>>
>> File ~/TMP/sage-9.8/src/sage/misc/functional.py:773, in integral(x, *args,
>> **kwds)
>> 648 """
>> 649 Return an indefinite or definite integral of an object ``x``.
>> 650
>>(...)
>> 770
>> 771 """
>> 772 if hasattr(x, 'integral'):
>> --> 773 return x.integral(*args, **kwds)
>> 774 else:
>> 775 from sage.symbolic.ring import SR
>>
>> File ~/TMP/sage-9.8/src/sage/symbolic/expression.pyx:13211, in
>> sage.symbolic.expression.Expression.integral()
>> 13209 R = SR
>> 13210 return R(integral(f, v, a, b, **kwds))
>> > 13211 return integral(self, *args, **kwds)
>> 13212
>> 13213 integrate = integral
>>
>> File ~/TMP/sage-9.8/src/sage/symbolic/integration/integral.py:1063, in
>> integrate(expression, v, a, b, algorithm, hold)
>>1061 if not integrator:
>>1062 raise ValueError("Unknown algorithm: %s" % algorithm)
>> -> 1063 return integrator(expression, v, a, b)
>>1064 if a is None:
>>1065 return indefinite_integral(expression, v, hold=hold)
>>
>> File ~/TMP/sage-9.8/src/sage/symbolic/integration/external.py:69, in
>> sympy_integrator(expression, v, a, b)
>> 67 else:
>> 68 result = sympy.integrate(ex, (v, a._sympy_(), b._sympy_()))
>> ---> 69 return result._sage_()
>>
>> File ~/TMP/sage-9.8/src/sage/interfaces/sympy.py:216, in _sympysage_add(self)
>> 214 s = 0
>> 215 for x in self.args:
>> --> 216 s += x._sage_()
>> 217 return s
>>
>> File
>> ~/TMP/sage-9.8/local/var/lib/sage/venv-python3.11.1/lib/python3.11/site-packages/sympy/core/basic.py:1959,
>> in Basic._sage_(self)
>>1957 sympy_init() # may monkey-patch _sage_ method into self's class or
>> superclasses
>>1958 if old_method == self._sage_:
>> -> 1959 raise NotImplementedError('conversion to SageMath is not
>> implemented')
>>1960 else:
>>1961 # call the freshly monkey-patched method
>>1962 return self._sage_()
>>
>>
>> Here is same integral in sympy itself. You see it works.
Re: Re: [sage-devel] ChatGPT is an expert in SageMath too
On Fri, 21 Apr 2023 at 20:36, William Stein wrote: > > There's is a discussion right now on HN about LLM's trained on code > > https://news.ycombinator.com/item?id=35657982 > > One of the comments https://news.ycombinator.com/item?id=35658118 > points out that most of the non-GPL super permissive licenses require > explicit attribution when creating derived works. If the output of an > LLM is a derived work (and not just some fair use of that input), then > there is legally nothing particularly special about GPL in the context > of training LLM's. That I think successfully undercuts my point in > starting this thread. I don't think GPL or other licenses really matter here. It won't be long before these models can produce code that is sufficiently original/distinct that it would not be considered "derived" anyway. The fact that the model happened to learn in part from looking at lots of code with different licenses is not really that different from the way that humans learn programming. If I happen to look at the Sage source code and learn something in the process it does not mean that Sage's GPL conditions apply to all future code I write after gaining that knowledge. There is a spectrum from using knowledge learned from code through to adapting the code and in the extreme just copying the code. Pretty soon these models will be able to position themselves wherever you want on that spectrum. -- Oscar -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxSKzm3QHxQqSx5-k8kpFZFxOSf368eCUnM-3TqM04GN-w%40mail.gmail.com.
Re: [sage-devel] RealField isn't doing it right
On Sun, 16 Apr 2023 at 15:52, Trevor Karn wrote: > > I don't have much understanding of how floating point arithmetic works, but > the argument > > >If you're writing python code, you should expect 2*0.5 to return a > >float. But if you're learning linear algebra for the first time and > >typing a matrix into the Sage notebook, typing 0.5 instead of 1/2 > >should not ruin the entire assignment without so much as a warning. > > seems important to me. I also sometimes worry that Sage seems to be written > for users who are both experts in [insert mathematical field here] and > Python. This prevents (a) mathematical experts who don't know python from > using Sage and (b) more junior students from using sage. Maybe one can make > the argument that mathematical experts should just learn python (although I > would disagree), but I think (b) is a genuine problem. Mathematica doesn't > seem to require the user to be expert in either math or Wolfram language (or > maybe I haven't used it enough). I don't have an actionable complaint here, > but it is something I encounter when helping folks around my math department > with their code. I'm trying to keep it in mind as I develop code. This hardly requires expert knowledge of Python but rather just the understanding that 0.5 means a floating point number and then some understanding of the implications of floating point numbers on exactness. This is not uniquely a feature of Python by any stretch. The use of a decimal point to denote approximate or floating point numbers is the same in Mathematica, Maple, Maxima, Matlab, and not just Python but most general purpose programming languages. You can see the Mathematica and Maple docs explaining this here: https://www.maplesoft.com/support/help/maple/view.aspx?path=float https://reference.wolfram.com/language/howto/ChangeTheFormatOfNumbers.html Select quotes from there: > > > Enter an approximate real number by explicitly including a decimal point: > > > The presence of a floating-point number in an expression generally > > > implies that the computation will use floating-point evaluation. > > > any calculation mixing exact and approximate numbers gives an approximate > > > result The fact that writing 0.5 (rather than 1/2) implies the use of floating point which in turn implies rounding errors and inexactness is certainly something that can surprise beginners. In the context of Sage it could have been a valid choice not to do that and to have 0.5 mean an exact rational number when it appears as a literal in the user's code. There is no difficulty in making that work any more than making 1/2 return a rational number (since in Python itself 1/2 is a float). This is a design choice though and using decimal literals for floats is useful for anyone who actually wants to do calculations with floats since it means that there is a succinct syntax for floats as well as a separate syntax for exact rationals. > I see that > > sage: A = matrix([[-3, 2, 1 ],[ 2,-4, 4 ], [ 1, 2,-5 ]]) > sage: B = (2*0.5*A) > sage: rank(B) > 3 > > What about floating point arithmetic makes this break? I print (B) and see > > [-3.00 2.00 1.00] > [ 2.00 -4.00 4.00] > [ 1.00 2.00 -5.00] > > which doesn't have any obvious reason to be not rank-2. Could someone ELI5? Arithmetic is needed to be able to compute the rank. With floats that arithmetic is going to be approximate and will have some rounding error. Knowing that the rank is 2 here requires knowing that the third row is *exactly* equal to some linear combination of the first and second but rounding errors will make the linear combinations not be exactly equal. It is basically impossible to compute the rank of a matrix using inexact arithmetic since the tiniest rounding errors will make most matrices appear to be full rank. That does not stop there being floating point routines for computing the rank but they work differently, are inherently heuristic and need thresholds as discussed here: https://numpy.org/doc/stable/reference/generated/numpy.linalg.matrix_rank.html NumPy's matrix_rank function does give the expected answer here and is probably a better implementation of this for machine precision: sage: np.linalg.matrix_rank(B) 2 The Mathematica docs have a caveat about computing the rank of a matrix of floats: https://reference.wolfram.com/language/ref/MatrixRank.html Under the "possible issues" section it says: > > > Use machine arithmetic. Machine numbers cannot distinguish between 9 and > > > 9 + 1e-20 It then shows an example in which the rank of a matrix of floats is computed incorrectly. With that example NumPy fails for the same reason: sage: A = np.array([[1, 2, 3], [4, 5, 6], [7, 8, 9 + 1e-20]]) sage: A array([[1., 2., 3.], [4., 5., 6.], [7., 8., 9.]]) sage: np.linalg.matrix_rank(A) 2 It is not that the matrix_rank function gets anything
Re: [sage-devel] RealField isn't doing it right
On Sat, 15 Apr 2023 at 22:39, aw wrote: > >A user should be able to send any argument to a function, and it's the >responsibility of the programmer to make sure one of two things happen: > > (a) the user is given the right answer; > or (b) the user is given no answer and an error message. That is quite a strong requirement. I guess the programmer needs to build a program that ignores what the user actually types in and instead understands what they want some other way (psychically?). That way the user can call any functions with any arguments but the program will always do what the user wanted it to do regardless of what code they entered. Seriously though, floating point is not something where responsibility can be *entirely* outsourced at *any* level. Anyone who wants to use floating point types/routines directly or indirectly needs to have some level of understanding of what the implications are even if that is as basic as just knowing that rounding errors can happen and knowing which operations might be affected by them. Explicitly mixing or converting between precisions as in these examples requires more care and understanding and it is just not possible for the "programmer" to eliminate that responsibility from the "user" altogether. > RealField(18)(RealField(12)(13/10)) (A) > > What should happen here is this: > RealField(12) should eval 13/10 as 1.30 > RealField(12) should pass to RealField(18) only those digits, 1.30 > RealField(18) should then zero-pad that to 18 bits, yielding 1.3000 That is what happens except that it happens in binary rather than decimal floating point. Binary floating point means that 13/10 in RealField(12) is already not exactly 1.3 which is why padding it with zero bits also gives something that is not exactly 1.3. The most accurate representation of 13/10 in RealField(18) is not just a zero-padded version of the result from RealField(12) so the conversion to higher precision does not recover the accuracy that is already lost: sage: RealField(12)(13/10) 1.30 sage: RealField(12)(13/10).as_integer_ratio() (1331, 1024) sage: 1331./1024 1.2998046875 sage: RealField(18)(RealField(12)(13/10)) 1.2998 sage: RealField(18)(RealField(12)(13/10)).as_integer_ratio() (1331, 1024) Notice as_integer_ratio gives the same result for the number in RealField(18) as in RealField(12). They are both the exact same number but they display differently because the decimal display representation depends on the precision of the field. -- Oscar -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxRjwYBAYRQW8kXHAY5QRO_uUcZjL4n0-tpACfWEjnZrUA%40mail.gmail.com.
Re: [sage-devel] OT: google's chatbot Bard is at https://bard.google.com/
On Sun, 26 Mar 2023 at 19:07, William Stein wrote: > > Ok, that "proof" from GPT-4 is pretty absurd nonsense to put it mildly. I > wonder if there will be a new surge in crank math papers this year. Apparently the way that the chat GPT models are trained is that the source data comes from having humans use them and then rate the quality of the answers they get given. Then they train a model to predict how humans would rate the answers and then they use that to train new iterations of GPT. After some iterations of that they go back to the humans again and so on. What that means is that ultimately the target of the chat models is to try to satisfy the humans who are using them in testing. They have used any old humans though rather than say "experts" so the goal is not to be "correct" but just to try to satisfy the human users. One implication of this training goal is that the models are optimised towards giving superficially plausible answers. A clever sounding but incorrect answer has a chance to satisfy a human who does not read carefully. A negative result like "Sorry I can't answer" is likely to receive a poor rating from most humans even if it is the most correct answer. Also these models will actually try to judge what sort of human you are. If your question suggests that you do know what you are talking about then the bot will try to give an answer that would please someone who knows what they are talking about. Naturally the converse applies as well. This means that the wording of your question can alter the answers that you receive in more ways than you might immediately expect. These models are called language models for good reason because they are really just trained to be good at language. Their ability to answer questions that seem to involve some reasoning is no different from a human BS-monger who can google for a bit and knows how to string some sentences together in a way that momentarily resembles the language of someone who knows what they are talking about. The limits of their actual reasoning are quite clear in the final part of this proof where we go from a theorem like algebraic^algebraic -> transcendental in one step to transcendental^transcendental -> transcendental. Quite apart from the bogus algebra this is a failure in pretty elementary logic. However I think that Chat GPT on some level *knows* that the logic is bogus. It has just scored that bogusness and decided that it is better than the alternatives it could generate for the problem at hand (and the user at hand!). If you castigate the bot and point out its fallacies or even just tell it lies then it will rework its answer to be some new BS it thinks you will be more likely to be satisfied by. -- Oscar -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxRw-b1KPe9DwwgPgK1-H9K36FBXYzT7L1PNBr11qerf%3Dw%40mail.gmail.com.
Re: [sage-devel] Github Discussions
On Wed, 8 Feb 2023 at 20:20, William Stein wrote: > > Many thanks for sharing this from the *developer* point of view. I'm very > much thinking about this problem entirely from the end-user-of-sage point > of view (i.e., me right now).Did you also encounter problems using > discussions with sympy from the end user point of view? I don't personally like the format(s) but I haven't seen users having problems with the interface itself. The quality of dialogue/interaction with users there is low though. The threads that have a reasonable dialogue are actually just developers talking to each other rather than users getting their questions answered. > Glancing at the sympy Discussions at > > https://github.com/sympy/sympy/discussions > > I had a positive impression, since there's a lot of activity, with > questions clearly marked "answered", etc. > So thanks for sharing how painful that can be from the dev side. What won't be obvious from a distance is that all of the people answering the questions are the same people who would normally respond to issues and would submit or review pull requests etc. In fact many of the people asking the questions are also people who are submitting pull requests so many are not really "user" questions. The mailing list has broader reach and there questions usually get asked and answered in the first instance by people who are not maintainers (more like "power users"). Likewise there are many people who answer questions on StackOverflow but who have little or no involvement on GitHub. The implication then is that Discussions can provide a support channel that is only watched by maintainers. Partly that's bad because it places additional burden on those maintainers but also compared to a mailing list it has no sense of community and no wider discussion. There are no other users watching the questions and answers and either learning from them or contributing their own solutions or follow up questions. That's also a loss because I think that other "users" will often have a very different perspective from the small group of maintainers and I think that community building is more important than providing immediate Q+A. -- Oscar -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxRuAT6nBu6-dbGKBmJqsQqJgABV9HA7GLv0se2ivHcy-w%40mail.gmail.com.
Re: [sage-devel] Github Discussions
On Wed, 8 Feb 2023 at 16:47, William Stein wrote: > > Hi Sage Devs, > > Any thoughts about enabling "Github Discussions" for SageMath on > Github now? I just want to share my experience of this feature being used in the SymPy GitHub repo because I personally think that enabling it was a mistake. I dislike the interface of the discussions feature but more importantly I think it's organisationally bad to use GitHub for end user support in a large project that has many users. In a smaller project that e.g. doesn't have a mailing list I can see how it might be useful for situations where someone wants to talk to the developers without having to create an open issue but I don't think that necessarily carries over to larger projects. Following and responding to notifications on a busy repo is time consuming and can be mentally draining. The pool of people who will do that is smaller than the pool of people who would subscribe to e.g. a mailing list. For example I am not going to subscribe to notifications from the SageMath repo but I am quite happy to skim messages on this mailing list and only occasionally respond to anything. The basic problem with GitHub's discussions feature is that it places the burden of user support on to the smaller group of people who are actively engaging with the repo. Those people are already dealing with the large number of incoming issues, bugs, feature requests, pull requests, new contributors etc and it is important not to make that any more difficult or time consuming than it needs to be. > This can be used much like ask.sagemath.org or sage-support, but is > more modern and easy to moderate.It's also very easy > to move a github issue to be a discussion, when somebody opens an > issue that really should just be a request for help. This is the one significant advantage of the discussions feature. Closing an issue as invalid is not nice for the person who opened the issue. Being able to transfer the issue to a discussion instead comes across less harshly. However from the perspective of the maintainer who would close an invalid issue the difficult part is deciding whether something is an issue or not. The fact that you can turn the issue into a discussion does not make it any less draining to have to decide (often with incomplete information) whether or not an issue is valid or even whether the person opening the issue intended for it to be a bug report rather than just a request for help. Personally I prefer for user support and discussion fora to be clearly separated from GitHub and to happen somewhere where there is a larger pool of people who can engage more recreationally rather than feeling any burden to respond. Those fora can triage problems around user confusion before it gets to the point of opening a GitHub issue. Ideally what would otherwise be invalid issues would be filtered out before they reach GitHub. If the desire is to have something more modern and easy to moderate than a mailing list then my suggestion would be to use Discourse forums. -- Oscar -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxTuOaypGK7ma2B-Jfon7C9Z%2B0brT1HPHPQFnRbVqRQ0Xg%40mail.gmail.com.
Re: [sage-devel] Merging fix for github CI
On Wed, 8 Feb 2023 at 13:10, David Roe wrote: > > On Wed, Feb 8, 2023 at 12:23 PM 'Martin R' via sage-devel > wrote: >> >> Why would I need write access to the sagemath repo? >> >> I would have thought that I'd "somehow" (no idea how) take over the branch >> and modify it. Or are pull requests directly tied to a specific user? In >> other words, what is the replacement for the following? > > Pull requests are from a specific user's fork of Sage. If you are not the > author of a PR but want to suggest changes to it, you have several options. ... > 3. If you're collaborating closely with the author, they can give you > permission to push to the branch from which the PR originates. Then you > could make your changes and push them directly. Note that permissions are > only possible on a repo basis, so they're actually giving you permission to > push to their whole fork of Sage, but this may be acceptable if they trust > you. Another option here is that when opening a PR there is a tickbox that says something like "Allow edits by maintainers". This box is ticked by default but the author can choose to untick it if they want. If the box is ticked then I think it means that anyone who would have permissions to merge the PR automatically has permissions to push to the PR's branch in the originating author's fork which will update the commits in the PR. -- Oscar -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxTxvBd42FCRGTjb7GUJpj%2BEoKZKcCzy%2BLC41jb5Z8JpcQ%40mail.gmail.com.
Re: [sage-devel] Re: Doubts about correctness of `integrate(floor(x)^2,x)`
On Fri, 3 Feb 2023 at 13:57, Georgi Guninski wrote:
>
> One of the reasons I asked this is to get correct closed form
> for stuff like sum/int 2^2^floor(x).
> Judging by the discussions, this won't work.
The integration part of that is easy and sage can do it for a single
integer interval:
>>> a = var('a')
>>> assume(a, 'integer')
>>> integrate(2^2^floor(x), (x, a, a+1))
2^(2^a)
Now you just need the summation of that over the range of integer
intervals you are interested in but Sage's sum can't do anything with
that and I'm not sure if anything else can either.
--
Oscar
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/CAHVvXxT6gWBt8Ky4abDVG6hSsO5_62m2EdE1ssYNXO1MPLWWpg%40mail.gmail.com.
Re: [sage-devel] Re: Doubts about correctness of `integrate(floor(x)^2,x)`
On Fri, 3 Feb 2023 at 09:31, Emmanuel Charpentier
wrote:
>
> BTW :
>
> ```
> sage: a, b = var("a, b")
> sage: f(x) = floor(x)^2
> sage: f(x).integrate(x, a, b)
> // Giac share root-directory:/usr/local/sage-9/local/share/giac/
> // Giac share root-directory:/usr/local/sage-9/local/share/giac/
> Added 0 synonyms
> No checks were made for singular points of antiderivative
> floor(sageVARa)^2*sageVARx for definite integration in [sageVARa,sageVARb]
> -a*floor(a)^2 + b*floor(a)^2
> ```
>
> Even accepting `x*floor(x)^2` as an antiderivative of `floor(x)`, this
> *definite* integral is wrong, *wrong*, **wrong**. One could expect :
>
> ```
> sage: F(x) = f(x).integrate(x) ; F
> x |--> x*floor(x)^2
> sage: F(b) - F(a)
> -a*floor(a)^2 + b*floor(b)^2
> ```
I guess somewhere it is assumed that indefinite integration can be
used in FTOC without checking for discontinuities. The result is then
valid as a definite integral only if both end points lie within an
interval in which the function is continuous. In this particular case
that might not seem like a very useful guarantee but there are
probably other cases where it means that integrate can return
something useful.
Simple cases like floor(x) can be patched up but it's much harder to
solve this in general. The question then is really what guarantee you
want the integrate function to uphold when there are symbolic
parameters because most of the time the choice will be between
returning something like the above or just not returning anything.
A case that is unambiguously wrong is this definite integral that has
no symbolic parameters:
>>> integrate(atan2(sin(x), cos(x)), x)
1/2*arctan(sin(x)/cos(x))^2
>>> integrate(atan2(sin(x), cos(x)), (x,0,pi))
0
Here the integrand actually is continuous within the interior of the
region of integration and really does have an antiderivative but the
antiderivative expression returned by integrate is not differentiable
at pi/2 even though the integrand is continuous there. In this case
the result from SymPy is better:
>>> integrate(atan2(sin(x), cos(x)), x))
atan2(sin(x), cos(x))**2/2
>>> integrate(atan2(sin(x), cos(x)), (x, 0, pi))
pi**2/2
That antiderivative expression is continuous and differentiable
throughout the *interior* of (-pi, pi) just like integrand itself. You
still have to be careful about the end points though so if the
integral goes to pi then it needs to be known whether the
antiderivative expression is valid when approaching pi from the left
or the right so basically a limit should be computed. An example where
SymPy gets this kind of thing wrong is
(https://github.com/sympy/sympy/issues/24004):
>>> integrate(sin(x)*atan2(sin(x), cos(x)), (x, -pi, pi))
0
>>> integrate(sin(x)*atan2(sin(x), cos(x)), (x, -pi+0.001, pi)).n()
6.28318373671672
>>> integrate(sin(x)*atan2(sin(x), cos(x)), x)
sin(x) - cos(x)*atan2(sin(x), cos(x))
Here the integrand is nonnegative and continuous although not
differentiable at the end points. The antiderivative expression is
discontinuous though. This happens because even though the integrand
is continuous our symbolic expression for it contains discontinuous
functions. The issue is not with the fundamental theorem of calculus
but rather specifically with the limitations of *symbolic*
differentiation and integration with expressions involving non-smooth
functions.
Sage also gets this example wrong but in a different way:
>>> integrate(sin(x)*atan2(sin(x), cos(x)), (x, -pi, pi))
0
>>> integrate(sin(x)*atan2(sin(x), cos(x)), x)
-2*arctan(-2*sin(x)/((sin(x)^2/(cos(x) + 1)^2 - 1)*(cos(x) + 1)))
/(sin(x)^2/(cos(x) + 1)^2 + 1)
+ 2*sin(x)/((sin(x)^2/(cos(x) + 1)^2 + 1)*(cos(x) + 1))
+ 2*arctan(sin(x)/(cos(x) + 1))
That expression is definitely wrong because its derivative is negative
for half of every 2*pi interval.
It could be possible to patch up SymPy's antiderivative by adding
something like 2*pi*floor((x-pi)/(2*pi)) which would give a valid
antiderivative in a formal sense but then that means using more
discontinuous functions in antiderivative expressions. I am not sure
that it actually is better to try to make indefinite integration
always return complete antiderivatives where discontinuous functions
are involved. The same applies in reverse when thinking about
differentiation: adding in delta functions is probably not helpful.
Rather I think that it just needs to be understood and documented that
there are limits to
symbolic differentiation and (indefinite) integration where
discontinuous functions are involved.
The Maple docs explicitly discuss this giving floor(x) as an example.
It says there that:
> Note that the indefinite integral in Maple is defined up to a piecewise
> constant
> Hence, the results returned by int may be discontinuous at some points.
> For symbolic definite integration, two options control how discontinuities
> are handled.
> By default, int checks for discontinuities, and computes the
Re: [sage-devel] Integral of log() and exp() failing the derivative check
On Sat, 21 Jan 2023 at 14:34, Georgi Guninski wrote: > > I got an integral, which fails the derivative check. > > For real positive x, define > f(x)=2^(x - 1/2*I*log(-e^(-2*I*pi*x))/pi - 1/2) > f(x) is just an obfuscation of 2^floor(x) and > for all positive x, f(x) is integer. > Let g(x) be the indefinite integral of f(x) > and let gder(x)=g'(x). > Assuming correct computations, we should have > > gder(x)=g'(x)=f(x) (*) > > According to sage, gder is the constant $1$ > and (*) fails. > > Some questions: > 1. What other CASes say about g(x)? In this case SymPy gives: In [34]: f = 2**(x-S(1)/2*I*log(-E**(-2*I*pi*x))/pi-S(1)/2) In [35]: print(f.integrate(x)) sqrt(2)*2**x*x/(2*2**(I*log(-exp(-2*I*pi*x))/(2*pi))) In [36]: print(f.integrate(x).diff(x)) sqrt(2)*2**x/(2*2**(I*log(-exp(-2*I*pi*x))/(2*pi))) In [37]: print(expand(f.integrate(x).diff(x) - f)) 0 In [38]: print(f.diff(x)) 0 In [39]: print(simplify(f.integrate(x)/f)) x > 2. Why the derivative test fails? Antiderivatives are not well defined for functions with jump discontinuities. A true antiderivative only exists for functions having the intermediate value property: https://en.wikipedia.org/wiki/Darboux%27s_theorem_(analysis) Since a true antiderivative does not exist the question is what can integrate do or what guarantees should be expected of the result that it returns? Generally symbolic antiderivatives of discontinuous functions should be understood as being only defined up to a piecewise constant function. Another way to think about this is that when you add a constant of integration like +C to your antiderivative it should be +C(x) where C(x) is a function whose derivative is zero almost everywhere but that might be discontinuous at the same places as the integrand. Algorithms for finding antiderivatives rely on differentiation which should also be understood as being well defined only where a function actually is differentiable. It is not possible for those algorithms to guarantee that what is returned is a symbolic expression for an antiderivative that always matches the integral of a function over *any* chosen interval [a,b] if the function is not continuous in all of [a,b]. > 3. Besides the jumps at integer, do branches of log() > give instability? > > Some comments suggest discontinuous functions > cause integral problems. There are built-in > discontinuous functions like tan() which are > widely used. > > 4. Why tan() integrals are used without problems (?) > when this fails the derivative check? In the case of `tan` you still need to understand any antiderivative as being limited to intervals of width pi. You could not for example use the expression of an antiderivative for tan to compute the integral of tan(x) between 0 and 2*pi. -- Oscar -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxT%3DmernUer71ZAabNUhc%3DFL5kWoMNi%3Dg-cK8ViH6gvOvg%40mail.gmail.com.
Re: [sage-devel] Doubts about correctness of `integrate(floor(x)^2,x)`
On Sat, 21 Jan 2023 at 06:43, Jonathan Thornburg wrote:
>
> On Fri, Jan 20, 2023 at 07:16:14PM +0200, Georgi Guninski wrote:
> > I have theoretical reasons to doubt the correctness
> > of integrals involving `floor`.
> >
> > The smallest testcases:
> >
> > sage: integrate(floor(x)^2,x)
> > // Giac share root-directory:/usr/share/giac/
> > // Giac share root-directory:/usr/share/giac/
> > Added 0 synonyms
> > x*floor(x)^2
> >
> > sage: integrate(2**floor(x),x)
> > 2^floor(x)*x
> >
> > Would someone check with another CAS or prove/disprove by hand?
>
> Maple reports the same result for your first testcase:
>
> tux% maple
> |\^/| Maple 2022 (X86 64 LINUX)
> ._|\| |/|_. Copyright (c) Maplesoft, a division of Waterloo Maple Inc. 2022
> \ MAPLE / All rights reserved. Maple is a trademark of
> < > Waterloo Maple Inc.
> | Type ? for help.
> > int(floor(x)^2, x);
> 2
> floor(x) x
>
> But, I think Maple and Sage/Giac are both wrong: consider the *definite*
> integral (latex notation) $I = \int_0^{3/2} \lfloor x \rfloor^2 \, dx$:
>
> Then the Sage/Giac indefinite integral implies that
> $I = \left. x \lfloor x \rfloor^2 \right|^{3/2}_0
>= (3/2) \lfloor (3/2) \rfloor^2 - 0 \lfloor 0 \rfloor^2
>= 3/2$
>
> But it seems to me that the correct result should be
> $I = \int_0^{3/2} \lfloor x \rfloor^2 \, dx$
>= \int_0^1 \lfloor x \rfloor^2 \, dx
> + \int_1^{3/2} \lfloor x \rfloor^2 \, dx
>= \int_0^1 0 \, dx + \int_1^{3/2} 1 \, dx
>= 0 + 1/2
>= 1/2$
The fundamental theorem of calculus requires that the integrand be
continuous over the interval of integration but in this case the
integrand is discontinuous at 1 so you cannot apply the theorem over
[0, 3/2]. The question is: what do you want to give as the indefinite
integral of a discontinuous function f given that its antiderivative
does not exist everywhere?
The expression F = floor(x)^2 * x is a valid antiderivative for f =
floor(x)^2 for all values of x such that f is continuous. At integer
values of x the function f is discontinuous and no (two-sided)
antiderivative exists.
It can still be possible to define a function F so that the integral
of f over [a, b] is equal to F(b) - F(a) but then is it worth doing
that rather than just returning a locally valid antiderivative that is
most likely a simpler expression. In this case a function F could be
something along the lines of (I haven't checked this carefully):
sum(n^2, (n, 1, floor(x)-1)) + floor(x)^2*(x - floor(x))
In context you should consider whether this is actually a better
expression or not though. Also keep in mind that it won't be possible
to do this for all discontinuous functions (e.g. 1/x). Any CAS that
promises to return indefinite integrals or antiderivatives of
potentially discontinuous functions will at least in some cases need
to return expressions that are only locally valid antiderivatives
rather than always returning a function F that can be used to compute
definite integrals blindly without checking continuity of the
integrand.
Given that you can't compute a suitable F in general, is it better to
try some of the time or just to state clearly in the documentation
what the limitations are and return the simplest locally valid
antiderivative expression?
--
Oscar
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/CAHVvXxRt4EZnV9TPUaqf4QvaDU9TGVO8TcaH-N9V%3DAMFx5GEOw%40mail.gmail.com.
Re: [sage-devel] Re: On changing Bernoulli(1) to +½
On Mon, 12 Sept 2022 at 22:09, Fredrik Johansson wrote: > > The claim "bernoulli_plus admits a natural generalisation to real and complex > numbers but bernoulli_minus does not" (made elsewhere in this thread) seems a > bit hyperbolic. For B+ this natural generalization is -n*zeta(1-n); for B- > one can just use -n*zeta(1-n)*cos(pi*n). OK, one is a bit simpler than the > other, but both are perfectly fine entire functions. I chose the word "natural" carefully because to me it conveys the fact that it is a subjective statement rather than a formal one. I assume it is formally possible to make infinitely many complex analytic functions to interpolate any function on the nonnegative integers (is that a named theorem?). The question is whether the factor of cos(pi*z) that you've included is something that is meaningful for noninteger values of z or something included only artifically. Did you have any reason to choose it besides fixing bernoulli(1)=-1/2 (which can also be done in infinitely many other ways)? Most mathematical functions will never gain the status of being a named function in any context so would defining a complex analytic bernoulli_minus(z) = -z*zeta(1-z)*cos(pi*z) have any particular value? Any formula involving bernoulli_plus would apply equally to bernoulli_minus but with some factors of cos(pi*z) lying around. Would any of the formulas have some other factor of cos(pi*z) for those to cancel with in order to produce something more "natural"? Would there be any value in SymPy, mpmath, Arb, Sage etc implementing such a bernoulli_minus? -- Oscar -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxSXzmOXcNnO3scCZOm7pZG36tGB9G-GEavqQi2hKRq-Xw%40mail.gmail.com.
Re: [sage-devel] On changing Bernoulli(1) to +½
On Mon, 12 Sept 2022 at 16:24, davida...@gmail.com
wrote:
>
> > Why don't we create a B+ and a B-?
>
> This was one of the idea of the ticket
> https://trac.sagemath.org/ticket/34521. A new option to the bernoulli
> function was added ("plus=False"), giving the option to the user to choose
> their prefered value. However, I think that the ticket was set to invalid and
> closed prematurely without any possibility for a meaningful discussion. I
> think that the debate here would be: what is the default value of this new
> option. There is two choices:
>
> "plus=False": bernoulli(1) = -1/2, nothing changes.
> "plus=True": bernoulli(1) = +1/2 (new value). Deprecation needs to be
> implemented.
If there is a need to provide both behaviours then I would suggest
using two new functions bernoulli_plus and bernoulli_minus rather than
a boolean flag. The bernoulli function can continue to return
bernoulli_minus but can refer to the other functions in its
documentation. That way the conventions are clearly distinguished and
in future it can be possible to make it so that bernoulli emits a
warning (prompting the caller to use bernoulli_plus or bernoulli_minus
explicitly instead) or perhaps is eventually changed to call
bernoulli_plus after some time of giving a warning.
The reason I didn't want to go that way for SymPy is that
bernoulli_plus admits a natural generalisation to real and complex
numbers but bernoulli_minus does not. It would be awkward to implement
both bernoulli_plus and bernoulli_minus as symbolic functions where
the rules and domains, numerical evaluation etc would all be
different: one would be a complex analytic function while the other an
integer sequence.
> In any case, I think that something should be done about this, because FLINT
> has been changed to return +1/2 (and FLINT is the default for small Bernoulli
> numbers)
Has FLINT been changed? I see a PR here but it is still open:
https://github.com/wbhart/flint2/pull/1179
--
Oscar
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/CAHVvXxRYSfX9-Mg_v%3Dt8Rr3z96F%3Dhf%3DmUxJp0bgG1Qi5U1pSFQ%40mail.gmail.com.
Re: [sage-devel] On changing Bernoulli(1) to +½
On Sat, 10 Sept 2022 at 18:49, William Stein wrote: > > On Sat, Sep 10, 2022 at 10:04 AM davida...@gmail.com > wrote: > > > > > I'm curious if the change breaks any code anywhere else in Sage (e.g., > > > maybe for computing q-expansions of modular forms?)... > > > > You guessed right. I did a quick local change to the bernoulli function and > > it indeed breaks some tests in sage/modular/modform: > > I created all of the files listed below. My guess is that code for > computing q-expansions of Eisenstein series assume B(1) is what it is, > and one would just need to change that code by changing a sign > somewhere. The two different versions of the Bernoulli sequence are related very simply (B-(n) = (-1)^n B+(n)) so it should be easy to update any code that depends on the current behaviour. This is why SymPy isn't providing any direct replacement for its previous B- behaviour. Oscar -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxQY1qoMcn4KP06KG6ktaHcjmM%3DWfrW%2B-ZVHZnh0HXOKWQ%40mail.gmail.com.
