On Fri, Oct 24, 2014 at 9:16 AM, Jori Mantysalo <jori.mantys...@uta.fi> wrote: > On Fri, 24 Oct 2014, Jakob Kroeker wrote: > >> Does Sage warn somehow the user if a user calls a function which is >> *known* to be buggy?
*YES, we do*. At a Sage days a few years ago, Robert Bradshaw, David Roe, me and others introduced a "stopgame" framework for exactly this. You can see 52 tickets involving it here: http://trac.sagemath.org/search?q=stopgap If you know of *anything* that should be added, contributions are greatly welcome. I'm extremely appreciative that you (Jakob) are making repeated noise about software quality. Sage is sufficiently mature (at 10 years old now) that the timing is very much right to have a new round of discussion about how to improve quality. We had a similar discussion around 2006 spurred mainly by Craig Citro and Michael Abshoff, which led to numerous substantial improvements in Sage development. Last year we had a dramatic improvement in the technical workflow (based on git branches instead of text-based patches) pushed by Andrew Ohana and Volker Braun. But there is much room for improvement. For example, Sage has a 100% doctest policy, and people can inspect the source code of Sage and see that we follow it. That's something Craig Citro convinced us to do 7 years ago, and it has had I think a genuinely positive impact on our code quality, and ability to have a larger number of developers. Michael Abshoff used to obsessively run valgrind on Sage, which detected and fixed many issues with memory leaks, pointer issues, segfaults, etc. Is there another "lead bullet" that we should add to our arsenal? For me the biggest clear technical value in having access to source code is: - It makes it *much easier to adapt/change* for research purposes, since what you *want* to do is often not exactly what the implementors made available. Source code makes this much easier, since (if nothing else) it no question at all makes it possible to more deeply understanding what you're building on. - Reading source code of math software you're using can help you *decide how much to trust or not trust it*. This is precisely your point -- when you started reading through the code of Singular, you definitely came to conclusion about how much to trust it. Looking at code and deciding -- oh crap, this stuff is a mess -- even if you still use the code in research, is very valuable. Sometimes even bad code is very useful for research purposes, depending on the field of mathematics. An obvious example is "integer factorization". Horrible buggy code is still useful there. -- William > > > Sometimes, but for example > > On Fri, 24 Oct 2014, Jean-Pierre Flori wrote: > >> We're stuck at http://trac.sagemath.org/ticket/17184. >> I've also posted on Singular forum: > > > I know that Singular versions 3.x has a heisenbug, it stucks sometimes when > factoring multivariate polynomials over rationals. There is no warning > message. > > (But of course user do not get wrong answer, if there is no answer at all.) > > -- > Jori Mäntysalo > > > -- > 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. -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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.
