From online@mactech.com Fri Jul 11 01:06:16 1997 Received: from neon.chem.ucla.edu for online@mactech.com by www.ccl.net (8.8.3/950822.1) id AAA04227; Fri, 11 Jul 1997 00:13:33 -0400 (EDT) Received: from [164.67.21.134] (ts32-1.wla.ts.ucla.edu [164.67.21.190]) by neon.chem.ucla.edu (8.8.0/8.8.0) with ESMTP id VAA15293 for ; Thu, 10 Jul 1997 21:14:56 -0700 (PDT) X-Sender: nick@neon.chem.ucla.edu Message-Id: In-Reply-To: <3.0.16.19970710190111.2a5fcde4@mathtrek.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 10 Jul 1997 21:18:21 -0800 To: chemistry@www.ccl.net From: "nick.c" Subject: Re: CCL:Object-oriented means for computational chemistry programming > Who says FORTRAN cannot be "object-oriented"? How about Windows >FORTRAN .DLL's, or other types of FORTRAN libraries? Please enlighten me >if I'm off-base, but it seems to me that the entire "object-oriented thing" >is simply a modern version of what we used to call a "subroutine" in >FORTRAN. The only difference is that one must adopt an accepted convention >to define the ways in which the "object" \equiv "subroutine" communicates >with the outside world. My understanding is that (despite popular opinion) "object-oriented" does mean more than information hiding. Specifically, a language is object-oriented if and only if it supports three features of the object-oriented paradigm: objects, classes, and inheritance. If you have a copy of Cline and Lomow's C++ FAQ's (ISBN 0-201-58958-3), check out FAQ #11 on page 7 he talks about what OOP is and what each of these features are. An object is definitely more than a subroutine (although I guess it is fair to compare it with a code module in C, Fortran, or any other programming construct which contains both data storage and functions for manipulating that data). Hmm... those of you who don't have the book handy can check out Marshall Brain's _Understanding C++_ pages: Marshall writes: __quote on__ C++ is an "object oriented" language. Object oriented programming is a reaction to programming problems that were first seen in large programs being developed in the 70s. All object oriented languages try to accomplish three things as a way of thwarting the problems inherent in large projects: 1. Object oriented languages all implement "data abstraction" in a clean way using a concept called "classes". We will look at data abstraction in much more detail later because it is a central concept in C++. Briefly, data abstraction is a way of combining data with the functions used to manipulate the data so that implementation details are hidden from the programmer. Data abstraction makes programs much easier to maintain and upgrade. 2. All object oriented languages try to make parts of programs easily reusable and extensible. This is where the word "object" comes from. Programs are broken down into reusable objects. These objects can then be grouped together in different ways to form new programs. Existing objects can also be extended. By giving programmers a very clean way to reuse code, and by virtually forcing programmers to write code this way, it is much easier to write new programs by assembling existing pieces. 3. Object oriented languages try to make existing code easily modifiable without actually changing the code. This is a unique and very powerful concept, because it does not at first seem possible to change something without changing it. Using two new concepts however --inheritance and polymorphism-- it is possible to do just that. The existing object stays the same, and any changes are layered on top of it. The programmer's ability to maintain and adjust code in a bug-free way is drastically improved using this approach. __quote off__ Bottom line: Fortran ain't OOP. That doesn't mean it's not a great language... heh... :-) Well, I'm not going to go there. But, in a completely undefensible statement of preference: today, new code should be built in C/C++ (IMHO). I respect the fact that a huge body of legacy code for comp chem exists in FORTRAN, but I tend to agree with Taisung. The OOP paradigm developed in response to specific demands of the industry. The expectations of users have incresed--will increase--exponentially, the ambitions of programmers have accelerated even faster, and I (JMO) honestly don't think FORTRAN is cabable of continuing to support the increasinly complex and expansive programs that folks want to weave. Just my opinion. ____Nicholas C. DeMello, Ph.D.________________________________________ Online at MacTech Magazine, the Journal of Macintosh Programming http://www.MacTech.com/ _/ _/ _/ _/_/_/ _/ _/ Chemistry: Nick@chem.UCLA.edu _/_/ _/ _/ _/ _/ _/_/_/ MacTech: Online@MacTech.com _/ _/_/ _/ _/ _/ _/ http://www.chem.ucla.edu/~nick/ _/ _/ _/_/_/ _/ _/ From lai@csb0.IPC.PKU.EDU.CN Fri Jul 11 02:06:17 1997 Received: from csb0.IPC.PKU.EDU.CN for lai@csb0.IPC.PKU.EDU.CN by www.ccl.net (8.8.3/950822.1) id BAA04409; Fri, 11 Jul 1997 01:39:01 -0400 (EDT) Received: by csb0.IPC.PKU.EDU.CN (920330.SGI/940406.SGI.AUTO) for chemistry@www.ccl.net id AA20784; Fri, 11 Jul 97 13:38:54 -0700 Date: Fri, 11 Jul 1997 13:38:52 -0700 (PDT) From: "Prof. Luhua LAI" To: chemistry@www.ccl.net Subject: Softwares for Crystal Engineering Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear Netter: A collegue of mine is initiating a project in crystal engineering. We would like to ask your comments on the available softwares for crystal packing analysis and crystal engineering. Please send the answer to my address directly. I will give a summary to CCL. Thanks. ----------------------------------------- Luhua Lai Institute of Physical chemistry & Department of Chemistry Peking University Beijing 100871 CHINA Phone: 86-10-62751490 Fax: 86-10-62751725 E-mail: lai@ipc.pku.edu.cn ----------------------------------------- From glinker@sct.co.uk Fri Jul 11 05:06:24 1997 Received: from fallback.mail.pipex.net for glinker@sct.co.uk by www.ccl.net (8.8.3/950822.1) id EAA05210; Fri, 11 Jul 1997 04:06:41 -0400 (EDT) From: Received: (qmail 3312 invoked from network); 11 Jul 1997 07:47:28 -0000 Received: from sctepsc2.sct.co.uk (194.130.240.7) by relay.mail.pipex.net with SMTP; 11 Jul 1997 07:47:28 -0000 Received: from ccMail by sctepsc2.sct.co.uk (SMTPLINK V2.11.01) id AA868636205; Fri, 11 Jul 97 08:35:52 gmt Date: Fri, 11 Jul 97 08:35:52 gmt Message-Id: <9706118686.AA868636205@sctepsc2.sct.co.uk> To: chemistry-request@www.ccl.net, hinsen@ibs.ibs.fr, serge@qsar.chem.msu.su, "W. R. Smith" Cc: chemistry@www.ccl.net Subject: Re: CCL:Object-oriented means for computational chemistry Please don't confuse object-orientated programming with Windows programming. OO does not have necessarily to do with DLLs and other windows concepts. The benefit of OO lies in the encapsulation of code. An interface (a set of properties and functions) will be provided to the outside world to interact with the object. When you decide to change some code you only have to worry about the object you modify. This reduced the amount of code to worry about. You would only benifit from OO when you make a good object design of your application. Define objects as you would recognize them in real life and not as you see them as a programmer. e.g. good cadidates for objects would be: molecule, atom, spectrum bad candidates for objects are: MathFunctions, InputFile Before moving to OO please consider the tool which tool you choose to work with. Dangerous are the hybrid OO languages like C++ which allow you to write non OO code as well as OO code. Other languages do not provide all OO mechanisms like inheritance etc. Switching to OO is not at all trivial and requires a lot of training. I once heard a OO consultant say that with OO you cannot write spagetti code (code with a lot of goto statments) anymore. You now write macaroni code: the loops are shorter but the mess it the same. Kind regards, Gerrit-Jan Linker Analyst/Programmer SCT International, Manchester email: linker@ilovechocolate.com web: http://members.aol.com/gjlinker/ >Who says FORTRAN cannot be "object-oriented"? How about Windows >FORTRAN .DLL's, or other types of FORTRAN libraries? Please enlighten me >if I'm off-base, but it seems to me that the entire "object-oriented >thing" is simply a modern version of what we used to call a "subroutine" >in FORTRAN. The only difference is that one must adopt an accepted >convention to define the ways in which the "object" \equiv "subroutine" >communicates with the outside world. At 11:10 AM 7/10/97 +0200, Konrad Hinsen wrote: >> FORTRAN still remains the main programming language of computational >> chemistry. But >> I wonder if anybody knew about the programs where methods computational >> chemistry and, in particular quantum mechanical (ab initio or >> semiempirical), MM or QM/MM force field methods are developed by means of >> object-oriented languages (C++ preferably). I know Hyperchem is announced > From gerwalin@iris1.chemie.uni-kl.de Fri Jul 11 06:06:24 1997 Received: from uni-kl.de for gerwalin@iris1.chemie.uni-kl.de by www.ccl.net (8.8.3/950822.1) id FAA05703; Fri, 11 Jul 1997 05:30:39 -0400 (EDT) Received: from iris1.chemie.uni-kl.de by news.uni-kl.de id aa20780; 11 Jul 97 11:30 MET DST Received: by iris1.chemie.uni-kl.de (940816.SGI.8.6.9/940406.SGI.AUTO) for chemistry@www.ccl.net id LAA02480; Fri, 11 Jul 1997 11:30:35 +0200 Date: Fri, 11 Jul 1997 11:30:35 +0200 From: Elmar Gerwalin Message-Id: <199707110930.LAA02480@iris1.chemie.uni-kl.de> To: chemistry@www.ccl.net Subject: G94: how much iterations does "freq=numer" need? Hi I'm trying to calculate IR spectra of aromatic molecules which has to be done using "Freq=(numer,restart)" (g94 users know what I mean) Each step of a numerical differentation needs 4.5 h cpu time. I assume the lines "Re-enter D2Numr: IAtom= 1 IXYZ=2 IStep= 1." mean that one step is starting. Question: How much steps does a calculation (using Cs symmetry) perform? Can someone give me a hint how to calculate the number of steps? I didn't get an answer from G94 yet and the handbooks don't mention such problems. Thanks for any help BYe Elmar ---- Elmar Gerwalin, gerwalin@chemie.uni-kl.de ----- From hinsen@lmspc1.ibs.fr Fri Jul 11 06:10:31 1997 Received: from ibs.ibs.fr for hinsen@lmspc1.ibs.fr by www.ccl.net (8.8.3/950822.1) id GAA05764; Fri, 11 Jul 1997 06:00:34 -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 MAA06179; Fri, 11 Jul 1997 12:01:11 +0200 Received: (from hinsen@localhost) by lmspc1.ibs.fr (8.8.5/8.8.5) id LAA21692; Fri, 11 Jul 1997 11:59:56 +0200 Date: Fri, 11 Jul 1997 11:59:56 +0200 Message-Id: <199707110959.LAA21692@lmspc1.ibs.fr> From: Konrad Hinsen To: support@mathtrek.com CC: chemistry@www.ccl.net In-reply-to: <3.0.16.19970710190111.2a5fcde4@mathtrek.com> (support@mathtrek.com) Subject: Re: CCL:Object-oriented means for computational chemistry programming > Who says FORTRAN cannot be "object-oriented"? How about Windows > FORTRAN .DLL's, or other types of FORTRAN libraries? Please enlighten me > if I'm off-base, but it seems to me that the entire "object-oriented thing" > is simply a modern version of what we used to call a "subroutine" in No, not at all. Object-oriented design/programming refers to a technique of program design that structures non-trivial code around the data, not around the control flow, as in traditional procedure-oriented programming. Object-oriented languages are those which actively support object-oriented programming. (Note that merely enabling it is not sufficient; you can implement object-oriented designs in C, but that doesn't make C object-oriented). That definitely excludes Fortran-77. The classification of Fortran-90 is less clear, since it allows the definition of data types to some extent. However, most definitions of "proper" OO languages postulate support for several fundamental techniques (like inheritance), and by that definition Fortran-90 isn't OO either. > FORTRAN. The only difference is that one must adopt an accepted convention > to define the ways in which the "object" \equiv "subroutine" communicates > with the outside world. Objects are pieces of data, so the closest analog in Fortran are arrays (since there are no other data structures). Objects are defined by the operations allowed on them. For example, a "matrix" object is defined by the mathematical operations addition, product, inversion, element access, etc. In the actual implementation, the operations resemble classical subroutines. But there are lots of important differences in detail. -- ------------------------------------------------------------------------------- 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 ------------------------------------------------------------------------------- From news@franck.pc.Uni-Koeln.DE Fri Jul 11 07:06:27 1997 Received: from franck.pc.Uni-Koeln.DE for news@franck.pc.Uni-Koeln.DE by www.ccl.net (8.8.3/950822.1) id GAA05942; Fri, 11 Jul 1997 06:23:02 -0400 (EDT) Received: (from news@localhost) by franck.pc.Uni-Koeln.DE (8.8.5/8.8.5) id MAA23262 for CHEMISTRY@www.ccl.net; Fri, 11 Jul 1997 12:23:05 +0200 To: CHEMISTRY@www.ccl.net From: R.Rebentisch@uni-koeln.de Newsgroups: local.CCL Subject: C-H stretch IR Int. Date: 11 Jul 1997 12:22:58 +0200 Organization: Physikalische Chemie Universitaet Koeln Lines: 27 Sender: reben@hilbert.pc.Uni-Koeln.DE Message-ID: NNTP-Posting-Host: hilbert.pc.uni-koeln.de Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Cc: reben@hilbert.pc.Uni-Koeln.DE X-Newsreader: Gnus v5.4.52/XEmacs 20.2 Xref: franck.pc.Uni-Koeln.DE local.CCL:332 I use quantumchemical programs to simulate IR spectra (for instance: G94 HF/6-31G**) with Komorinickis and McIvers method to calculate dipole moment derivative tensors. I use the conventional harmonic approximation to calculate normal modes to determine the IR Intensities. Why are the IR--intensities of the C-H stretch modes calculated this way too low in comparison with experiments? Is that due to anharmonicities, if so -- how do anharmonicities influence the IR intensities? Are there references dealing with this topic? Replies can send to me directly, I will summarize to the list. Please use R.Rebentisch@uni-koeln.de for direct replies. thank you very much in advance Rupert Rebentisch -- ---------------------------------------------------------------------- | Rupert Rebentisch | R.Rebentisch@uni-koeln.de | | Institut fuer Physikalische Chemie | fax: 0049-(0)221-470-5144 | | Lehrstuhl Prof. Dr. G. Hohlneicher | tel: 0049-(0)221-470-4816 | | Universitaet zu Koeln | www.rrz.uni-koeln.de/~acp50 | ---------------------------------------------------------------------- From hinsen@lmspc1.ibs.fr Fri Jul 11 07:11:13 1997 Received: from ibs.ibs.fr for hinsen@lmspc1.ibs.fr by www.ccl.net (8.8.3/950822.1) id GAA05957; Fri, 11 Jul 1997 06:25:16 -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 MAA06337; Fri, 11 Jul 1997 12:26:28 +0200 Received: (from hinsen@localhost) by lmspc1.ibs.fr (8.8.5/8.8.5) id MAA21755; Fri, 11 Jul 1997 12:25:14 +0200 Date: Fri, 11 Jul 1997 12:25:14 +0200 Message-Id: <199707111025.MAA21755@lmspc1.ibs.fr> From: Konrad Hinsen To: online@mactech.com CC: chemistry@www.ccl.net In-reply-to: (online@mactech.com) Subject: Re: CCL:Object-oriented means for computational chemistry programming > But, in a completely undefensible statement of preference: today, new > code should be built in C/C++ (IMHO). I respect the fact that a huge I don't disagree in principle, but a few clarifications can't hurt (which are of course largely my personal opinion!): - C is no more OO than Fortran, but it doesn't have most of Fortran's most severe problems. But Fortran-90 is no worse than C, and in some respects better. - The main advantage of C is support: there is a C compiler for every imaginable machine, and there are plenty of high-quality libraries. But there is little support for numerical work, and indeed many C compilers are rather bad at optimizing standard numerical code. - C++ is an exceedingly complicated language, largely due to its compatibility to C. It may seem simple at first, but the more you get into the details the more surprises you will find. Worse, there is a frightening number of "undefined" situations, meaning that the meaning of certain pieces of code is compiler dependent. Writing solid and portable C++ code requires a lot of experience. The payoff may be worth it for professional programmers, but most scientists are not professional programmers. The bottom line: no single language is perfect. I think scientists should get used to the idea of mixed-language programming. For a small number-crunching subroutine the best choice may well be Fortran, but for the majority of a non-trivial program it certainly isn't. But all modern operating systems have provisions to link code in different languages together. Scientists should also have a closer look at high-level languages. They make development and testing substantially easier by taking care of much detail automatically. Of course that comes at a price in terms of speed, but the majority of a typical scientific program is *not* time-critical. The CPU intensive parts are specific subroutines that can still be implemented in a low-level language. My personal recommendation for a high-level language is Python. It is sufficiently simple, has a clear syntax, and a very convenient interface to low-level languages. For C code, a Python interface can even be generated automatically with a tool called SWIG. More on Python at http://www.python.org, and on my "Python for Science" page at http://starship.skyport.net/crew/hinsen/. Finally, for those who don't mind a trip to San Jose, the 6th International Python Conference >from 14-17 October in San Jose will have tutorials, presentations, and discussions on scientific applications of Python. -- ------------------------------------------------------------------------------- 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 ------------------------------------------------------------------------------- From hinsen@lmspc1.ibs.fr Fri Jul 11 10:06:34 1997 Received: from ibs.ibs.fr for hinsen@lmspc1.ibs.fr by www.ccl.net (8.8.3/950822.1) id JAA07281; Fri, 11 Jul 1997 09:57:06 -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 PAA07767; Fri, 11 Jul 1997 15:57:52 +0200 Received: (from hinsen@localhost) by lmspc1.ibs.fr (8.8.5/8.8.5) id PAA23022; Fri, 11 Jul 1997 15:56:37 +0200 Date: Fri, 11 Jul 1997 15:56:37 +0200 Message-Id: <199707111356.PAA23022@lmspc1.ibs.fr> From: Konrad Hinsen To: support@mathtrek.com CC: online@mactech.com, chemistry@www.ccl.net In-reply-to: <3.0.16.19970711093433.2f5f6850@mathtrek.com> (support@mathtrek.com) Subject: Re: CCL:Object-oriented means for computational chemistry programming > >- C is no more OO than Fortran, but it doesn't have most of Fortran's > > most severe problems. But Fortran-90 is no worse than C, and in some > > respects better. > > i.e. Fortran can be OO too. That's not what I wrote, and according to any accepted definition it's wrong. > A quote by a distinguished scientist that I recall from a scientific > meeting about 10 years ago: > > "I don't know what type of programming language scientists will be using in > the next millenium, but it will be CALLED Fortran" > > i.e. Fortran will evolve over time to incorporate newly desired features Maybe. But will it be fast enough? Fortran-90 finally offered features that have been around in other languages for 20 years. And Fortran-90 is far from generally accepted; you can't even expect every scientist to have access to a Fortran-90 compiler yet. > >Scientists should also have a closer look at high-level languages. > >They make development and testing substantially easier by taking care > >of much detail automatically. Of course that comes at a price in terms > >of speed, but the majority of a typical scientific program is *not* > >time-critical. The CPU intensive parts are specific subroutines that > >can still be implemented in a low-level language. > > e.g. a Visual Basic front-end with Fortran or C .DLL's The world is larger than Windows! Visual Basic is a language available on one operating system and from one vendor only. That doesn't make sense for a community which jumps at the latest available supercomputers as soon as they are available. Ever seen Visual Basic on a parallel machine? > No slight against Python, but we all remember the following historical > sequence: > > Algol vs Fortran (1960's) > PL1 vs Fortran (1970's) > Pascal vs Fortran (1980's) > > and now, it's > > C vs Fortran > > On the left-hand side, it has usually been CS (computer-science) types. On > the RH side, it has usually been scientists/engineers. But the "left-hand side" has shown steady improvement, while the right-hand side has merely stressed compatibility. I am not saying that Fortran will disappear soon, but it will become one among several languages used in science and engineering. There is already a clear trend towards increased use of C and C++, which has never happened with Algol or Pascal. Instead of keeping up the battle between "CS types" and "scientists", maybe it's time to start working together. The CS types have made a lot of progress in software engineering during the last decades, and scientists are about the only ones who seem to be determined to ignore that. -- ------------------------------------------------------------------------------- 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 ------------------------------------------------------------------------------- From gmercier@mail.med.upenn.edu Fri Jul 11 10:11:33 1997 Received: from mail.med.upenn.edu for gmercier@mail.med.upenn.edu by www.ccl.net (8.8.3/950822.1) id JAA07300; Fri, 11 Jul 1997 09:58:35 -0400 (EDT) Received: (from gmercier@localhost) by mail.med.upenn.edu (8.8.5/8.8.5) id JAA23909 for CHEMISTRY@www.ccl.net; Fri, 11 Jul 1997 09:58:36 -0400 (EDT) From: "Gustavo A. Mercier Jr" Message-Id: <199707111358.JAA23909@mail.med.upenn.edu> Subject: Object Oriented Programming To: CHEMISTRY@www.ccl.net Date: Fri, 11 Jul 1997 09:58:35 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23-upenn3.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi! I **strongly** recommend the following book for those interested in numerical applications and OO programming, particularly if you come from the Fortran school. It lacks info on I/O stuff, but it goes heavily on the differences/benefits/tradeoffs between Fortran and OO as implemented under C++. It is also a very practical book, no philosophical discussions here. Scientific C++ Building Numerical Libraries the Object-Oriented Way Guido Buzzi-Ferraris Addison-Wesley 1993 One key point to understand is that there are different ways to implement an array in C/C++. Amazingly, the book shows how the approach used in the famous Numerical Recipes books is not the most efficient, particularly for OO programming! The book does not cover templates, part of the ANSI C++ standard. There is another book written by some IBM people that is also intended for the Fortran crowd. It is also very good, and does cover templates. It uses finite difference methods to illustrate the principles of an object. Unfortunately, I don't have the reference now! Contact me if you are interested. As a final note... I started with fortran, and moved on to Mathematica, then C, and now C++. I still write some code in Fortran, simply because some I/O stuff is easier to implement in Fortran. This reflects the fact that the output is going into a program written in Fortran that may be unforgiving regarding the format of the input. To move away from the procedural paradigm of programming was not easy. Even Wolfram states this in the handbook to Mathematica. Mathematica promotes a functional programming paradigm, although it is easy to write code using procedural programming, and with some effort OO programming. In retrospect, it was a great way to move from Fortran to C++. I must have read several books on programming, including a whole book on just the concept of OO programming with no reference to a specific programming language. I am still learning. Has the change being worth while? Only time will tell! :-) Not much experience, yet. Sorry! But, OO is the closest I can get to a fast program that allows me to keep the "thinking" I use with Mathematica. Unfortunately, unless I use a predefined class library, I have to write everything from scratch, a real pain. Moreover, a good knowledge of data structures is key if you intend to take advantage of OO programming. As KH states, I think Python is a great alternative, but I am only now learning about it... Still searching for a "nice" programming paradigm and its associated language. OO (with C++ or Python?) is getting there... Read Buzzi-Ferraris book and judge for yourself! Bye! -- ("`-/")_.-'"``-._ Gustavo A. Mercier,Jr.,MD,PhD (. . `) -._ )-;-,_() Division of Nuclear Medicine (v_,)' _ )`-.\ ``- Dept. of Radiology _;- _,-_/ / ((,' University of Pennsylvania ((,.-' ((,/ 3400 Spruce St. gmercier@mail.med.upenn.edu Philadelphia, PA 19104 215-662-3069/3091 fax: 215-349-5843 From c867buc@semovm.semo.edu Fri Jul 11 11:06:27 1997 Received: from SEMOVM.SEMO.EDU for c867buc@semovm.semo.edu by www.ccl.net (8.8.3/950822.1) id KAA07482; Fri, 11 Jul 1997 10:20:27 -0400 (EDT) Message-Id: <199707111420.KAA07482@www.ccl.net> Received: from duben.st.semo.edu by SEMOVM.SEMO.EDU (IBM VM SMTP V2R3) with TCP; Fri, 11 Jul 97 09:17:32 CDT X-Sender: c867buc@semovm.semo.edu X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 11 Jul 1997 09:06:45 -0500 To: chemistry@www.ccl.net From: c867buc@semovm.semo.edu (Anthony J. Duben) Subject: Re: CCL:Object-oriented means for computational chemistry programming RE: C/C++ vs. FORTRAN IMHO there is another alternative -- Ada. It is designed for writing solid software engineering applications, lacks the arcana of C/C++, and has versions available for most systems. Tony Duben (c867buc@semovm.semo.edu) ****************************************************** Anthony J. Duben Associate Dean, College of Science and Technology Mail Stop 6000 Southeast Missouri State University 1 University Plaza Cape Girardeau MO 63701-4799 phone: 573-986-6036 fax: 573-651-2223 e-mail: c867buc@semovm.semo.edu "Science is a wonderful thing if one does not have to earn a living at it." - Albert Einstein ***************************************************** From newhoir@mail.auburn.edu Fri Jul 11 11:11:07 1997 Received: from mallard.duc.auburn.edu for newhoir@mail.auburn.edu by www.ccl.net (8.8.3/950822.1) id KAA07670; Fri, 11 Jul 1997 10:44:31 -0400 (EDT) Received: from localhost by mallard.duc.auburn.edu (SMI-8.6/SMI-SVR4) id JAA15962; Fri, 11 Jul 1997 09:44:26 -0500 Date: Fri, 11 Jul 1997 09:44:26 -0500 (CDT) From: Irene Newhouse X-Sender: newhoir@mallard To: CHEMISTRY@www.ccl.net Subject: still FORTRAN? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII There ARE reasons why FORTRAN is still used by scientists. Of course there's the legacy code argument -- people who don't have time to reinvent the wheel continue to use stable, well-developed subroutines for parts of their code. 2nd, you cannot confuse aesthetic structure with efficently executing code!!!! I work in a user services environment where we help people optimize codes. Spaghetti code is ugly, but it executes. Every subroutine call adds overhead, and we've seen some gorgeous OOP stuff that runs like molasses in January, dragged down by all the overhead... FORTRAN has a decades' long head start in compiler opt. that's going to be hard to overcome in languages that weren't originally designed to do math. [Think about it: FORTRAN = FORmula TRANslation. In C, you have to include math.h because arithmetic operations weren't part of the original concept - writing unix was]. Until these purely PRACTICAL considerations even out, scientists who use computers as a TOOL will continue to do what works best & easiest. Irene Newhouse From berriz@chasma.harvard.edu Fri Jul 11 11:14:21 1997 Received: from chasma.harvard.edu for berriz@chasma.harvard.edu by www.ccl.net (8.8.3/950822.1) id KAA07599; Fri, 11 Jul 1997 10:39:29 -0400 (EDT) Received: by chasma.harvard.edu (AIX 3.2/UCB 5.64/4.03) id AA24246; Fri, 11 Jul 1997 10:40:17 -0400 Date: Fri, 11 Jul 1997 10:40:17 -0400 From: berriz@chasma.harvard.edu (Gabriel Berriz) Message-Id: <9707111440.AA24246@chasma.harvard.edu> To: chemistry@www.ccl.net In-Reply-To: <199707111025.MAA21755@lmspc1.ibs.fr> (message from Konrad Hinsen on Fri, 11 Jul 1997 12:25:14 +0200) Subject: Re: CCL:Object-oriented means for computational chemistry programming Date: Fri, 11 Jul 1997 12:25:14 +0200 From: Konrad Hinsen The bottom line: no single language is perfect. I think scientists should get used to the idea of mixed-language programming. This sounds great in theory, but I think it is hard to put into practice. The reason is that, while anyone can easily find pretty authoritative reference manuals on, say, ANSI C or Fortran90, it is much harder to find good documentation for mixed-language programming. (And coding with incomplete or inaccurate information will almost certainly fail to yield faster programs.) Or have I just had bad luck? Moreover, I suspect that to make the mixed-language idea pay-off, one would really have to learn a great deal about the processor-dependent nitty-gritty of numerical computation, information that is even more difficult to come by even than that for mixed-language programming. As things stand, computational chemists face the unpleasant choice between writing relatively slow code in their favorite language, or devoting a huge amount of time and effort to mastering the computational arcana of the various, rapidly mutating platforms they work with, material that is totally unrelated to their science. As you said, most scientists are not professional programmers, and they are naturally more interested in their science, so they will settle for the slower code. Besides, as one colleague of mine puts it, is it really worth it to spend about half one's time keeping one's skills as a computational ace well honed, and writing more complicated, but highly optimized code, so that one's programs run at most twice, more likely 110%, as fast? Probably not. Ultimately, most folks are more concerned with optimizing their time use than the computer's :-) . Regarding C++, and independent of its flaws and virtues, judging by the ratio (about 9:1) of C++ books to C books at my local bookstore, I expect C++ will displace C as the "standard" programming language in a few years (if it hasn't already). Sad but true. G. Berriz berriz@chasma.harvard.edu From Gerald.Loeffler@univie.ac.at Fri Jul 11 12:06:28 1997 Received: from mailbox.univie.ac.at for Gerald.Loeffler@univie.ac.at by www.ccl.net (8.8.3/950822.1) id LAA08074; Fri, 11 Jul 1997 11:42:29 -0400 (EDT) Received: from gerilap.imp.univie.ac.at (gerilap.imp.univie.ac.at [131.130.80.125]) by mailbox.univie.ac.at (8.8.4/8.8.4) with SMTP id RAA11632; Fri, 11 Jul 1997 17:42:21 +0200 Message-ID: <33C6534E.63D6@univie.ac.at> Date: Fri, 11 Jul 1997 17:37:50 +0200 From: Gerald Loeffler Reply-To: Gerald.Loeffler@univie.ac.at Organization: I.M.P. X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: "Gustavo A. Mercier Jr" CC: CHEMISTRY@www.ccl.net Subject: Re: CCL:Object Oriented Programming References: <199707111358.JAA23909@mail.med.upenn.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi! Just a remark since someone recommended two books: Gustavo A. Mercier Jr wrote: ... > I **strongly** recommend the following book for those interested > in numerical applications and OO programming, particularly > if you come from the Fortran school. It lacks info on I/O stuff, > but it goes heavily on the differences/benefits/tradeoffs > between Fortran and OO as implemented under C++. It is also > a very practical book, no philosophical discussions here. > > Scientific C++ > Building Numerical Libraries the Object-Oriented Way > Guido Buzzi-Ferraris > Addison-Wesley 1993 I bought and read this book and in my humble opinion it is extremely out-dated, misleading, badly written and simply serves the purpose of teaching OO-programming to a scientific community not well! I can not recommend it to anyone, actually. Somehow its strange how two peoples perception of one and the same item can vary... ... > The book does not cover templates, part of the ANSI C++ > standard. There is another book written by some IBM people > that is also intended for the Fortran crowd. It is also very good, > and does cover templates. It uses finite difference methods to > illustrate the principles of an object. Unfortunately, > I don't have the reference now! Contact me if you are interested. Thats Scientific and Engineering C++ : An Introduction With Advanced Techniques and Examples by John J. Barton, Lee R. Nackman Hardcover, 671 pages Published by Addison-Wesley Pub Co Publication date: July 1, 1994 This on the other hand is a very thoroughly written text on C++ as it will more or less emerge from the standardization effort (note: there is no ANSI C++ standard yet!). Furthermore, Lee and Nackman have a regular column in the "C++ report", and definitely know what they are writing about. It's also rather old by now and some details mentioned therein are not strictly speaking C++ any more, but this should be no argument against buying this book. ... -- Gerald Loeffler PostDoc in Theoretical Biophysics EMail: Gerald.Loeffler@univie.ac.at Phone: +43 1 79730 554 Fax: +43 1 7987153 SMail: I.M.P. - Research Institute of Molecular Pathology Dr. Bohr-Gasse 7 A-1030 Vienna AUSTRIA From kotelyan@plmsc.psu.edu Fri Jul 11 12:11:42 1997 Received: from plmsc.psu.edu for kotelyan@plmsc.psu.edu by www.ccl.net (8.8.3/950822.1) id LAA07978; Fri, 11 Jul 1997 11:18:19 -0400 (EDT) Received: (from kotelyan@localhost) by plmsc.psu.edu (8.8.2/8.8.2) id LAA20403; Fri, 11 Jul 1997 11:18:13 -0400 (EDT) Date: Fri, 11 Jul 1997 11:18:09 -0400 (EDT) From: Mike Kotelyanskii To: "W. R. Smith" cc: chemistry-request@www.ccl.net, Konrad Hinsen , serge@qsar.chem.msu.su, chemistry@www.ccl.net Subject: Re: CCL:Object-oriented means for computational chemistry programming In-Reply-To: <3.0.16.19970710190111.2a5fcde4@mathtrek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Well, there is a difference. If you ever saw a description of Pascal with OOP or C++ you would have noticed, that object is hot just a subroutine. It is a way to encapsulate data AND functions together. It is very useful for code development for large projects. If the set of objects is wisely designed it would take a minimal amount of work to introduce changes. But, of course whatever can be done with OOP can also be done without it. It just a matter of programming style and discipline. OOP sort of does it for you. And I think performance is what you pay for it. Mike ------------------------------------------------------------------------------- Michael J. Kotelyanskii Phone (814) 863 43 81 Polymer Science Program FAX (814) 865 29 17 Department of Materials Science and Engineering kotelyan@plmsc.psu.edu Pennsylvania State University University Park, PA 16802, USA -------------------------------------------------------------------------------- On Thu, 10 Jul 1997, W. R. Smith wrote: > Hello, > > Who says FORTRAN cannot be "object-oriented"? How about Windows > FORTRAN .DLL's, or other types of FORTRAN libraries? Please enlighten me > if I'm off-base, but it seems to me that the entire "object-oriented thing" > is simply a modern version of what we used to call a "subroutine" in > FORTRAN. The only difference is that one must adopt an accepted convention > to define the ways in which the "object" \equiv "subroutine" communicates > with the outside world. > > > > At 11:10 AM 7/10/97 +0200, Konrad Hinsen wrote: > >> FORTRAN still remains the main programming language of computational > >> chemistry. But > >> I wonder if anybody knew about the programs where methods computational > >> chemistry and, in particular quantum mechanical (ab initio or > >> semiempirical), MM or QM/MM force field methods are developed by means of > >> object-oriented languages (C++ preferably). I know Hyperchem is announced > > > > -- W. R. Smith, PhD, P. Eng., Senior Scientist, Mathtrek Systems -- > 3-304 Stone Road West, Suite 165, Guelph, Ontario CANADA N1G 4W4 > EMail: support@mathtrek.com Tel:519-763-1356,FAX:519-763-4525 > --------------------- http://www.mathtrek.com --------------------- > -Mathtrek Systems - Home of EQS4WIN Chemical Equilibrium Software - > > > -------This is added Automatically by the Software-------- > -- Original Sender Envelope Address: support@mathtrek.com > -- Original Sender From: Address: support@mathtrek.com > CHEMISTRY@www.ccl.net: Everybody | CHEMISTRY-REQUEST@www.ccl.net: Coordinator > MAILSERV@www.ccl.net: HELP CHEMISTRY or HELP SEARCH | Gopher: www.ccl.net 73 > Anon. ftp: www.ccl.net | CHEMISTRY-SEARCH@www.ccl.net -- archive search > Web: http://www.ccl.net/chemistry.html > > From gmercier@mail.med.upenn.edu Fri Jul 11 14:06:27 1997 Received: from mail.med.upenn.edu for gmercier@mail.med.upenn.edu by www.ccl.net (8.8.3/950822.1) id NAA08689; Fri, 11 Jul 1997 13:15:15 -0400 (EDT) Received: (from gmercier@localhost) by mail.med.upenn.edu (8.8.5/8.8.5) id NAA04294 for chemistry@www.ccl.net; Fri, 11 Jul 1997 13:15:15 -0400 (EDT) From: "Gustavo A. Mercier Jr" Message-Id: <199707111715.NAA04294@mail.med.upenn.edu> Subject: PDBLib++ under Linux? To: chemistry@www.ccl.net Date: Fri, 11 Jul 1997 13:15:15 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23-upenn3.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi! I am trying to compile the OO library PDBLib++. The makefile is targeted to SGI and Sun machines. Before I rediscover the wheel, has anybody generated a makefile for Linux/Intel systems? Thanks! -- ("`-/")_.-'"``-._ Gustavo A. Mercier,Jr.,MD,PhD (. . `) -._ )-;-,_() Division of Nuclear Medicine (v_,)' _ )`-.\ ``- Dept. of Radiology _;- _,-_/ / ((,' University of Pennsylvania ((,.-' ((,/ 3400 Spruce St. gmercier@mail.med.upenn.edu Philadelphia, PA 19104 215-662-3069/3091 fax: 215-349-5843 From berriz@chasma.harvard.edu Fri Jul 11 14:29:14 1997 Received: from chasma.harvard.edu for berriz@chasma.harvard.edu by www.ccl.net (8.8.3/950822.1) id NAA08950; Fri, 11 Jul 1997 13:39:52 -0400 (EDT) Received: by chasma.harvard.edu (AIX 3.2/UCB 5.64/4.03) id AA24290; Fri, 11 Jul 1997 13:40:45 -0400 Date: Fri, 11 Jul 1997 13:40:45 -0400 From: berriz@chasma.harvard.edu (Gabriel Berriz) Message-Id: <9707111740.AA24290@chasma.harvard.edu> To: chemistry@www.ccl.net In-Reply-To: <199707111713.NAA27510@tarkovsky.npac.syr.edu> (bernhold@npac.syr.edu) Subject: Re: CCL:Object-oriented means for computational chemistry programming Date: Fri, 11 Jul 1997 13:13:25 -0400 From: "David E. Bernholdt" It is true that interlanguage programming is not standardized (yet), but as a practical matter, on a given platform you can expect that ^^^^^^^^^^^^^^^^^^^ most languages (from the same vendor at least) will follow a similar underlying structure and _will_ be able to interface... The platform-dependance is already a hindrance, I think. I already have to write for 4 different platforms; it's bad enough as it is even staying within a well-standardized language such as ANSI C. Some things, like mixed Fortran77 and C, are now so common that there is a community of people out there who understand pretty well how to do this and even some packages/templates to help you do it in a platform-independent way. If you seek out such people, you can probably find them without too much trouble. Are you offering your services? :-) Perhaps it's not as bad as it looks from my end, but if I had to rely on the kindness of unpaid experts for every question that I now handle with my reference manuals, I would be dealing with some pretty annoyed experts... I can't recall a case where I had to know more about the "processor-dependent nitty-gritty of numerical computation" to do mixed-language programming than I needed to do a good job of scientific programming in one language -- the interfaces are rarely so fine-grained as that. I didn't express myself clearly. What I was trying to say is that, once one decides to worry about speed optimization, one has to worry about machine architecture. It is my understanding that without knowing the architecture-dependent details of how the processor will move data around, one can easily end up with rather inefficient code, regardless of which language it is written in. Gabriel Berriz berriz@chasma.harvard.edu From bobg@chaos.cc.uic.edu Fri Jul 11 16:06:31 1997 Received: from chaos.cc.uic.edu for bobg@chaos.cc.uic.edu by www.ccl.net (8.8.3/950822.1) id PAA09791; Fri, 11 Jul 1997 15:15:18 -0400 (EDT) Message-Id: <199707111915.PAA09791@www.ccl.net> Received: by chaos.cc.uic.edu (1.39.111.2/16.2) id AA197728250; Fri, 11 Jul 1997 14:10:50 -0500 To: chemistry@www.ccl.net From: "Bob Goldstein" Subject: Re: CCL:Object-oriented means for computational chemistry programming In-Reply-To: Your message of "Fri, 11 Jul 1997 13:40:45 CDT." <9707111740.AA24290@chasma.harvard.edu> Date: Fri, 11 Jul 1997 14:10:50 -0500 Sender: bobg@chaos.cc.uic.edu > > Some things, like mixed Fortran77 and C, are now so common that there > is a community of people out there who understand pretty well how to > >Are you offering your services? :-) Perhaps it's not as bad as it >looks from my end, but if I had to rely on the kindness of unpaid [...snip ...] Hmm. How about mixed tcl/C ? The tcl interpreter is done in C, so rebuilding the interpreter is not mixed-language. But the result would be -- use tcl (slow as molasses, but lots of high level constructs like hashes, regular expressions, flow control) for the putting-together-the-tools part, and let C (or fortran) do the heavy lifting. Someone could provide a toolkit of tcl commands written in C, and anyone could put the tools together in new ways using a highlevel scripting language. I think perl and python would also work as scripting languages here. This is not just object-oriented (for the programmer) but also somewhat component-oriented (for the application builder or end user). bobg From kotelyan@plmsc.psu.edu Fri Jul 11 21:06:30 1997 Received: from plmsc.psu.edu for kotelyan@plmsc.psu.edu by www.ccl.net (8.8.3/950822.1) id UAA10706; Fri, 11 Jul 1997 20:19:25 -0400 (EDT) Received: (from kotelyan@localhost) by plmsc.psu.edu (8.8.2/8.8.2) id UAA21275; Fri, 11 Jul 1997 20:19:23 -0400 (EDT) Date: Fri, 11 Jul 1997 20:19:22 -0400 (EDT) From: Mike Kotelyanskii To: Bob Goldstein cc: chemistry@www.ccl.net Subject: Re: CCL:Object-oriented means for computational chemistry programming In-Reply-To: <199707111915.PAA09791@www.ccl.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII That's actually what Biosym has been doing for last couple of years. Their script language was actually Tcl (if I am not mistaken...) MikeK ------------------------------------------------------------------------------- Michael J. Kotelyanskii Phone (814) 863 43 81 Polymer Science Program FAX (814) 865 29 17 Department of Materials Science and Engineering kotelyan@plmsc.psu.edu Pennsylvania State University University Park, PA 16802, USA -------------------------------------------------------------------------------- On Fri, 11 Jul 1997, Bob Goldstein wrote: > > > > Some things, like mixed Fortran77 and C, are now so common that there > > is a community of people out there who understand pretty well how to > > > >Are you offering your services? :-) Perhaps it's not as bad as it > >looks from my end, but if I had to rely on the kindness of unpaid > [...snip ...] > > Hmm. How about mixed tcl/C ? The tcl interpreter is done in C, > so rebuilding the interpreter is not mixed-language. But the > result would be -- use tcl (slow as molasses, but lots of > high level constructs like hashes, regular expressions, flow > control) for the putting-together-the-tools part, and let > C (or fortran) do the heavy lifting. > > Someone could provide a toolkit of tcl commands written in C, > and anyone could put the tools together in new ways using > a highlevel scripting language. I think perl and python > would also work as scripting languages here. This is > not just object-oriented (for the programmer) but also > somewhat component-oriented (for the application builder or > end user). > > bobg > > -------This is added Automatically by the Software-------- > -- Original Sender Envelope Address: bobg@chaos.cc.uic.edu > -- Original Sender From: Address: bobg@uic.edu > CHEMISTRY@www.ccl.net: Everybody | CHEMISTRY-REQUEST@www.ccl.net: Coordinator > MAILSERV@www.ccl.net: HELP CHEMISTRY or HELP SEARCH | Gopher: www.ccl.net 73 > Anon. ftp: www.ccl.net | CHEMISTRY-SEARCH@www.ccl.net -- archive search > Web: http://www.ccl.net/chemistry.html > >