From campagne@incm.u-nancy.fr Sat Aug 9 13:16:33 1997 Received: from brown.incm.u-nancy.fr for campagne@incm.u-nancy.fr by www.ccl.net (8.8.3/950822.1) id NAA21220; Sat, 9 Aug 1997 13:09:41 -0400 (EDT) Received: from yellow.incm.u-nancy.fr by brown.incm.u-nancy.fr via ESMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id SAA13958; Sat, 9 Aug 1997 18:12:37 +0100 Received: from yellow.incm.u-nancy.fr (localhost [127.0.0.1]) by yellow.incm.u-nancy.fr (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id SAA08115; Sat, 9 Aug 1997 18:12:34 +0100 Sender: campagne@incm.u-nancy.fr Message-ID: <33ECA501.41C6@incm.u-nancy.fr> Date: Sat, 09 Aug 1997 18:12:33 +0100 From: Fabien Campagne Organization: Laboratoire de Chimie The'orique de Nancy X-Mailer: Mozilla 3.0SC-SGI (X11; I; IRIX64 6.2 IP28) MIME-Version: 1.0 To: chemistry@www.ccl.net, Konrad Hinsen Subject: Re: CCL:Design/OO/standardization References: <199708081413.QAA22116@lmspc1.ibs.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Konrad Hinsen wrote: > > > Development of software for Computational Chemistry > > by researchers is usualy focused on new methodologies. > > That's a matter of specialization: people who develop > > and maintain scientific software have less time to use > > these software to applied research than people interested > > in applications only. These two communities have distinct > > needs: > >... > > The needs are distinct, but that doesn't mean that they can't be dealt > with in a single implementation. A well-designed modular system > would consist of well-tested high-performance modules for established > techniques and experimental modules for experimental techniques. A common "design" could be used, not a common "implementation". Going from "experimental modules" to "well-tested high-performance modules" imply changing the implementation: at the end of the process the program won't be the same one (different executables: different implementations). Ok, this remark is a bit particular, I agree :-) > > Computer scientific community uses standardization commitees > > that consist of experts in one field talking together until they > > agree on a standard: ONE way to do something that meet experts > > idea of what is important (performances, reusability, extensability..). > > That is one possibility, but equally many products are essentially > designed by a single person. There are good and bad aspects about > both approaches. You point out the main difference between these two approaches: PRODUCTS "are essentially designed by a single person" STANDARDS are designed, discussed, refined, finaly accepted and documented by a set of people that represents a large panel of needs. These needs reflect needs of the much larger number of people that will work with the final standard. It seems to me that the final product of a software design, whatever it is about, reflects experiences (sometime opinions or convinctions, sometime knowledge of the logic under the system to be designed, sometime statistical observations) of the people involved in the design. If one person is to design a product because this product will be used by himself only, that's fine (same thing with "team" for "person"). In case of standards, which actual goal is to offer a COMMON solution to a problem that interests a community, the least you can do is give as much people as possible the oppportunity to discuss and criticize the choices before they are adopted as the standard. If you fail to do so, the "standard" won't be adopted by the community (ie. won't be used) because it won't reply to the needs of the majority of the people in the community. > > What about standardizing interfaces for common algorithms ? > > It seems to me that a minimization algorithm looks like > > another and should be used the same way from the code > > I'm writing (whatever the implementation I actually decide > > to retain) > > Almost. Minimization algorithms do essentially the same job, but > require different parameters for controlling convergence, step sizes, > etc. And there are many more situations in which various algorithms > have almost the same interface. > > An OO solution to this problem is to encapsulate the algorithm in > an object that also stores all the parameters. For example, you The Standard Template Library, which IS part of the standard C++ library, proposes algorithms (for each, find, sort, transform,... to name a few) that are not designed as objects. They are implemented using "generic programing" in C++. to learn more about this alternative approach, you could read http://www.ipmce.su/~fbp/stl/StepanovUSA.html and look at http://www.cyberport.com/~tangent/programming/stl/resources.html for information about STL. The "generic programing" approach seems well suited to fine grain algorithms (very low level components) because its C++ implementations can be very efficient. In any case, it's certainly a good idea for a C++ programmer to know about.. > could create a "steepest descent object" with a certain parameters > and a "conjugent gradient object" with another set of parameters, > and then apply the two in exactly the same way to a molecular > system. > > > Couldn't we design our software so that algorithms are > > parameters for algorithms (at compile time). Maybe an example > > Once algorithms are encapsulated in objects, this is trivial: > the algorithm object is simply passed as an ordinary parameter. > For an example, look at the description of minimizer objects > in my Molecular Modelling Toolkit; the relevant page of the manual > is http://starship.skyport.net/crew/hinsen/mmtk_manual/dynamics.html. I agree with you that OO design is a good way to design evolutive systems. The point I would like to insist here again, is: if we want to be able to reuse computational chemistry software components (pieces of code written by different labs or individuals and made available to ohers) -- in a rational way --, we need to design, carefully, a common interface to related components. I understand some people reading this post may be not familiar with the terminology: components, design, interface (interface beetween two pieces of code, not graphical user interfaces). I'm currently writing a few www pages to describe these concepts and the way they can be useful to computational chemistry software reuse. I'm convinced the real problem that curb the ermergence of interfaces between already existing components is a lack of information on 1/ the advantages of the method 2/ the "how to" problem. I'll post an announce to CCL once this resource will be available. Fabien Campagne -- campagne@incm.u-nancy.fr | Lab. de Chimie Theorique phone: +33 (0)3 83 91 20 00 extension 3236 | Nancy, France. http://www.lctn.u-nancy.fr/viseur/FC.html From hinsen@lmspc1.ibs.fr Sat Aug 9 14:16:48 1997 Received: from ibs.ibs.fr for hinsen@lmspc1.ibs.fr by www.ccl.net (8.8.3/950822.1) id NAA21288; Sat, 9 Aug 1997 13:38:43 -0400 (EDT) Received: from lmspc1.ibs.fr (hinsen@lmspc1.ibs.fr [192.134.36.141]) by ibs.ibs.fr (8.6.12/8.6.12) with ESMTP id TAA14804; Sat, 9 Aug 1997 19:39:57 +0200 Received: (from hinsen@localhost) by lmspc1.ibs.fr (8.8.5/8.8.5) id TAA25991; Sat, 9 Aug 1997 19:38:29 +0200 Date: Sat, 9 Aug 1997 19:38:29 +0200 Message-Id: <199708091738.TAA25991@lmspc1.ibs.fr> From: Konrad Hinsen To: campagne@incm.u-nancy.fr CC: chemistry@www.ccl.net In-reply-to: <33ECA501.41C6@incm.u-nancy.fr> (message from Fabien Campagne on Sat, 09 Aug 1997 18:12:33 +0100) Subject: Re: CCL:Design/OO/standardization > A common "design" could be used, not a common "implementation". > Going from "experimental modules" to "well-tested high-performance > modules" imply changing the implementation: at the end of the process > the program won't be the same one (different executables: different > implementations). Ok, this remark is a bit particular, I agree :-) True, but only individual modules would change. The majority of the implementation would remain the same. > You point out the main difference between these two approaches: > PRODUCTS "are essentially designed by a single person" > STANDARDS are designed, discussed, refined, finaly accepted > and documented by a set of people that represents a > large panel of needs. These needs reflect needs of the much The distinction is not that clear-cut. Often de-facto standards are defined by a single product (e.g. the IBM PC or the Visual-Basic language) that is later copied. And even official standards are sometimes to a large degree based on the work of one person; for example, the coming C++ standard would not exist without the preliminary definition of C++ by Bjarne Stroutstrup. > If you fail to do so, the "standard" won't be adopted by the > community (ie. won't be used) because it won't reply to the needs > of the majority of the people in the community. And even if everyone is involved in the definition of a standard, it may well in the end be ignored, typically because it became irrelevant during the long time of the standardization process. Anyone using ISO-Pascal out there? Probably not. When it was ready, all Pascal dialects other than Turbo-Pascal had essentially disappeared. > > An OO solution to this problem is to encapsulate the algorithm in > > an object that also stores all the parameters. For example, you > > The Standard Template Library, which IS part of the standard C++ > library, proposes algorithms (for each, find, sort, transform,... > to name a few) that are not designed as objects. They are implemented Because they do not need parameters for their specification. Besides, templates are a technique specific to C++, not a general OO technique, therefore the STL approach is not easily generalizable. > The "generic programing" approach seems well suited to > fine grain algorithms (very low level components) because > its C++ implementations can be very efficient. In any case, > it's certainly a good idea for a C++ programmer to know about.. Obviously. In fact, the whole STL is something C++ programmers should definitely know about! > I agree with you that OO design is a good way to design evolutive > systems. The point I would like to insist here again, is: > if we want to be able to reuse computational chemistry software > components (pieces of code written by different labs or > individuals and made available to ohers) -- in a rational way --, > we need to design, carefully, a common interface to related components. Ultimately yes. But I think we are still far from a state in which such as decision could be made. There is hardly any practical experience with OO program packages in computational chemistry. But designing a standard requires first analyzing existing solutions to find their good and bad properties. > I understand some people reading this post may be not familiar > with the terminology: components, design, interface (interface > beetween two pieces of code, not graphical user interfaces). Which is the proof that there is not enough practical experience around! Anyone taking part in a standardization process must not only be familiar with such terms, but also have practical experience with these concepts. > software reuse. I'm convinced the real problem that curb the > ermergence of interfaces between already existing components > is a lack of information on 1/ the advantages of the method > 2/ the "how to" problem. Right. But I am not sure that explaining all that on a Web page will be sufficient - the difficult part could be convincing people to read it! -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28 Institut de Biologie Structurale | Fax: +33-4.76.88.54.94 41, av. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais -------------------------------------------------------------------------------