-
-
Notifications
You must be signed in to change notification settings - Fork 482
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
tight complex interval inverse #19964
Comments
Commit: |
Author: Miguel Marco |
Changed keywords from none to interval, root |
This comment has been minimized.
This comment has been minimized.
comment:5
Can you give an example which clearly illustrates the better bounds? Also, have you run timings versus the schoolbook version? (I don't have the technical abilities to review this ticket though.) |
This comment has been minimized.
This comment has been minimized.
comment:6
Added some examples to the description. |
comment:7
Is this better in all cases? - 0.?e-182 - 0.7598602580415435?*I,
- 0.?e-249 + 0.7598602580415435?*I,
+ 0.?e-215 - 0.7598602580415435?*I,
+ 0.?e-229 + 0.7598602580415435?*I, |
comment:8
It should be, up to floating point artifacts. I don't know much about the subtleties of floating point numbers though. |
comment:9
I was wondering about the |
comment:10
Yes, that is what i imagined, but i would guess that in those two cases the discrepancy is due to those pesky numerical artifacts that can appear just by, for example, performing the same operations in different order. |
comment:12
IMHO the tests should cover all branches of the new implementation (ideally with test cases where the rounding modes matter, if that's not too hard to achieve). |
comment:13
Following comment:12 I added a doctest. And I also removed the trailing whitespaces in a second commit. This is good for me to go. Any remarks? New commits:
|
Reviewer: Vincent Delecroix |
Changed branch from u/mmarco/tight_complex_interval_inverse to u/vdelecroix/19964 |
comment:15
lgtm except that I'd suggest the following change in order to really test all possible cases:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:17
You really don't want to test the cases where the interval contains zero |
Changed reviewer from Vincent Delecroix to Vincent Delecroix, Marc Mezzarobba |
Changed branch from u/vdelecroix/19964 to |
Changed commit from |
comment:19
Breakage: #22834 |
The tight reversion of complex intervals introduced in 84ab655 from sagemath#19964 made complex intervals wrong... and hence unreliable. This remained unnoticed until an apparently unrelated bug involving QQbar sagemath#37927. As an emergency measure we simply revert the tight reversion. Fixes sagemath#37927 ### 📝 Checklist <!-- Put an `x` in all the boxes that apply. --> - [x] The title is concise and informative. - [x] The description explains in detail what this PR is about. - [x] I have linked a relevant issue or discussion. - [x] I have created tests covering the changes. - [x] I have updated the documentation and checked the documentation preview. URL: sagemath#37941 Reported by: Vincent Delecroix Reviewer(s): Marc Mezzarobba
…_ - thus for complex interval division. The implementation is inspired by Rokne-Lancaster 1971. Some history: - The first implementation of returning tight intervals was commit 84ba655 (see ticket sagemath#19964). - That implementation had bugs (returning too small intervals) and was reverted to fix ticket sagemath#37941. - This change is the second implementation.
…_ - thus for complex interval division. The implementation is inspired by Rokne-Lancaster 1971. Some history: - The first implementation of returning tight intervals was commit 84ba655 (see ticket sagemath#19964). - That implementation had bugs (returning too small intervals) and was reverted to fix ticket sagemath#37941. - This change is the second implementation.
…_ - thus for complex interval division. The implementation is inspired by Rokne-Lancaster 1971. Some history: - The first implementation of returning tight intervals was commit 84ba655 (see ticket sagemath#19964). - That implementation had bugs (returning too small intervals) and was reverted to fix ticket sagemath#37941. - This change is the second implementation.
This provides a (hopefully) correct implementation of computing a tight enclosure for the inverse of a complex interval. It fixes sagemath#37963. There is some history to this: Commit 84ab655 from sagemath#19964 introduced a tight enclosure but had some bugs such as ticket sagemath#37927. Thus, the that commit (and the subsequent partial fixes) were reverted in commit 8d59b12, see pull request sagemath#37941. This is a new implementation of Rokne-Lancaster that I wrote from scratch. ### 📝 Checklist - [x] The title is concise and informative. - [x] The description explains in detail what this PR is about. - [x] I have linked a relevant issue or discussion. - [x] I have created tests covering the changes. - [x] I have updated the documentation and checked the documentation preview. ### ⌛ Dependencies sagemath#37941 URL: sagemath#38360 Reported by: Matthias Goerner Reviewer(s): Marc Culler, Nathan Dunfield
The current method to compute the multiplicative inverse of a complex interval uses schoolbok formula that produces intervals much bigger than the actual result.
This ticket implements a method that produces a tight interval enclosure of the result.
As a result, we get better precission in root isolating methods (and hence, less steps needed).
Here are some examples that illustrate the impact of the changes:
Old behaviour:
new behaviour:
Another example with a smaller interval,
old:
new:
As you can see, the diameter of the result can easily get cut to half or even smaller.
The timings of the inversion can vary, but they remain in the same order of magnitude as before. It has a noticeable effect in root isolation:
old:
new:
CC: @tscrim @videlec @dkrenn @jdemeyer @sagetrac-tmonteil @cheuberg
Component: numerical
Keywords: interval, root
Author: Miguel Marco
Branch:
39558b6
Reviewer: Vincent Delecroix, Marc Mezzarobba
Issue created by migration from https://trac.sagemath.org/ticket/19964
The text was updated successfully, but these errors were encountered: