On 10/29/10 10:10 PM, Robert Bradshaw wrote:
On Tue, Oct 26, 2010 at 12:57 AM, Dr. David Kirkby

'cksum' is a 32-bit checksum. Actually, if used all three sections of the
output

1) Checksum
2) Length
3) Filename

I feel that should be sufficiently relieable. The probability of a test
having the exact same path, checksum and length, while having changed, would
be exceeding close to zero.
True, though I bet I could (maliciously) come up with two docstrings
that have the same checksum given how weak the algorithm is. I don't
see any advantage to using a weak checksum given that we have Python
and aren't doing this on a per-file basis (or, I hope, extracting
doctests with an external shell script).

What's possible with malicious input is not really of a concern for a non-security application. The man page says deliberate deception would be difficult, though not impossible.

I agree using a stronger algorithm is fine if Python was used to do all this. It just struck me that was was being contemplated was very complex. I was tempted to just hack together a 20 line shell script which parsed ptestlong.log, though one really wants CPU times, not wall times for this to be of any use whatsoever unless the machine was in an idle state.

Also, I was talking to Craig Citro about this and he had the
interesting idea of creating some kind of a "test object" which would
be saved and then could be run into future versions of Sage and re-run
in. The idea of saving the tests that are run, and then running the
exact same tests (rather than worrying about correlation  of files and
tests) will make catching regressions much easier.

- Robert

Yes, that makes a lot of sense, though unless there a lot of tests, it would
be easy to miss problems.

Fortunately, there are a lot of tests :).

- Robert

But if a new set of tests is written for the benchmark, there would not be all the current doctests to use, so the number might drop. At least that is what I thought was talked of. The thread has got a bit long, and I've not been folowing it closely.

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

Reply via email to