> > If you know of *anything* that should be added, contributions are > greatly welcome. >
It is not clear yet if I will ever contribute something substantial to sage before leaving research, so here some suggestions (which are sadly of much less value): For example, Sage has a 100% doctest policy, and people can inspect > the source code of Sage and see that we follow it. > If sage developers find it useful, spread this to other groups! Consider that there is (e.g. in Singular) a difference between the official and practised policy! - sensitize developers about testing and handling special cases - develop and use a framework for auto-testing routines by throwing random examples at them and by comparing different implementations. To my knowledge, there was already something done in this direction by the sage group. - pay QA stuff or users for bug hunting. *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. > > I'm aware of this; it is a good start. AFAIK it does not support 'stopgame' at function level, only at package level. I have some suggestions here, but again they are much less worth than real contributions. ( AFAIK the user does not get any warnings if he uses polynomial rings over integers. This functionality is broken in Singular for years and should be completely disabled in my opinion until it got fixed. There is work in progress by Adi Popescu and Anne Frühbis-Krueger) ) Jakob Am Freitag, 24. Oktober 2014 19:01:58 UTC+2 schrieb William: > > On Fri, Oct 24, 2014 at 9:16 AM, Jori Mantysalo <jori.ma...@uta.fi > <javascript:>> 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+...@googlegroups.com <javascript:>. > > To post to this group, send email to sage-...@googlegroups.com > <javascript:>. > > 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.
