[TODO] Updated item on tzeta:

  * removed the old problem: the fact that the traces for the trunk and
    for r9954 are different is normal (fixes in mpfr_can_round affecting
    tgeneric.c), and the timings depend on GMP_CHECK_RANDOMIZE and seem
    equivalent in average with "test_generic (..., 5);" in both cases;
  * added the fact that tzeta has been much slower since r9848, at least
    with the x86 32-bit ABI.

git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@10789 280ebfd0-de03-0410-8827-d642c229c3f4

1 files changed, 2 insertions, 11 deletions

diff --git a/TODO b/TODO
index 575cfc98a..9cbcef031 100644
--- a/TODO
+++ b/TODO
@@ -608,17 +608,8 @@ Table of contents:
   (The one done in r10573 allowed us to find a bug even without
   assertion checking.)
 
-- after the fix of mpfr_can_round in r9883, tzeta has a different trace
-  from r9882, which may be expected as mpfr_can_round has an influence
-  in tgeneric.c, but a closer look is needed: check only the first
-  difference (with various GMP_CHECK_RANDOMIZE values), since after it,
-  the random numbers do not match.
-  With the 32-bit ABI, tzeta r9955 is even 2.17 times as slow as r9954;
-  the corresponding change:
-    -  test_generic (2, 70, 5);
-    +  test_generic (MPFR_PREC_MIN, 70, 5);
-  Find the real cause, whether a wrong result could be obtained before
-  the fix r9883, and whether the slowdown can be avoided.
+- tzeta has been much slower due to r9848, at least with the x86 32-bit ABI;
+  see whether this was expected.
 
 
 ##############################################################################