On Fri, Aug 27, 2010 at 12:37 PM, Dr. David Kirkby <david.kir...@onetel.net> wrote: > On 08/27/10 07:24 PM, mhampton wrote: >> >> For the record, I tried the above calculation at least 250,000 times >> on two macs (running OSX 10.5 and 10.6) and on Ubuntu 9.10 with a i7 >> 860 processor, had no errors. This was on Sage-4.5.2. I guess I'll >> try again with 4.5.3, maybe its related to the Pari upgrade. >> >> Otherwise +1 to Alex's comments. >> >> Marshall >> > Pari has not been upgraded in 4.5.3 - it will be 4.6.0 before that's > updated. > > There have been many reports of where doctests fail when running > > make ptest > or > make ptestlong > > which later pass if run individually. I've lost count of the number of times > I've seen that reported, on every operating system under the Sun.
I'm willing to bet this is a problem with the doctesting system, not Sage itself. (Actually, there's at least one known bug that I've personally run into when running at high levels of parallelization: http://trac.sagemath.org/sage_trac/ticket/9739 ) > I'll post a list of the failure once I've run them 100 times. > > I've got a feelign the frequency of failures might be related to system > load, though that's hard to prove. There have been long periods where all > tests passed every time, and I believe those were when I was not using the > machine for much else. The failures occcured on runs numbered 4, 11, 17, 21, > 22, 23, 26, 34, 60, 66. > > So 25 times in succession all tests pass, but then there are periods where > there are a number of failures. > > Anyway, I'll just leave it running, and see what happens. > I ran the eigenvalues test 100,000 times on my Mac (Sage 4.5.2) and never had it fail once. It looks like linbox is called to create the charpoly, and IIRC linbox occasionally uses probabilistic methods by default (with tiny but non-zero chance of failure). I wouldn't rule out cosmic rays or other hardware failure--is your ram ECC? With 12GB, you're likely to see a bit flipped per day. Also, you're using a (relatively) uncommon operating system and set of hardware. This can be good for exposing bugs, but that's not a good thing when you're trying to use the software. I have more confidence in software working correctly on the system(s) used by its developers than a port. In terms of the general rant, there are two points I'd like to make. The first is that there's a distinction between the Sage library itself and the many other spkgs we ship. By far the majority of your complaints have been about various arcane spgks. Sage is a distribution, and we do try to keep quality up, but it's important to note that much of this software is not as directly under our control, and just because something isn't as good as it could be from a software engineering perspective doesn't mean that it won't be extremely useful to many people. Even if it has bugs. We try to place the bar high for getting an spkg in but blaming the Sage community for poor coding practices in external code is a bit unfair. I hold the Sage library itself to a much higher standard. The second point is that much of the older, crufty code in Sage was put in at a time when standards were much lower, or even before there was a referee process at all. I think this was necessary for the time--Sage would have gotten off the ground if it couldn't have been useful so quickly. This includes in particular many of the spkgs that have been grandfathered in and wouldn't make the cut now, but it takes time to remove/replace/clean them up. Of course there's room for improvement, but do you think the current review process is insufficient and lots of new bad code is being written and included? If so, what should we do better? - Robert -- 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
