Hello, For the past 10 years, I have followed the discussions about commons-math on the dev ML and I even contributed to the Levenberg-Marquardt code some years ago. Before I leave this ML because I am fed up, I would like to give my final 1 cent comment.
What I have seen over these years are distinct categories of people with antagonist approaches trying to build something together. For the sake of simplicity, I am going to assume that everybody is proficient in his/her own field. There is a group of people who initially needed some tool for their own work. Regardless of how many people over the whole world would need such a tool, those contributors decided to add it to commons-math in order to make commons-math community a de facto beta tester (ever wondered why some releases were pushed out so strongly, so quickly?). These contributors usually did their best to comply with the commons rules of coding. Their assumption about the amount of beta testers for their very own contribution was often too optimistic: the more specialised the code, the fewer the users! They nevertheless had the feeling of bringing their block to the big monument, whether the monument is better/stronger/nicer with it or not did not matter to them! A second group does not seem to be so interested in getting a working code that it is in getting a nicely written (maintainable!) code. Every now and then, someone appears on the list, wants to bring some contribution (e.g. bug fixing) and notices that the whole code is not written in the way (s)he would have written it. That often results in several weeks of discussions where only purely 'philosophical' arguments are exposed (I propose this name for a method instead of that one, that class should belong to this package rather than that one, ...). For the past several weeks, I have seen yet another group who seems to only care about how this monument should be displayed/dismantled/reshaped. Should one drop an old working block because no one feels knowledgeable enough to maintain it? What about the actual users? What do they/we want? My first guess would be that most of them simply do not want to have to reinvent the wheel: they do not want to go back to a linear algebra 1st year college textbook to write down their own version of LU decomposition! They expect it to be readily available somewhere. However, I bet that if they are dealing with a huge sparse ill-conditioned matrix, they will be willing to go to a research paper to find out what the most appropriate algorithm could be and to implement it if it is only described in pseudo code style. Even if one implements the best known algorithm for this type of matrices, one should then be humble and accept that very few other Java users would actually be interested in that code so why would you want to pollute the Java math Swiss knife? Interested in aggregating some new contributors? Always nice but you will eventually end up in the same situation: a few users will want to contribute with their exotic needs, written in a way that will clash with the philoso- phers who know better how things should be written! At the next divorce between the two, one will again end up calling the lawyers to settle who takes the chairs and who keeps the dog. There is presently no consensus, not even on what the content of the Swiss knife should be! Rather than rushing into several votes, first agree upon what textbook should be used to define the core of any math library. Regards, Dimitri Pourbaix. ---------------------------------------------------------------------------- Dimitri Pourbaix, FNRS * Don't worry, be happy Institut d'Astronomie et d'Astrophysique * and CARPE DIEM. CP 226, office 2.N4.211, building NO * Universite Libre de Bruxelles * Tel : +32-2-650.35.71 Boulevard du Triomphe * Fax : +32-2-650.42.26 B-1050 Bruxelles * NAC: HBZSC RG2Z6 http://sb9.astro.ulb.ac.be/~pourbaix * mailto:pourb...@astro.ulb.ac.be --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
