Opened 10 years ago
Last modified 9 years ago
#10195 closed defect
Occasional doctest failure in libs/fplll/fplll.pyx — at Version 7
Reported by: | mpatel | Owned by: | mvngu |
---|---|---|---|
Priority: | major | Milestone: | sage-duplicate/invalid/wontfix |
Component: | doctest coverage | Keywords: | |
Cc: | drkirkby, malb, jdemeyer | Merged in: | |
Authors: | Reviewers: | ||
Report Upstream: | Fixed upstream, in a later stable release. | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description (last modified by )
Reported on sage-devel:
I ran ./sage -t -long -force_lib "devel/sage/sage/libs/fplll/fplll.pyx" 1000 times in serial [1] with a 64-bit 4.6.rc0 built on OS X 10.6 (bsd.math). All but one of the runs pass. The failure: Run 766 of 1000 Detected SAGE64 flag Building Sage on OS X in 64-bit mode sage -t -long -force_lib "devel/sage/sage/libs/fplll/fplll.pyx" ********************************************************************** File "/Users/buildbot/build/sage/bsd-2/bsd_64_full/build/sage-4.6.0pre0/devel/sa ge/sage/libs/fplll/fplll.pyx", line 853: sage: L.echelon_form() == A.echelon_form() Expected: True Got: False
The error also occurs with a 32-bit build on bsd.math (OS X 10.6, 5 out of 1000 runs) and on sage.math (64-bit Ubuntu 8.04.4 LTS, 6 of 1000 runs).
David Kirkby does not get any incorrect results on OpenSolaris 06/2009 after more than 15000 runs with 4.6.rc0 and more than 16000 with 4.6.1.alpha0. He had a total of 31748 passes. However, he did experience 109 doctest failures which are likely to be result of doctesting two copies of Sage simultaneously, as these were using the same directory for temporary files ($HOME/.sage/tmp
). His errors were like this:
Run 442 of 100000 sage -t -long -force_lib "devel/sage/sage/libs/fplll/fplll.pyx" python: can't open file '/export/home/drkirkby/.sage//tmp/fplll.py': [Errno 2] No such file or directory [0.2 s]
and never due to False being return instead of True. His problems are probably the result of the issues discussed on #9739.
Change History (7)
comment:1 Changed 10 years ago by
- Type changed from PLEASE CHANGE to defect
comment:2 Changed 10 years ago by
- Description modified (diff)
comment:3 Changed 10 years ago by
- Description modified (diff)
comment:4 Changed 10 years ago by
- Description modified (diff)
comment:5 follow-up: ↓ 6 Changed 10 years ago by
I reckon you Linux and OS X users should upgrade to Solaris!
Dave
comment:6 in reply to: ↑ 5 ; follow-up: ↓ 7 Changed 10 years ago by
Replying to drkirkby:
I reckon you Linux and OS X users should upgrade to Solaris!
Dave
What if those failures are intended by the fplll authors, but just do not work on your machine / operating system? Or just those "file not found" instances would have been the ones failing... Nobody knows. ;-)
(At least regarding memory and CPUs, I trust most of my machines; they didn't show any bit errors I certainly would have noticed for at least month of continuous computations whose results I could verify...)
Btw, one could also try something like
$ export SAGE_TEST_GLOBAL_ITER=1000 $ ./sage -tp 1 -long devel/sage/sage/libs/fplll/fplll.pyx 2>&1 | tee fplll-test.log $ echo "`grep -c All fplll-test.log` out of 1000 runs did NOT fail." $ echo "`grep -c Got fplll-test.log` tests out of 1000 gave an unexpected result."
comment:7 in reply to: ↑ 6 Changed 10 years ago by
- Description modified (diff)
Replying to leif:
Replying to drkirkby:
I reckon you Linux and OS X users should upgrade to Solaris!
Dave
What if those failures are intended by the fplll authors, but just do not work on your machine / operating system? Or just those "file not found" instances would have been the ones failing... Nobody knows. ;-)
I was rather expecting you to have something to say on this;-)
FWIW, I'm now doctesting again, but this time only testing one instance of Sage. So errors due to using the one directory for temp files should not exist. I've only managed to run the tests 3723 times, but none of them have failed in any way whatsoever.
I personally think my initial failures were due to #9739.
I think the matrix used for this test might be random, which could explain failures which occur when (for example) all elements are zero. However, that would probably not explain why I don't get any failures.
Leif Leonhardy's results: