Revert cif fast inversion 84ab655

[videlec]

The tight reversion of complex intervals introduced in 84ab655 from #19964 made complex intervals wrong... and hence unreliable. This remained unnoticed until an apparently unrelated bug involving QQbar #37927. As an emergency measure we simply revert the tight reversion.

Fixes #37927

📝 Checklist

• The title is concise and informative.
• The description explains in detail what this PR is about.
• I have linked a relevant issue or discussion.
• I have created tests covering the changes.
• I have updated the documentation and checked the documentation preview.

[mezzarobba]

OK, though of course it would be better to debug the inversion routine if somebody has time for that.

[mezzarobba]

Sorry for the multiple label changes. I agree with the revert, but the tests currently fail, tough I don't think this is due to the changes made here.

Also, you might want to add a test based on #37927 (comment).

[fchapoton]

For a tentative to repair the currently very broken CI , see #37926

[videlec]

Sorry for the multiple label changes. I agree with the revert, but the tests currently fail, tough I don't think this is due to the changes made here.

Also, you might want to add a test based on #37927 (comment).

Isn't that enough?

commit 7a00b56dca6a148cc577aab9b3ffd647d4204c15
Author: Vincent Delecroix <[email protected]>
Date:   Mon May 6 00:05:36 2024 +0200

    add doctests

diff --git a/src/sage/rings/complex_interval.pyx b/src/sage/rings/complex_interval.pyx
index eb8c4f00da..8276d1e31e 100644
--- a/src/sage/rings/complex_interval.pyx
+++ b/src/sage/rings/complex_interval.pyx
@@ -1149,6 +1149,11 @@ cdef class ComplexIntervalFieldElement(FieldElement):
             sage: 1 / CIF(RIF(-1,1),0)
             [.. NaN ..] + [.. NaN ..]*I
 
+        Test that the bug reported in :issue:`37927` is fixed::
+
+            sage: (961 * (1 / CIF(0, 31))**2 + 1).contains_zero()
+            True
+
         REFERENCES:
 
         - [RL1971]_
diff --git a/src/sage/rings/qqbar.py b/src/sage/rings/qqbar.py
index 4e4454988c..773853ec67 100644
--- a/src/sage/rings/qqbar.py
+++ b/src/sage/rings/qqbar.py
@@ -552,6 +552,28 @@ Check that :issue:`28530` is fixed::
      (0.999999587? + 0.?e-11*I, 1),
      (0.999999999? + 0.?e-11*I, 1)]
 
+Check that issue:`37927` is fixed::
+
+    sage: y = polygen(QQ, 'y')
+    sage: v1 = QQbar.polynomial_root(y**2 + 1, CIF(0, -1))
+    sage: v2 = -QQbar(2).sqrt()
+    sage: M = matrix(QQbar, [[0, 0, 1, 0, 0, 0, 0, 0, 0, 0],
+    ....:              [0, 1, 0, 0, 0, 0, 0, 0, 0, 0],
+    ....:              [-4, 2*v1, 1, 64, -32*v1, -16, 8*v1, 4, -2*v1, -1],
+    ....:              [4*v1, 1, 0, -192*v1, -80, 32*v1, 12, -4*v1, -1, 0],
+    ....:               [2, 0, 0, -480, 160*v1, 48, -12*v1, -2, 0, 0],
+    ....:               [-4, 2*I, 1, 64, -32*I, -16, 8*I, 4, -2*I, -1],
+    ....:               [4*I, 1, 0, -192*I, -80, 32*I, 12, -4*I, -1, 0],
+    ....:               [2, 0, 0, -480, 160*I, 48, -12*I, -2, 0, 0],
+    ....:               [0, 0, 0, 8, 4*v2, 4, 2*v2, 2, v2, 1],
+    ....:               [0, 0, 0, 24*v2, 20, 8*v2, 6, 2*v2, 1, 0],
+    ....:               [0, 0, 0, 8, 4*v2, 4, 2*v2, 2, -v2, 1],
+    ....:               [0, 0, 0, 24*v2, 20, 8*v2, 6, 2*v2, 1, 0],
+    ....:               [0, 0, 0, -4096, -1024*I, 256, 64*I, -16, -4*I, 1],
+    ....:               [0, 0, 0, -4096, 1024*I, 256, -64*I, -16, 4*I, 1]])
+    sage: M.right_kernel_matrix()
+    [   1.000000000000000? + 0.?e-16*I                                 0                                 0 -0.00925925925925926? + 0.?e-19*I               0.?e-35 + 0.?e-18*I -0.11111111111111111? + 0.?e-18*I               0.?e-34 + 0.?e-17*I   0.5555555555555555? + 0.?e-16*I                                 0  -0.5925925925925926? + 0.?e-17*I]
+
 AUTHOR:
 
 - Carl Witty (2007-01-27): initial version

