Re: [sage-devel] Re: lcalc code quality
On Tue, Apr 5, 2011 at 7:50 AM, Volker Braun wrote: > On Tuesday, April 5, 2011 8:13:17 AM UTC-4, Bill Hart wrote: >> >> Ah, it seems that you do not actually want expert mathematicians who >> are not expert coders to contribute code to Sage. > > You are missing the point of this thread; its not at all about Mike R > tripping over one of the numerous C++ pitfalls. I don't doubt that his > program is great at what it does, and its awesome that he shares it with > us. > The issue is what I see as a failure of the Sage review process where some > code that doesn't seem to be ready for public consumption was shoehorned > into a library. There was no Sage review process when lcalc was added (by me) to Sage. At the time (2005?) I did not know that Sage would grow beyond just being a number theory system used mostly by me. A new substantial upstream library that has tons of issues should definitely not be added to Sage today, and I don't think any such thing has happened since 2007 when we enacted a voting/review process for package inclusion. > Ideally, one of the Sage developers who works in that field > would team up with the upstream author and polish lcalc. This would be both > a service to Sage and the mathematical community. +1 That would be great, and I'm very much looking forward to it happening. Mike is normally at Univ of Waterloo, which has an extremely strong CS program and CS students, so this could perhaps be a student project sometime in the future. Perhaps this thread will provide some motivation for such a project. -- William -- 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
Re: [sage-devel] Re: lcalc code quality
On 2 April 2011 18:08, Robert Bradshaw 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
Re: [sage-devel] Re: lcalc code quality
On Apr 2, 2011, at 06:20 , Bill Hart wrote: > > > On Mar 31, 8:41 pm, Jason Grout wrote: >> On 3/31/11 2:09 PM, kcrisman wrote: > >> +1 to everything you said. Also, I'd like to point out that since many >> upstream developers lurk on this and other Sage lists, our "colloquial" >> conversations actually are heard by many upstream developers. Even if a >> particular upstream developer is not subscribed, many other upstream >> developers see how we behave as a group and that will probably influence >> their opinion of Sage. > There's a fine line between critiquing/refereeing/improving code and > ridiculing it. 1++ -- Justin C. Walker, Curmudgeon at Large Director Institute for the Enhancement of the Director's Income --- Nobody knows the trouble I've been --- -- 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
Re: [sage-devel] Re: lcalc code quality
On Saturday, April 2, 2011 1:08:51 PM UTC-4, robertwb wrote: > > I think the key point is that there are several metrics for judging > code. > While there certainly is some artistic quality to what constitutes "beautiful code", surely we can agree that code that relies on implementation details of the system headers or any other unspecified behavior of the compiler is bad. This is not up to discussion; if you rely on unspecified behaviour then you will sometimes obtain wrong (and sometimes only subtly wrong / lowered precision) results. Which is particularly dangerous in floating-point computations where you can't test all bits of the result against some theoretical prediction. -- 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
Re: [sage-devel] Re: lcalc code quality
On Sat, Apr 2, 2011 at 8:18 AM, David Kirkby wrote: > On 2 April 2011 14:20, Bill Hart wrote: > >> Please also bear in mind that many "upstream" developers have put >> years of their life into research, development of algorithms and >> coding. Many of them are professional mathematicians, not computer >> scientists or professional programmers. They live and die by theorems, >> grants, teaching, publications, etc., not language standards and may >> only care if their code works for them and their immediate friends! >> They very often do not have time to maintain it to the high standard >> they might prefer, and their donation of their code is made on that >> understanding. > > > Fair enough, but I would hope the quality control in Sage would > prevent poor code being merged in the first place. That does not seem > to have been so, though I think the situation is improving somewhat. 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). Yet others judge code by whether it works correctly for their domain, or the sophistication of the algorithm, or its speed. 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. > I would not expect to see code written by pilots controlling aircraft > or code written by medical staff controlling medical equipment. > > OK, these are extreme cases, but happen to be two industries I have > worked in (aeronautical and medical), though I have never had to write > safety-critical software for either industry. > >> There's a fine line between critiquing/refereeing/improving code and >> ridiculing it. +1 - Robert -- 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
Re: [sage-devel] Re: lcalc code quality
On 2 April 2011 14:20, Bill Hart wrote: > Please also bear in mind that many "upstream" developers have put > years of their life into research, development of algorithms and > coding. Many of them are professional mathematicians, not computer > scientists or professional programmers. They live and die by theorems, > grants, teaching, publications, etc., not language standards and may > only care if their code works for them and their immediate friends! > They very often do not have time to maintain it to the high standard > they might prefer, and their donation of their code is made on that > understanding. Fair enough, but I would hope the quality control in Sage would prevent poor code being merged in the first place. That does not seem to have been so, though I think the situation is improving somewhat. I would not expect to see code written by pilots controlling aircraft or code written by medical staff controlling medical equipment. OK, these are extreme cases, but happen to be two industries I have worked in (aeronautical and medical), though I have never had to write safety-critical software for either industry. > There's a fine line between critiquing/refereeing/improving code and > ridiculing it. Very true, but the fact it is in Sage, does cause frustration. I suspect it was frustration which was the provocation for the initial rather harsh comments on this thread. There are bits of code in Sage, which even a cursory glance at the source code, or a look at the compiler warnings, should have in my opinion stopped it being in Sage before it was cleaned up. If the code was thought to be very useful (like Sympow), but of dubious quality (you yourself once wrote Sympow was "virtually obfuscated") https://groups.google.com/group/sage-devel/msg/d7aef307c15de2e6?hl=en then perhaps it should have remained experimental. Or perhaps it should have never been put in Sage, but people used it external to Sage. 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
Re: [sage-devel] Re: lcalc code quality
> > BTW, what is the full name of the author? SPKG.txt says "Rishikesh", yet > people here talk of "Risi" and "Mike". > Rishikesh is Mike Rubenstein's graduate student. That is his entire name; Rishi is an abbreviation. Mike is an abbreviation of Michael. I will suggest to Mike within the next hour about putting lcalc onto googlecode, just as I did with eclib. In fact, what made me put eclib onto google code was following Mike's example http://code.google.com/p/lmfdb/ John -- 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
Re: [sage-devel] Re: lcalc code quality
On 04/ 1/11 09:53 AM, Robert Bradshaw wrote: +1, to all of the above. What I was trying to say is that we should focus on getting the (very sophisticated and useful) code to compile and work again, rather than complain about the number of compiler warnings it gives. Getting it into a public repository would be a great step forward for those who care about cross-platform compatibility and compiler workings to contribute. - Robert A possible (probable?) problem will be that it will be very difficult for someone to know what changes to make. The current lcalc code in Sage is not valid C++, so trying to know what the author intended would be difficult and I feel attempting to clean it up would be more likely to break the code than improve it. BTW, what is the full name of the author? SPKG.txt says "Rishikesh", yet people here talk of "Risi" and "Mike". I've fixed many portability issues in the past, when it was clear what the author intended and one can see his mistakes. This is probably not so with 'lcalc' - at least based on what I can see just now. Obviously if revised code is much better then it may be possible for someone to clean it up further. Sympow was another case similar. I don't think anyone could clean up Sympow, as it's not valid C, so hard to know what the author was trying to do. I only managed to fix a bug in that as a result of finding a reference to a paper, reading the paper, then I was able to work out what the author intended. But I believe cleaning up Sympow would be dangerous rather than constructive. The big advantage here with lcalc is the author is still available, although busy just now. It might be safer to leave him to do it. If the Sun compiler was installed, this would give him the chance to turn it into valid C++. Then it would be much more maintainable. 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
Re: [sage-devel] Re: lcalc code quality
On Thu, Mar 31, 2011 at 12:09 PM, kcrisman wrote: > >> And I agree that we should communicate with the author politely. I was >> addressing the Sage developers that use lcalc, and I think that its >> allowable to use a more colloquial tone in that case. > > I would submit that we should be as polite as possible whenever > discussing component pieces of Sage. We depend on them to make it > work great. This is especially true when discussing something fairly > technical to a large proportion of Sage developers, I would guess, and > certainly to the many users who subscribe or visit this on the web in > the hopes of learning something. This is a public forum, even if it > often doesn't seem like it because we get to know one another to some > extent at Sage Days and on the list. > > As a separate issue, I realize that not everyone will agree on what > acronyms/cuss words are appropriate for this forum, so I won't push > this too strongly. But my guess is that the public Mma lists, or > Mapleprimes, wouldn't be too hot on this as a customer relations > strategy. > > (I also realize that now someone will prove me wrong by finding a much > worse example on one of those sites!) > > Colloquially yours, > - kcrisman +1, to all of the above. What I was trying to say is that we should focus on getting the (very sophisticated and useful) code to compile and work again, rather than complain about the number of compiler warnings it gives. Getting it into a public repository would be a great step forward for those who care about cross-platform compatibility and compiler workings to contribute. - Robert -- 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
