On 2 April 2011 18:08, Robert Bradshaw <rober...@math.washington.edu> wrote:
> I think the key point is that there are several metrics for judging > code. Some judge code by how many compiler warnings it produces, or > how standard-abiding it is. Others judge code by clarity of the > expressed algorithm(s). It's hard for me to see how code that produces loads of compiler warnings about unused variables can offer clarity of the algorithm. If you find a variable called "cutoff" which is not used, one is never sure if the code for the cutoff was overlooked, or whether it was not needed. (There was, perhaps still is, a bit of code in Sage which has an unused variable called "cutoff") > Yet others judge code by whether it works > correctly for their domain, or the sophistication of the algorithm, or > its speed. I understand all those. I feel if the speed is slow, if there's nothing better that's open-source, then I don't have a problem with it. Within reason, functionality that is slow is better than no functionality. > All of us weight these factors differently, and I don't > think anyone would consider any of these criteria bad, but we > shouldn't say code is bad because it doesn't satisfy only our choice > of metric. Agreed. But I agree with Volker's comments he posted a day or so ago about code relying on specific header files or compiler features. Such code may be perfectly acceptable for an individual to use on his or her computer, but its incorporation into software that designed to be portable is not a good idea until such time as either an upstream author or a Sage developer has cleaned it up. The particular software under discussion has been the source of several issues I'm aware of: 1) Passing of an assembler option to hide warnings caused a problem on Solaris. http://trac.sagemath.org/sage_trac/ticket/6609 2) This gcc 4.6 issue http://trac.sagemath.org/sage_trac/ticket/10892 3) A Cygwin issue (still unresolved) giving no results http://trac.sagemath.org/sage_trac/ticket/9165 4) Fails to build on HP-UX (admittedly not a high priority platform) http://trac.sagemath.org/sage_trac/ticket/7178 There are a number of tell-tale signs which should have ensured the code had an overhaul before being merged into software like Sage. Currently the latest gcc (4.6.0) is a bit more fussy than previous versions, so 3 pieces of software in Sage have been broken (Singular, Lcalc and PolyBoRi). Lcalc has a workaround, PolyBoRi has been fixed properly and to the best of my knowledge, the Singular problem has not been resolved. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
