On Mon, Jun 14, 2010 at 7:09 PM, Dr. David Kirkby <david.kir...@onetel.net> wrote: > On 06/14/10 11:41 AM, Tim Joseph Dumol wrote: >> >> Doctests are used to prevent regressions and (unwanted) backward >> incompatibilities. Since the code used in these modules are not ever >> going to be modified, it does not seem necessary to provide doctests, >> IMHO. > > Personally I'd beg to differ. A change in gcc's behavior could easily result > in the code acting differently, as could any number of other system changes. > > Here are a few tickets for issues that result of just changing compiler > versions. > > * segfault in Sage-4.4 built using GCC-4.5.0 > http://trac.sagemath.org/sage_trac/ticket/8788 > > * frobby optional spkg doesn't build with newer GCC's > http://trac.sagemath.org/sage_trac/ticket/8783 > > * GCC-4.5.0 breaks GAP -- the workspace is broken, hence gap('2+2') fails. > http://trac.sagemath.org/sage_trac/ticket/8773 > > * http://trac.sagemath.org/sage_trac/ticket/8767 > http://trac.sagemath.org/sage_trac/ticket/8767 > > As far as I can see, all those bugs were a result of changing just compiler > versions. > > Add to the mix the possibility of different versions of cython behaving > differently, and it seems a bad idea to me. > > It's certainly not unknown for a doc test to fail on one machine but pass on > another. So having the same code never guarantees you get the same result. > > Over the years, I've come across a lot of code which runs ok on fast > computers, but not on slow ones, or visa versa. One case I recall was > someone being rather stupid and seeing the random number generator from the > time of day multiple times in a loop. On a slow computer, the seed was > effectively random each time so they got a different pseudo random number. > On a fast computer, the code executed in less than a second, and so the RNG > was seeded twice with hte same value. > > Mathematica on Solaris had a bug when Solaris 10 was updated only on slow > computers. > > http://www.g8wrb.org/mathematica/ > > So I've known all these to cause bugs, while the source code remains > unchanged. > > * Changes in compiler version > * Changes in the speed of the computer > * Upgrade of the operating system. > > As one more final point, there are ports in progress to > > * FreeBSD > * OpenSolaris > * 64-bit on Solaris SPARC > > All of them have the potential to create problems on one platform, not seen > on another. > > Can you dismiss all the above possibilities? If not, why should the code be > exempt from testing? > > Dave >
As for Cython and gcc, the Sage notebook uses pure Python. I do acknowledge that there's a minuscule chance that a Python update could change runtime behaviour. It is worthwhile to note that the code under sage/server/* is only used to be able to load old pickles of Sage notebooks, and the only reasonable way I could think a Python update could mess this up is by a change in pickle format (which is guaranteed against in Python documentation). The code is not used for any other purpose aside from that. On Mon, Jun 14, 2010 at 6:34 PM, Dr. David Kirkby >> <david.kir...@onetel.net> wrote: >>> >>> On 06/14/10 05:15 AM, Minh Nguyen wrote: >>>> >>>> Hi folks, >>>> >>>> In a recent thread [1] on sage-notebook, it was suggested that files >>>> under the component >>>> >>>> sage/server >>>> >>>> need not contribute to the total doctest coverage. >>> >>> That seems a slightly strange decision to me. From the link it is >>> apparent >>> the code is still in use. To quote from there: >>> >>> "sage/server/notebook/worksheet.py cannot be removed since the sources >>> under server/notebook/* are still used by SageNB for conversion from >>> the old pickled data storage format to the new one." >>> >>> So why should it not be tested? >>> >>>> Taking a cue from >>>> that, today's coverage update [2] contains good news. >>> >>> This strikes me as rather fiddling things to make the statistics look >>> better. >>> >>>> I have blacklisted everything under sage/server in generating the new >>>> doctest reports at [2]. This now means that as of Sage 4.4.4.alpha0, >>>> the overall weighted coverage score is 84.6%. Previously, the number >>>> of strategic modules was 180, i.e. we needed to get 180 modules up to >>>> full coverage in order to meet the 90% coverage goal. Now, the number >>>> of strategic modules is down to 140. >>> >>> This reminds me of the saying: >>> >>> "There are lies, damn lies, and statistics". >>> >>>> [1] >>>> >>>> http://groups.google.com/group/sage-notebook/browse_thread/thread/a07e542145ec1c99 >>>> >>>> [2] http://sage.math.washington.edu/home/mvngu/doctest-coverage/ >>> >>> >>> Dave >>> >>> -- >>> To post to this group, send an email to sage-devel@googlegroups.com >>> To unsubscribe from this group, send an email to >>> sage-devel+unsubscr...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/sage-devel >>> URL: http://www.sagemath.org >>> >> >> >> > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- Tim Joseph Dumol <tim (at) timdumol (dot) com> http://timdumol.com -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
