From dmit@nmr1.ioc.ac.ru Mon Nov 28 06:15:29 1994 Received: from nmr1.ioc.ac.ru for dmit@nmr1.ioc.ac.ru by www.ccl.net (8.6.9/930601.1506) id FAA14553; Mon, 28 Nov 1994 05:41:38 -0500 Received: from [193.124.3.49] by nmr1.ioc.ac.ru with SMTP (WG7Jv1.07b+CWRU/BIOCv1.93) id AA528 ; Mon, 28 Nov 94 13:41:32 MST Date: Mon, 28 Nov 94 13:40:06 +0300 From: "Dmitry E. Dmitriev" Message-Id: <61476.dmit@nmr1.ioc.ac.ru> X-Minuet-Version: Minuet1.0_Beta_15 Reply-To: X-POPMail-Charset: IBM 8-Bit To: chemistry@ccl.net Subject: Isomerisation N=N bond Dear Colleagues; If anyone has any references to journal articles describe experimental and/or calculated data about the configuration of a -N=N- azo- double bond and it potential barrier of isomerication (rotation, inversion etc.) I very interested also to receive ones about related mechanisms. Thanks to all responders in advance. Dmitry. ============================================================================ Dmitry E. Dmitriev, ** E-mail: dmit@nmr1.ioc.ac.ru NMR Centre ** ***************** N.D. Zelinsky Inst. of Org. Chem., ** tel : 7 (095) 135 90 94 Russian Academy of Sciences ** fax : 7 (095) 135 53 28 ============================================================================ From lrbu00@xd88.kodak.com Mon Nov 28 10:17:36 1994 Received: from Kodak.COM for lrbu00@xd88.kodak.com by www.ccl.net (8.6.9/930601.1506) id JAA17306; Mon, 28 Nov 1994 09:24:05 -0500 From: Received: from euler.kodak.com by Kodak.COM (5.61+/2.1-Eastman Kodak) id AA28953; Mon, 28 Nov 94 09:24:02 -0500 Reply-To: lrbu00@xd88.kodak.com Received: from xd88.kodak.com by euler.kodak.com via SMTP (931110.SGI/931108.SGI.ANONFTP) for @kodakr.Kodak.COM:chemistry@ccl.net id AA28778; Mon, 28 Nov 94 09:19:24 -0500 Received: by xd88.kodak.com (AIX 3.2/UCB 5.64/4.03) id AA12913; Mon, 28 Nov 1994 09:11:04 -0500 Date: Mon, 28 Nov 1994 09:11:04 -0500 Message-Id: <9411280911.ZM18543@xd88.kodak.com> X-Mailer: Z-Mail (3.0.0 15dec93) To: chemistry@ccl.net Subject: PENTIUM FIX(?) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 IN THE LOCAL NEWSPAPER LAST WEEK AN ARTICLE POINTED OUT THAT THERE WERE 2,000,000 PENTIUM CHIPS THAT ARE BUGGY. THE ARTICLE POINTS OUT THAT MathWorks OF NATICK, MASS. WILL RELEASE A "FIX" TODAY. DOES ANYBODY KNOW ABOUT IT? CLEVE MOLER(OF MATHwORKS), ARE YOU LISTENING? INTERUPTION...PHONE CALL FROM INTEL...THE LOCAL OFFICE HERE IN ROCHESTER IS AWARE THAT INTENSIVE USERS ARE MUCH MORE LIKELY TO HAVE A PROBLEM, THOUGH THEY CLAIM OF STILL SMALL PROBABILITY. THEY ARE SERIOUS ABOUT CORRECTING THE PROBLEM FOR THOSE WHO INSIST....NO FLAMES TO ME PLEASE. INTEL:1-800-628-8686. REGARDS..... -- John M. McKelvey email: mckelvey@Kodak.COM Computational Science Laboratory phone: (716) 477-3335 2nd Floor, Bldg 83, RL Eastman Kodak Company Rochester, NY 14650-2216 -- From cieplak@tiger.chem.uw.edu.pl Mon Nov 28 12:15:33 1994 Received: from tiger.chem.uw.edu.pl for cieplak@tiger.chem.uw.edu.pl by www.ccl.net (8.6.9/930601.1506) id LAA20445; Mon, 28 Nov 1994 11:59:18 -0500 Received: by tiger.chem.uw.edu.pl (AIX 3.2/UCB 5.64/4.03) id AA16459; Mon, 28 Nov 1994 17:42:13 +0100 Date: Mon, 28 Nov 1994 17:42:13 +0100 From: cieplak@tiger.chem.uw.edu.pl (Piotr Cieplak) Message-Id: <9411281642.AA16459@tiger.chem.uw.edu.pl> To: chemistry@ccl.net Subject: am1 parameters for Au, Ag, Rd etc Dear Netters I am looking for the AM1 parameters for metals like: Au, Ag, Rd etc? I would appreciate any answer to cieplak@chem.uw.edu.pl, since I am not a member of this list. Best regards to everybody Piotr Cieplak From R29CLOSE@ETSU.EAST-TENN-ST.EDU Mon Nov 28 13:15:34 1994 Received: from phem3 for R29CLOSE@ETSU.EAST-TENN-ST.EDU by www.ccl.net (8.6.9/930601.1506) id MAA21425; Mon, 28 Nov 1994 12:39:45 -0500 Received: from ETSU.EAST-TENN-ST.EDU (MAILER@ETSU) by phem3.acs.ohio-state.edu (PMDF V4.2-13 #5888) id <01HK0HDISJUO94DSLG@phem3.acs.ohio-state.edu>; Mon, 28 Nov 1994 12:39:40 EDT Received: from ETSU.EAST-TENN-ST.EDU (NJE origin R29CLOSE@ETSU) by ETSU.EAST-TENN-ST.EDU (LMail V1.2a/1.8a) with BSMTP id 5455; Mon, 28 Nov 1994 12:39:06 -0500 Date: Mon, 28 Nov 1994 12:35:13 -0500 (EST) From: David Close Subject: Pentium Problems?? To: chemistry@ccl.net Message-id: <01HK0HDISJUQ94DSLG@phem3.acs.ohio-state.edu> Organization: East Tennessee State University Content-transfer-encoding: 7BIT Dear Netters: I have seen several notes here on the Pentium problem which now has hit the newspapers. I am wondering just what the specific problems could be in using standard programs. For example, does this error under discussion pose any problems for people trying to use AMPAC/MOPAC on a Pentium running DOS? Regards, Dave Close From cletner@remcure.bmb.wright.edu Mon Nov 28 13:17:01 1994 Received: from remcure.bmb.wright.edu for cletner@remcure.bmb.wright.edu by www.ccl.net (8.6.9/930601.1506) id MAA21394; Mon, 28 Nov 1994 12:37:29 -0500 Received: by remcure.bmb.wright.edu (931110.SGI/921111.SGI.AUTO) for CHEMISTRY@ccl.net id AA05254; Mon, 28 Nov 94 12:28:27 -0800 Date: Mon, 28 Nov 1994 11:03:00 -0800 (PST) From: Charles Letner Subject: PENTIUM FIX(?) and Intel response To: Computational Chemistry List In-Reply-To: <9411280911.ZM18543@xd88.kodak.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello all, For those who are following this "story" I was able to verify the problem using the windows calculator (as was mentioned by another user last week). It is a easy check... On Mon, 28 Nov 1994 lrbu00@xd88.kodak.com wrote: > INTERUPTION...PHONE CALL FROM INTEL...THE LOCAL OFFICE HERE IN ROCHESTER IS > AWARE THAT INTENSIVE USERS ARE MUCH MORE LIKELY TO HAVE A PROBLEM, THOUGH THEY > CLAIM OF STILL SMALL PROBABILITY. THEY ARE SERIOUS ABOUT CORRECTING THE > PROBLEM > FOR THOSE WHO INSIST....NO FLAMES TO ME PLEASE. INTEL:1-800-628-8686. I tried Intel tech support this morning. They do not sound very interested in correcting the problem to me. 8v( Basically the response was let me send you a fax. We can talk more if you actually run a application and have the problem. Interesting that they will decide if they think you have a problem. I felt like they where "blowing me off". You can make what you want of the fax. I've included a copy of the fax below so you can draw your own conclusions. Best regards, Chuck Charles Letner Wright State University Department of Biochemistry Dayton, OH 45435 e-mail: cletner@remcure.bmb.wright.edu FAX from intel corperation from 11/28/94 (scanned in and converted to text some errors in actual characters may be present. I found most of them I think. -------------------------------------------------------------------- INTEL INFORMATION ON THE SUBTLE FLAW OF THE FLOATING POINT UNIT OF THE PENTIUM(TM) PROCESSOR There has been a lot of communication recently on the Internet about a floating point flaw on the Pentium(TM) processor. For almost all users, this is not a problem. Here are the facts. Intel detected a subtle flaw in the precision of the divide operation for the Pentium Processor. For rare cases (one in nine billion possible divides), the precision of the result is reduced. Intel discovered this subtle flaw during ongoing testing -- after several trillions of floating point operations in our continuing testing of the Pentium processor. Intel immediately tested the most stringent technical applications that use the floating point unit over the course of months and we have been unable to detect any error. In fact, after extensive testing and shipping millions of Pentium processor-based systems, there has only been one reported instance of this flaw affecting a user, to our knowledge. In this case, a mathematician doing theoretical analysis of prime numbers and reciprocals saw reduced precision at the 9th place to the right of the decimal. In fact, extensive engineering tests demonstrated that an average spreadsheet user could encounter this subtle flaw of reduced precision once in every 27,000 years of use. Based on these empirical observations and our extensive testing, the user of standard off-the-shelf software will not be impacted. If you do this kind of prime numbers generation or other complex mathematics, call 1-800-628-8686 (International 916-356-3551). If you don't, you won't encounter any problems with your Pentium processor-based system. If ever in the life of the computer this becomes a problem, Intel will work with the customer to resolve the issue From zdenko@harvey.cam.rice.edu Mon Nov 28 14:15:39 1994 Received: from moe.rice.edu for zdenko@harvey.cam.rice.edu by www.ccl.net (8.6.9/930601.1506) id OAA22968; Mon, 28 Nov 1994 14:03:31 -0500 Received: from harvey.cam.rice.edu by moe.rice.edu (AA26515); Mon, 28 Nov 94 13:03:20 CST Received: by harvey.cam.rice.edu (AA04917); Mon, 28 Nov 94 13:03:17 CST Date: Mon, 28 Nov 94 13:03:17 CST From: zdenko@harvey.cam.rice.edu (Zdenko Tomasic) Message-Id: <9411281903.AA04917@harvey.cam.rice.edu> To: lrbu00@xd88.kodak.com Cc: chemistry@ccl.net In-Reply-To: 's message of Mon, 28 Nov 1994 09:11:04 -0500 <9411280911.ZM18543@xd88.kodak.com> Subject: CCL:PENTIUM FIX(?) I doubt that Cleve reads this list, but he has offerred a software workaround (actually improvement) which however is cannot recover full IEEE complience (error in no more than 1 ulp). Here is his message from netnews (read comp.sys.intel for more): From rice!news.sesqui.net!darwin.sura.net!rsg1.er.usgs.gov!ukma!news-feed-1.peachnet.edu!usenet.eel.ufl.edu!news.mathworks.com!not-for-mail Sun Nov 27 00:30:43 1994 Path: rice!news.sesqui.net!darwin.sura.net!rsg1.er.usgs.gov!ukma!news-feed-1.peachnet.edu!usenet.eel.ufl.edu!news.mathworks.com!not-for-mail From: moler@mathworks.com (Cleve Moler) Newsgroups: comp.sys.intel Subject: Hard/software Workaround for the FDIV Bug Date: 24 Nov 1994 14:34:03 -0500 Organization: The MathWorks, Inc., Natick, MA 01760 Lines: 99 Message-ID: <3b2prb$13q@acoma.mathworks.com> NNTP-Posting-Host: acoma.mathworks.com Summary: Software uses Pentium to correct itself. Keywords: Pentium,FDIV,MATLAB SOFTWARE/HARDWARE WORKAROUND FOR THE FDIV BUG At the MathWorks, we have decided to issue a new release of MATLAB which is "Pentium aware". It incorporates a workaround for the floating point division bug which restores full accuracy without a serious degradation of efficiency. And, we have decided to post a description of our technique to the Internet so that other people, including other commercial software developers, can make use of it. It is not easy to modify a large package like MATLAB to include this change. We would much prefer to have the compiler or the operating system do the job for us, but this is not yet an option. The kernel of MATLAB is written in C. We have replaced several dozen instances of a '/' denoting a floating point division by a function call. We are now in the process of confirming that we didn't introduce any source code errors while doing this. Our initial intention was to use the Pentium hardware FDIV instruction to compute a candidate quotient, check its accuracy, and then, if necessary, employ a standard Newton iterative refinement technique to eliminate any inaccuracy produced by the hardware. But then we realized that an approach unique to this situation was possible, and more effective. The FDIV instruction can be used to correct itself! Here's the code: #include #define EPS 2.2204460492503131e-16 #define REALMIN 2.2250738585072014e-308 #define RHO 0.75 double fdiv(double x, double y) { int ok; double r,z; z = x/y; r = x - y*z; while (fabs(r) > EPS*fabs(x)+REALMIN) { x = RHO*x; y = RHO*y; z = x/y; r = x - y*z; } return(z); } The idea is to use the hardware to divide x by y and produce the candidate quotient, z. This will be correct in the vast majority of cases, but it is necessary to check. The test uses the residual, r = x - y*z. Normally, r will be no larger than roundoff error in x. The constant EPS involved in the test is the distance from 1.0 to the next larger floating point number. For double precision, EPS is 2^(-52). At first, we forgot to include the constant REALMIN in the test, but this term is required to deal correctly with denormal floating point numbers. If the residual fails the test, it indicates that the hardware bug has been encountered. When this occurs, we simply rescale the numerator and denominator by a factor of 3/4 and repeat the process. The scaling scrambles the bit patterns in x and y so that the second division almost certainly gives a satisfactory result. The factor 3/4 is important. It is the "simplest" factor which alters the bit patterns in the fractions of x and y. If the last bit in the fraction is zero, the scaling does not introduce any roundoff error. Furthermore, since 3/4 is less than 1, the scaling cannot overflow. And, if the operands are so small that scaling by 3/4 would underflow, the original division is done correctly and the scaling is not needed. How much does all this cost in execution speed? We have not yet done any serious timings outside the MATLAB context. Since the occurrence of the inaccurate results is so rare, any time spent inside the while loop can be ignored. The FDIV instruction itself takes 30 or more cycles. To this we must add the time for computing the residual, the time for doing the test and, perhaps the most significant, the time required by the function call. We guess that this might double the time, but the actual factor will depend upon the surrounding environment. If anybody actually does incorporate this approach in their software, we'd like to hear about it. In particular, we'd appreciate hearing about any timing measurements from other large packages. I will be posting an article to the comp.soft-sys.matlab newsgroup describing the Pentium aware MATLAB, and its availability, in more detail. Finally, although I have not yet met any of them in person, I would like acknowledge and thank Thomas Nicely, Tim Coe and Mike Carlton for their contributions to this enterprise. -- Cleve Moler Chairman and Chief Scientist The MathWorks, Inc. moler@mathworks.com From yinona@niva.tau.ac.il Mon Nov 28 15:22:23 1994 Received: from niva.tau.ac.il for yinona@niva.tau.ac.il by www.ccl.net (8.6.9/930601.1506) id PAA25244; Mon, 28 Nov 1994 15:22:23 -0500 Date: Mon, 28 Nov 1994 22:22:11 +0200 (IST) From: yinon ashkenasy Sender: yinon ashkenasy Reply-To: yinon ashkenasy Subject: Hard/software Workaround for the pentium bug To: chemistry@ccl.net Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Due to the latest interest in the Pentium bug in this group... ---------- Forwarded message ---------- Date: 24 Nov 1994 14:34:03 -0500 From: Cleve Moler Subject: Hard/software Workaround for the FDIV Bug SOFTWARE/HARDWARE WORKAROUND FOR THE FDIV BUG At the MathWorks, we have decided to issue a new release of MATLAB which is "Pentium aware". It incorporates a workaround for the floating point division bug which restores full accuracy without a serious degradation of efficiency. And, we have decided to post a description of our technique to the Internet so that other people, including other commercial software developers, can make use of it. It is not easy to modify a large package like MATLAB to include this change. We would much prefer to have the compiler or the operating system do the job for us, but this is not yet an option. The kernel of MATLAB is written in C. We have replaced several dozen instances of a '/' denoting a floating point division by a function call. We are now in the process of confirming that we didn't introduce any source code errors while doing this. Our initial intention was to use the Pentium hardware FDIV instruction to compute a candidate quotient, check its accuracy, and then, if necessary, employ a standard Newton iterative refinement technique to eliminate any inaccuracy produced by the hardware. But then we realized that an approach unique to this situation was possible, and more effective. The FDIV instruction can be used to correct itself! Here's the code: #include #define EPS 2.2204460492503131e-16 #define REALMIN 2.2250738585072014e-308 #define RHO 0.75 double fdiv(double x, double y) { int ok; double r,z; z = x/y; r = x - y*z; while (fabs(r) > EPS*fabs(x)+REALMIN) { x = RHO*x; y = RHO*y; z = x/y; r = x - y*z; } return(z); } The idea is to use the hardware to divide x by y and produce the candidate quotient, z. This will be correct in the vast majority of cases, but it is necessary to check. The test uses the residual, r = x - y*z. Normally, r will be no larger than roundoff error in x. The constant EPS involved in the test is the distance from 1.0 to the next larger floating point number. For double precision, EPS is 2^(-52). At first, we forgot to include the constant REALMIN in the test, but this term is required to deal correctly with denormal floating point numbers. If the residual fails the test, it indicates that the hardware bug has been encountered. When this occurs, we simply rescale the numerator and denominator by a factor of 3/4 and repeat the process. The scaling scrambles the bit patterns in x and y so that the second division almost certainly gives a satisfactory result. The factor 3/4 is important. It is the "simplest" factor which alters the bit patterns in the fractions of x and y. If the last bit in the fraction is zero, the scaling does not introduce any roundoff error. Furthermore, since 3/4 is less than 1, the scaling cannot overflow. And, if the operands are so small that scaling by 3/4 would underflow, the original division is done correctly and the scaling is not needed. How much does all this cost in execution speed? We have not yet done any serious timings outside the MATLAB context. Since the occurrence of the inaccurate results is so rare, any time spent inside the while loop can be ignored. The FDIV instruction itself takes 30 or more cycles. To this we must add the time for computing the residual, the time for doing the test and, perhaps the most significant, the time required by the function call. We guess that this might double the time, but the actual factor will depend upon the surrounding environment. If anybody actually does incorporate this approach in their software, we'd like to hear about it. In particular, we'd appreciate hearing about any timing measurements from other large packages. I will be posting an article to the comp.soft-sys.matlab newsgroup describing the Pentium aware MATLAB, and its availability, in more detail. Finally, although I have not yet met any of them in person, I would like acknowledge and thank Thomas Nicely, Tim Coe and Mike Carlton for their contributions to this enterprise. -- Cleve Moler Chairman and Chief Scientist The MathWorks, Inc. moler@mathworks.com ---Administrivia: This message is automatically appended by the mail exploder: CHEMISTRY@ccl.net -- everyone | CHEMISTRY-REQUEST@ccl.net -- coordinator MAILSERV@ccl.net: HELP CHEMISTRY | Gopher: www.ccl.net 73 Anon. ftp www.ccl.net | CHEMISTRY-SEARCH@ccl.net -- archive search http://www.ccl.net/chemistry.html | for info send: HELP SEARCH to MAILSERV From behnam@iris134.biosym.com Mon Nov 28 16:15:39 1994 Received: from bioc1.biosym.com for behnam@iris134.biosym.com by www.ccl.net (8.6.9/930601.1506) id QAA26347; Mon, 28 Nov 1994 16:09:52 -0500 Received: from iris134.biosym.com by bioc1.biosym.com (5.64/0.0) id AA23320; Mon, 28 Nov 94 13:09:23 -0800 Received: by iris134.biosym.com (931110.SGI/930416.SGI) for @bioc1.biosym.com:CHEMISTRY@ccl.net id AA17806; Mon, 28 Nov 94 13:09:19 -0800 Date: Mon, 28 Nov 94 13:09:19 -0800 From: behnam@iris134.biosym.com (Behnam Vessal) Message-Id: <9411282109.AA17806@iris134.biosym.com> To: CHEMISTRY@ccl.net Subject: fortran compiler for pcs Hello everyone: I am looking for a fortran compiler for a 486 pc ( preferably window based ). Does anybody know of any ( shareware and or commercial ? ) Best Wishes Behnam From flbdsilv@fox.cce.usp.br Mon Nov 28 16:17:28 1994 Received: from bee.uspnet.usp.br for flbdsilv@fox.cce.usp.br by www.ccl.net (8.6.9/930601.1506) id PAA25218; Mon, 28 Nov 1994 15:20:50 -0500 Received: from fox.cce.usp.br (fox.cce.usp.br [143.107.70.1]) by bee.uspnet.usp.br (8.6.8.1/SPARC10-CCE2.0)id SAA03742 Received: from localhost (flbdsilv@localhost) by fox.cce.usp.br (8.6.4/CONVEX120-CCE2.0) id SAA12218 Date: Mon, 28 Nov 1994 18:14:41 -0300 (BST) From: Fernando Luis Barroso da Silva Subject: Experimental results - Ions and Solvent around polymers and biomolecules To: chemistry@ccl.net, bioforum@net.bio.net, biophysics@net.bio.net cc: Water Science Network Administrator Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear Netters, I am looking for some references about experimental results of ions and solvent ( water ) structure around polymers and biomolecules ( proteins ). Please, e-mail me direct. I'll summarize for the net ( Of course !!! ). Thanks in advance. Regards, Fernando ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Fernando Luis Barroso da Silva Departamento de Quimica e-mail: flbdsilv@fox.cce.usp.br Faculdade de Ciencias - Unesp Phone: +55(0142) 30-2111 - R. 134 17033-360 - Bauru - SP - BRASIL +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From adit@Kodak.COM Mon Nov 28 17:15:37 1994 Received: from Kodak.COM for adit@Kodak.COM by www.ccl.net (8.6.9/930601.1506) id QAA26569; Mon, 28 Nov 1994 16:17:56 -0500 Received: from bcc9.kodak.com by Kodak.COM (5.61+/2.1-Eastman Kodak) id AA13062; Mon, 28 Nov 94 16:18:10 -0500 Reply-To: adit@Kodak.COM Received: by bcc9.kodak.com (4.1/SMI-4.1) id AA23099; Mon, 28 Nov 94 16:11:56 EST Date: Mon, 28 Nov 94 16:11:56 EST From: adit@Kodak.COM (Adi Treasurywala) Message-Id: <9411282111.AA23099@bcc9.kodak.com> To: chemistry@ccl.net Subject: Please Note the change. Hi, Given the short time left, I can think of no quicker way to inform all of those folks who matter most to me of my change of address. Sorry for taking up the bandwidth. Old Address: adit@kodak.com New address: adit@extreme.chem.rpi.edu Thanks in advance for your understanding. Adi Treasurywala. From phys13@unix.york.ac.uk Mon Nov 28 18:15:36 1994 Received: from leeman.york.ac.uk for phys13@unix.york.ac.uk by www.ccl.net (8.6.9/930601.1506) id RAA27485; Mon, 28 Nov 1994 17:24:08 -0500 Received: from tower.york.ac.uk by leeman.york.ac.uk with SMTP (PP) id <07691-0@leeman.york.ac.uk>; Mon, 28 Nov 1994 22:18:54 +0000 Received: by tower.york.ac.uk (940715.SGI.52/931108.SGI.ANONFTP) for @leeman.york.ac.uk:CHEMISTRY@ccl.net id AA02145; Mon, 28 Nov 94 22:24:40 GMT Date: Mon, 28 Nov 1994 22:24:39 +0000 From: RJ Greenall X-Sender: phys13@tower.york.ac.uk To: CHEMISTRY@ccl.net Cc: RJ Greenall Subject: Demonstration software for 486 PC. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Is there any software (free or commercial) to graphically demonstrate MD simulation on a 486 PC which would impress school children and possibly persuade them to take up courses in molecular biophysics/computational chemistry ? Full MD facilities would be preferable, but packages that could impressively animate say, amber trajectories, would also be very useful. Thanks. From arthur@pchindigo2.IPC.PKU.EDU.CN Mon Nov 28 21:15:41 1994 Received: from pchindigo2.IPC.PKU.EDU.CN for arthur@pchindigo2.IPC.PKU.EDU.CN by www.ccl.net (8.6.9/930601.1506) id UAA29267; Mon, 28 Nov 1994 20:44:31 -0500 Received: by pchindigo2.IPC.PKU.EDU.CN (920330.SGI/911001.SGI) for CHEMISTRY@ccl.net id AA16077; Tue, 29 Nov 94 09:19:23 +0800 Date: Tue, 29 Nov 1994 09:19:22 +0800 (SST) From: Wan Arthur To: CHEMISTRY@ccl.net Subject: Look for Refs. of Rational Drug Design Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, all of the chemists, I am looking for some references of rational drug design. Would you please give me some hints? Regards, Arthur Wang ********************************************* * * * Mr. Arthur Wang * * Molecular Design Lab * * Institute of Physical Chemistry * * Peking University * * Beijing 100871 * * P.R.China * * * * E-mail: arthur@pchindigo2.ipc.pku.edu.cn * ********************************************* From tony@schroeder.newcastle.edu.au Mon Nov 28 21:34:40 1994 Received: from schroeder.newcastle.edu.au for tony@schroeder.newcastle.edu.au by www.ccl.net (8.6.9/930601.1506) id UAA29180; Mon, 28 Nov 1994 20:20:52 -0500 Received: by schroeder.newcastle.edu.au (AIX 3.2/UCB 5.64/4.03) id AA11110; Tue, 29 Nov 1994 12:20:41 +1000 Date: Tue, 29 Nov 1994 12:20:37 +1000 (EET) From: Tony Dyson To: Computational Chemistry List Subject: CCL: Alpha vs RS/6000 for g92 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII We are currently evaluating workstations for use running Gaussian. At this stage our options appear to be these: Alpha 200 4/233 Alpha 3000/700 IBM 37T (or maybe 3AT) Although benchmarks such as Linpack TPP appear to favour the Alpha machines, examination of the tables of Gaussian run-times that have been posted recently on CCL would indicate that this is not a good predictor of performance running Gaussian. My own tests with an Alpha 200 4/166 lead me to believe that the Alpha 200 4/233 will come in 5-10% slower than the IBM 37T. I know nothing about the 3000/700! If anybody has any experience with these machines running Gaussian, especially if you can shed some light on how the various architectures affect performance, I would _love_ to hear from you. Tony ================================================================ Mr. Anthony J. Dyson tony@schroeder.newcastle.edu.au Dept. of Physics phone: +49 21 5425 University of Newcastle fax: +49 21 6907 Callaghan, Australia, 2308 ================================================================ From THPierce@rohmhaas.com Mon Nov 28 21:41:32 1994 Received: from monte.br.rohmhaas.com for THPierce@rohmhaas.com by www.ccl.net (8.6.9/930601.1506) id VAA00161; Mon, 28 Nov 1994 21:08:54 -0500 Received: from rcsh04.sh.rohmhaas.com by monte.br.rohmhaas.com (AIX 3.2/UCB 5.64/4.03) id AA28964; Mon, 28 Nov 1994 21:02:16 -0500 Date: Mon, 28 Nov 1994 21:02:16 -0500 Message-Id: <9411290202.AA28964@monte.br.rohmhaas.com> X-Sender: rs0thp@monte.br.rohmhaas.com (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Chemistry@ccl.net From: THPierce@rohmhaas.com (Tom Pierce) Subject: RE: Defective PENTIUM FPU's X-Mailer: Previously David J. Heisterberg (djh@ccl.net) wrote (in response to John McKelvey): >>NOW WHAT? COMPUTE STATISTICAL PROBABILITIES OF ERRORS IN COMPUTED RESULTS? >Tim Coe at Vitesse Semiconductor has done just that. He's posted a >very detailed description of the problem in the comp.arch.arithmetic >news group. For the likelyhood of running into this bug he says > that needs clearing is that this is an extended precision problem. This > bug hits between 50 and 2000 single precision dividend divisor pairs (out > of a total of 64 trillion.) >His analysis shows that the probability of getting a relative error >greater than 1e-5 is 3e-12, of less than 1e-5, 6e-12. As to when this >error occurs > Examination of the above divide failures reveals that both the dividend > and divisor are integers minus small deltas. Also notable is the induced > error is roughly delta^(2/3). The integers in the divisors are actually Hmmm - integer minus small delta's ala x-y=4195835-3145727=1050108, a large delta, and the error is 256 -> delta^2/3 =4096 not 1,050,108. I am unhappy with the processor, and now will not use it for calculations... Maybe I should send it back... Where is that warranty card... -- Sincerely, Tom Pierce Ph.D.