On 18 Oct, 21:33, Robert Bradshaw <rober...@math.washington.edu> wrote: > On Sun, Oct 17, 2010 at 6:39 AM, Dr. David Kirkby
> On Sun, Oct 17, 2010 at 6:39 AM, Dr. David Kirkby > > sage: seed(1,2) > > sage: seed(100,34) > > sage: seed(1,2,3,4,5,6,7) > > > will all crash Sage with an "Unhandled SIGSEGV". Plenty more sets of invalid > > input to other commands will hang Sage, so the only answer is to kill the > > process. > > Though in an ideal world, this kind of thing wouldn't crash Sage, I'm > more worried about the kinds of bugs where valid input causes a > segfault, or, much worse, an incorrect answer. Obviously getting incorrect results is the worst possible case bug - especially if the results look believable. If you try to factorise an integer and get a Bessel function as an answer, it is obviously wrong. Some results look reasonable and so are very bad news. I'd also agree getting crashes with valid input is bad, but its a fact of life people do enter invalid input. Sometimes how one uses a function is not very obvious, so using invalid input is going to happen. If that crashes Sage, and stops lots of people working on a Sage server, I think that's pretty serious, though not as bad as incorrect results. > > I think the main problem is ignorance. Good software engineering techniques > > do not form part of mathematics degrees, so most Sage developers are totally > > ignorant of the issues. Then those motivated to find more information soon > > hit the fact that books on this topic are not cheap. I have an 18-year old > > copy of this book, which despite the complaints the 7th edition is out of > > date, I think much of the material would be useful to Sage developers. > > >http://www.amazon.com/Software-Engineering-Practitioners-Approach-Int... > > > There's also plenty of books on software testing. > > >http://www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Dstripbooks&;... > > > Perhaps when William assembles the team in Seattle, he could find the money > > to buy each person a book on software testing. Buy each person a different > > book, then hopefully Sage developers will able to independently review the > > material. Perhaps they each write a Wiki page on what they though was the > > most important things they learned from the book. > > I would submit that practicing good software engineering techniques is > more than a matter of finding the money (and especially time) to read > a good book on it--we all have different priorities on what we can > afford to spend "10,000 hours" on. (Note, I'm not saying it wouldn't > be useful for all of us to learn these things, just that I don't > expect working mathematicians to all find enough time on the side to > become expert software developers as well). > - Robert IMHO, if Sage is every to become a viable alternative to Maple, Mathematica or MATLAB, then practicing good software engineering is an absolute *must* - not an option. (I purposely excluded Magma from that list, as I know nothing about that tool). If you believe that levels of quality equal to those three commercial packages can be achieved without such skills, then we will have to agree to differ. Of course, for some users Sage is no doubt already the best of these packages, but it is unlikely to be so for a mass audience without major changes. I was not suggesting anyone spend 10,000 hours studying the subject of software engeering. I'm not suggesting people need to be experts. But perhaps spending 20-50 hours on it is not unreasonable. I don't know about you, but I've probably devoted 1000 hours to working on Sage, so 20-50 is a small percentage. I think 20-50 hours would be for you too. It's a fact of life that you often have to learn new skills. 20-50 hours would not mean taking a week off of work, but reading a book on a train to work, or at night instead of a bit of TV. Expecting a new developer to spend such time would be unreasonable, but then their contributions should in my opinion come under closer scrutiny from those with better knowledge. Mike Witt said above, with reference to the Sage bugs: "I personally have been burned enough times now by obvious bugs that have shown up when I try to demonstrate what I'm doing in sage, that I hesitate now to shares things readily." It's clear to me (and perhaps Mike) the current methodology is not working. I certainly would not hesitate to show people things with MATLAB or Mathematica. If one of these tools did crash, I would not have egg on my face. But with Sage I would. Currently one person with poor Python skills can review the work of another with poor Python skills, and the code get committed to Sage. There's little filtering. I know Kcrisman has said +1 to your comments, so I'd say I'd have to disagree with him too. > On a more practical note, I think it may help things if we actually > used the priority field. Certainly > Blocker: 14 > Critical: 68 > Major: 1609 > Minor: 516 > Trivial: 26 Of course most are "Major" as that is the default. Many were at one time the "algebra" component. That's what I added a new category "PLEASE CHANGE". Likewise the default "type" is now "PLEASE CHANGE" and not "defect". Actually, if one was to take the time to read about the topic of software quality control, one would discover that setting priority like we do is far from optimal. It would be better to have a formula, something like: priority=f(Severity, Impact, Visibility, Class) http://software-quality.blogspot.com/2005/09/bug-priority-and-severity.html http://knol.google.com/k/setting-bug-severity-and-priority# http://geekswithblogs.net/srkprasad/archive/2004/08/20/9961.aspx 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