[miguelmarco]

As I mentioned in #37927, I think there is another underlying problem with mpfr not being able to find the difference between two different numbers:

sage: c = CIF(0,31)
sage: ci = 1/c
sage: ci.real().endpoints()
(0.000000000000000, -0.000000000000000)
sage: ci.imag().endpoints()
(-0.0322580645161291, -0.0322580645161290)
sage: ci.diameter()
0.000000000000000
sage: ci.imag().endpoints()[1]-ci.imag().endpoints()[0]
0.000000000000000

My guess is that in that particular case, the difference is in the last bit, but one of the numbers uses a higher exponent (both examples I have seen involve the inverses of powers of 2 or powers of two minus one, which are where you would expect to find this kind corner cases), so the precision of the result is set to the bigger exponent, and that last bit of difference is lost.

This problem is exposed in this case because the result of the inversion method is too tight, but I think it would be worth detecting this kind of problems and fixing them, because there are important performance advantages in using tight results.

[videlec]

As I mentioned in #37927, I think there is another underlying problem with mpfr not being able to find the difference between two different numbers:

sage: c = CIF(0,31)
sage: ci = 1/c
sage: ci.real().endpoints()
(0.000000000000000, -0.000000000000000)
sage: ci.imag().endpoints()
(-0.0322580645161291, -0.0322580645161290)
sage: ci.diameter()
0.000000000000000
sage: ci.imag().endpoints()[1]-ci.imag().endpoints()[0]
0.000000000000000

My guess is that in that particular case, the difference is in the last bit, but one of the numbers uses a higher exponent (both examples I have seen involve the inverses of powers of 2 or powers of two minus one, which are where you would expect to find this kind corner cases), so the precision of the result is set to the bigger exponent, and that last bit of difference is lost.

This problem is exposed in this case because the result of the inversion method is too tight, but I think it would be worth detecting this kind of problems and fixing them, because there are important performance advantages in using tight results.

Contrarily to the (sign, mantissa, exponent) triple, the decimal representation does not tell you the actual value.

sage: x_down = RealField(53, rnd='RNDD')(4648877034705029 * 2**-57)
sage: x_down
0.0322580645161290
sage: x_up = RealField(53, rnd='RNDU')(4648877034705029 * 2**-57)
sage: x_up
0.0322580645161291
sage: x_down == x_up  # these are actually equal!
True
sage: x_down.sign_mantissa_exponent()
(1, 4648877034705029, -57)
sage: x_up.sign_mantissa_exponent()
(1, 4648877034705029, -57)

The two floating points above are the one appearing in our example

sage: c = CIF(0,31)
sage: ci = 1/c
sage: [x.sign_mantissa_exponent() for x in ci.imag().endpoints()]
[(-1, 4648877034705029, -57), (-1, 4648877034705029, -57)]

[github-actions]

Documentation preview for this PR (built with commit c687feb; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

[videlec]

@mezzarobba some doctest failures were due to the reversion. They are fixed in c687feb.

[mkoeppe]

Reducing to "critical" because "blocker" still doubles as "CI Fix" until this is merged:

• CI: Handle the "p: CI Fix" label #37950

[videlec]

Reducing to "critical" because "blocker" still doubles as "CI Fix" until this is merged:

* [CI: Handle the "p: CI Fix" label #37950](https://github.com/sagemath/sage/pull/37950)

Thanks for taking care of this. I would really appreciate this PR to be part of the next beta as it does fix a critical bug!

[mezzarobba]

Isn't that enough?

Sure, I somehow missed the first of the two tests, sorry!