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
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
