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.