> > > > I can see that there could be a number of follow up comments about > > the article. But too much emphasis on Sage's ability to perform the > > computation correctly would make it like a childish pi**ing contest. > > > > Agree. A reasonable article should >
Yes. > > > > a) give some overview over the algorithms involved > > > > b) talk about bug tracking and prioritization, stopgaps > > > > c) automated testing to prevent the same issue in the future > > > And presumably pointing out that while all such software (hopefully!) has such things internally, in open source you can see it. > > There have been subtle bugs in determinants of integer matrices in Sage > > before, e.g. http://trac.sagemath.org/ticket/14032 "determinant() of > > integer matrices of size in [51,63] broken". Open source doesn't make > > Sage magically bug-free. But Linus' law applies: "given enough eyeballs, > > all bugs are shallow". > > I agree with both of you. Given that a significant part of this article > dwelt on the closed-source bug-reporting frustration, it might be even > more interesting if the user was taken through an actual bug found in > Sage, and the bug-reporting and bug-fixing process was described, > emphasizing the open approach and the role the authors could play. I > was disappointed with the original article's conclusions---it gave the > impression that the best we could hope for in finding, reporting, and > fixing bugs in mathematical software was that we might be able to find > them in comparing the output of two different black boxes. > Exactly why I passed the article on. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
