On 06/05/2014 04:15 AM, Waldek Hebisch wrote: >>> The code is equivalent given initial conditions. #listpol >>> different than 3 does not make sense for this function. >> >> No matter what. Just because nobody bothered to write some >> documentation, I have just wasted one hour of my life. :-( > > Well, you got confused because: > > 1) the 'while' loop in original code was confusing. It is gone > now...
That I appreciate. > 2) Using list to "pack" univariate gcd and cofactors. We could try > to rewrite it using separate record fields. But there is still > potential for confusion because of sepecial cases. Much easier. You have already analysed the code and know what the parameters mean. I only started and just see UTerm ==> Record(lpol : List SUP, lint : List List R, mpol : SUPP) If you had added a line saying what the meaning of the parts of this record are, that would have been 1) relatively cheap and 2) would convey enough information to prevent me from considering the case that lpol not always contains a list of 3 polynomials. Well, maybe it's "one or two or three" instead of "exactly 3". I don't know, I have to invest time that has already been invested by you. Sure, it's certainly a bit more inefficient for you, but still relativly cheap, but for the whole of FriCAS, such "commenting code when one comes to it" would be a huge benefit. > Well, you imagine how things should work and if they do not work > that way you are sad. That's not the point. Communication in FriCAS happens via mailing list. That's OK and needed. But it's inefficient if one reads code and doesn't know whether some code has already been discussed on the mailing list. By which question do I find that information on the mailing list? Maybe there is nothing in the mailing list, maybe my search engine is simply not good enough, maybe I have to give the answer in the search to find it in the mailinglist. I call that needlessly wasted time. It would be much more efficient to put at least some links to relevant information about the code into some comments. > I do not count hours spend on PGCD. I do not consider it wasted > time. I also don't count hours for code that comes from NAGcdrom that has never been newly considered. How else could I have reconstructed the book? But it's wasted time if someone else could have easily provided at least some hints inside bugfixes or new code. That helps quite a lot. > And my impression is that if your purpose was understanding PGCD, > than you approached it in rather inefficient way. My recent effort was, to understand your undocumented patch. I already failed with the "only refactoring" part. So the conclusion that everyone here on the mailing list can draw is that this guy must be totally stupid to even start with such an approach. > First, it is unreasonable to expect that you will immediately > understand a routine inside in isolation Sorry, but that's not why ideal. An implementation simply must match its specification. (It's not enough that it runs well.--What would be the definition of "well"?) That doesn't depend on any context. I may not get the big meaning of that function (for that literate programming would be the best thing), but that's OK at first. But there is no specification. So I must read code and extract the specification from the code. Unfortunately, that extracted specification is most often *not* what the original programmer had in mind. > : the routines are part of single algorithm and each operate in > context created by other routines. If you want to track code > line-by-line you need to start from entry point and reconstruct the > context. Sure, I start from the top and then hit a function that I don't know what it does or even what type it will return. So I try to investigate this function. Sure, I would have to insert print commands and try to recognize what the parameters are and what they could look like in order to understand the sub-function. So in fact, I have to redo the work that *you* have already done. I somehow feel treated as if I were your student. > Third, there is literature. http://www.ams.org/journals/mcom/1978-32-144/S0025-5718-1978-0568284-3/S0025-5718-1978-0568284-3.pdf Cool, the reference is even freely available (don't know whether that's truely the case since AMS might check IP addresses and allow me if I come with my university IP.) In general one cannot assume that the code follows the paper exactly. The big picture from literature is OK, but there may be tricks and optimizations in the code that are nowhere documented. That was the way code was written in those days and even today. I just hope that some day people realize that it's not enough to document the idea of the algorithm and leave the nasty details to the programmers. What if the programmer interpreted some part of the paper differently from everyone else? That gives a bug which certainly happens all the time, but which is hard to track down. You can even be the author of the paper and don't understand the programming language well enough, so you introduce errors that are not documented in the paper. > Fourth, we have this mailing list and you can ask questions > here. My impression is that when you have specific question, it > typically get answered. Yes, sure you answer my questions and I appreciate that. But the question about what is the meaning of the parameters of the functions would probably have been too unspecific and left unanswered. Am I wrong? Furthermore, if the next person comes one year from now would you answer the same question again? Would you be able to find your answer in the mailing list, so that you can send a link? Don't such repeated questions also waste *your* time? Yes, yes, I know, we are only two developers and such repeated question case is void. Sure, I probably don't change your attitude towards the need for documentation, but if you are just saying that people are not motivated enough to go through the code themselves and understand all this legacy code by themselves or are just not smart enough and therefore cry for more documentation ... that doesn't help FriCAS to become more easily accessible even in 10 years from now. FriCAS is a one-man-show. If *you* get uninterested, FriCAS is dead. I want FriCAS to live and that is my reason to invest my time in bringing hyperdoc to the web. It certainly doesn't count for my CV, but I hope it helps others or just makes FriCAS more visible because search engines have certain mathematical terms from the ++ comments that they can put into their index. Ralf -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
