-
-
Notifications
You must be signed in to change notification settings - Fork 480
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use the faster libgiac interface for "giac" integration #38686
base: develop
Are you sure you want to change the base?
Conversation
f12c887
to
093c840
Compare
Documentation preview for this PR (built with commit 8db21a2; changes) is ready! 🎉 |
AFAICS the CI failure is an unrelated timeout:
|
This looks like a good idea, thanks. |
I didn't see the label change, thanks for the review. |
I'm getting
|
…egration The library interface to libgiac is much more efficient than the pexpect one, but the name algorithm="giac" is more attractive (especially to newcomers) than algorithm="libgiac". We should just Do The Right Thing and use libgiac when "giac" is requested.
The pexpect integrator is unused now that the "giac" integrator uses libgiac. We also add a few "# needs sage.libs.giac" tags to the tests that use the libgiac integrator, because they obviously will fail when libgiac is not there.
One example in this file integrates with algorithm='giac', which can fail if sage.libs.giac is not available to perform the integration.
One example in this file integrates with algorithm='giac', which can fail if sage.libs.giac is not available to perform the integration.
…tegration A few examples in this file integrate with algorithm='giac', which can fail if sage.libs.giac is not available to perform the integration.
There's one test in this file for an integral where the "libgiac" algorithm prints a warning, but the old "giac" algorithm did not. Now that algorithm="giac" uses libgiac, we expect the warning in that case too.
One "giac" integral in this file has changed its output slightly now that the "giac" algorithm uses libgiac as opposed to the pexpect interface. The difference between the new and old expected outputs full_simplify() to zero, so this one is nothing to worry about.
When integrating to/from plus/minus infinity, Giac can get stuck: sage: integral(1/max_symbolic(x, 1)**2, x, 0, oo, algorithm='giac') ... RuntimeError: Unable to check sign: 1>Infinity This is apparently due to the type of infinity that is used for integration. There are (at least?) two kinds: sage: from sage.libs.giac import libgiac sage: libgiac(Infinity) Infinity sage: libgiac(Infinity._giac_()) +infinity And, for integration, I guess we want the second kind, because it allows the integration to proceed with a warning. This commit calls _giac_() on the endpoints of a definite integral before passing them to libgiac.integrate(). It fixes the example above, and we update the corresponding doctest.
With the recent change to the handling of infinity in the libgiac integrator, a warning about singular points has vanished.
093c840
to
8db21a2
Compare
These are the same anwer. I updated the expected output.
Nothing too scary here. This doctest already looks for the warning output on the previous line, where
This one on the other hand is a treat. It's reproducible using In any case, I was able to work around it. Don't ask me what the difference is, but giac likes |
Part of sagemath#38668. If it's going to be possible to disable giac, we need to guard all of the tests that use it with either `# needs giac` or `# needs sage.libs.giac`. I think I've gotten them all. A crude way to test: 1. `git rm -r src/sage/libs/giac` and rebuild to disable sage.libs.giac 2. build sage, and then delete the giac executable to disable the pexpect interface If you do these one at a time, it should ensure that the correct tags are used. (Typically, if giac is missing, neither sage.libs.giac nor the giac executable will be present, making it very easy to mix up the tags.) For bonus points you can undelete `src/sage/libs/giac` after building but before testing to make sure the "needs" tags in those files are accurate. ### Dependencies: * sagemath#38756 * sagemath#38686 (not strictly required, but it adds a few "needs sage.libs.giac" tags of its own) URL: sagemath#38770 Reported by: Michael Orlitzky Reviewer(s): Tobias Diez
Part of sagemath#38668. If it's going to be possible to disable giac, we need to guard all of the tests that use it with either `# needs giac` or `# needs sage.libs.giac`. I think I've gotten them all. A crude way to test: 1. `git rm -r src/sage/libs/giac` and rebuild to disable sage.libs.giac 2. build sage, and then delete the giac executable to disable the pexpect interface If you do these one at a time, it should ensure that the correct tags are used. (Typically, if giac is missing, neither sage.libs.giac nor the giac executable will be present, making it very easy to mix up the tags.) For bonus points you can undelete `src/sage/libs/giac` after building but before testing to make sure the "needs" tags in those files are accurate. ### Dependencies: * sagemath#38756 * sagemath#38686 (not strictly required, but it adds a few "needs sage.libs.giac" tags of its own) URL: sagemath#38770 Reported by: Michael Orlitzky Reviewer(s): Tobias Diez
Add `# needs sage.libs.giac`, from sagemath/sage#38686 by @orlitzky, cherry picked
While working on #38668, I noticed that all of our examples that use giac for integration do so with
algorithm='giac'
. This uses the pexpect interface that is much slower (and simply sloppier) than the library interface that would be used withalgorithm='libgiac'
.To fix this, I could just change those examples to
algorithm='libgiac'
, but since the libgiac interface is better in every way, that seems kind of rude to me. Most users aren't going to know what lib-anything is, and if they just want to use giac, they're going to tryalgorithm='giac'
. So instead this PR makesalgorithm='giac'
do the right thing, and use the better interface. I've left thealgorithm='libgiac'
alone for now to avoid breaking any code.Afterwards I have removed the pexpect giac integrator entirely, because there's no reason to use it, and no other code in sagelib uses it.