On 11/4/14, 7:04, Volker Braun wrote:
    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

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

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.

Thanks,

Jason


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

Reply via email to