From thys@schs.uia.ac.be Wed Nov 23 06:14:05 1994 Received: from sch2.uia.ac.be for thys@schs.uia.ac.be by www.ccl.net (8.6.9/930601.1506) id FAA22738; Wed, 23 Nov 1994 05:43:27 -0500 Received: from localhost by sch2.uia.ac.be (8.6.4/Ultrix3.0-C) id LAA17904; Wed, 23 Nov 1994 11:41:23 +0100 Date: Wed, 23 Nov 1994 11:41:19 +0100 (MET) From: Gerd Thys To: CCL cc: "J.J.P. Stewart" Subject: MOPAC93 - MECI Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear Netters, I'm interested in excitation energies of larger molecules (#atoms = 40-60). After geometry-optimization, I use the options 1SCF MECI C.I.=n, with n up to 8 or 9 ornitals. For n-values >9, I get the warning-message "TOO MANY CONFIGURATIONS".... I would like to include ALL orbitals in the MECI-calculation. Would this possible by slightly modifying the code? Did someone already try to include more than 10 orbitals? Please let me know... Best regards Gerd ---------------------------------------------------------------------------- Gerd Thys Ph.D. Student Structural Chemistry Group University of Antwerp (UIA) Universiteitsplein 1 E-mail: thys@uia.ua.ac.be B-2610 wilrijk URL: http://www.uia.ac.be/u/thys/index.html BELGIUM ---------------------------------------------------------------------------- From rs0thp@rohmhaas.com Wed Nov 23 09:15:22 1994 Received: from monte.br.rohmhaas.com for rs0thp@rohmhaas.com by www.ccl.net (8.6.9/930601.1506) id IAA24595; Wed, 23 Nov 1994 08:46:56 -0500 Received: by monte.br.rohmhaas.com (AIX 3.2/UCB 5.64/4.03) id AA26682; Wed, 23 Nov 1994 08:40:26 -0500 From: rs0thp@rohmhaas.com (Dr. Tom Pierce) Message-Id: <9411231340.AA26682@monte.br.rohmhaas.com> Subject: Re: CCL:PENTIUM GLITCH To: chemistry@ccl.net Date: Wed, 23 Nov 1994 08:40:25 -0500 (EST) In-Reply-To: <9411221347.ZM15133@xd88.kodak.com> from "lrbu00@xd88.kodak.com" at Nov 22, 94 01:47:18 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 718 Previously, John M. McKelvey wrote: > 1) THE REPORT OF THE GLITCH WE REPORTED YESTERDAY ORIGINATED FROM CLEVE MOLER > AT MATHWORKS. > 2) YESTERDAY WE VERIFIED IT USING REAL*8 WITH A WATCOM COMPILER. > 3) TODAY I VERIFIED IT USING THE CALCULATOR IN WINDOWS/ACCESSORIES! > REGARDS... > John M. McKelvey email: mckelvey@Kodak.COM IN spirit: 4) Last night I verified it with Excel 5.0 on my Pentium-90. ie "Z=X-(X/Y)*Y = 256, FOR X=4195835 AND Y=3145727. OBVIOUSLY THE CORRECT ANSWER IS EXACTLY 0" So it's is easy to est for and sad to find. -- Sincerely, Thomas Pierce - THPierce@RohmHaas.Com - Computational Chemist "These opinions are those of the writer and not the Rohm and Haas Company." From toukie@zui.unizh.ch Wed Nov 23 10:14:07 1994 Received: from rzusuntk.unizh.ch for toukie@zui.unizh.ch by www.ccl.net (8.6.9/930601.1506) id JAA25239; Wed, 23 Nov 1994 09:31:33 -0500 Received: by rzusuntk.unizh.ch (4.1/SMI-4.1.9) id AA04285; Wed, 23 Nov 94 15:31:23 +0100 X-Nupop-Charset: British Date: Wed, 23 Nov 1994 15:25:17 +0100 (MET) From: "Hr Dr. S. Shapiro" Sender: toukie@zui.unizh.ch Reply-To: toukie@zui.unizh.ch Message-Id: <55518.toukie@zui.unizh.ch> To: chemistry@ccl.net Subject: Soln relevance of MOPAC geometries Dear Colleagues; I am curious about the relevance (if any) of small molecular weight or- ganic molecules whose geometries are optimised using MOPAC to the geometries assumed by these same molecules in either an aqueous or a non-aqueous sol- vent environment. It is my understanding (please correct me if I am wrong) that the opti- mised geometries generated by MOPAC correspond to those single, isolated molecules in the gas phase or in vacuo. That being the case, are MOPAC- optimised geometries relevant to the study of small molecular weight mole- cules in, e.g., a solution of water? a solution of acetone? a solution of hexane? Of course, any references or citations that DIRECTLY address this prob- lem are most certainly welcome. Yours sincerely, (Dr.) S. Shapiro Institut fuer orale Mikrobiologie und allgemeine Immunologie Zentrum fuer Zahn-, Mund-, und Kieferheilkunde der Universitaet Zuerich Plattenstrasse 11 Postfach CH-8028 Zuerich, Switzerland Internet: toukie@zui.unizh.ch FAX-nr: ( ... + 1) 261'56'83 From soperpd@nylon.es.dupont.com Wed Nov 23 10:25:02 1994 Received: from gatekeeper.es.dupont.com for soperpd@nylon.es.dupont.com by www.ccl.net (8.6.9/930601.1506) id JAA25521; Wed, 23 Nov 1994 09:48:58 -0500 Received: by gatekeeper.es.dupont.com; id AA00904; Wed, 23 Nov 94 09:48:51 -0500 Received: by esds01.es.dupont.com; id AA17358; Wed, 23 Nov 94 09:48:50 -0500 Received: by nylon.es.dupont.com (931110.SGI/920502.SGI)for @esds01.es.dupont.com:chemistry@ccl.net id AA18242; Wed, 23 Nov 94 09:49:09 -0500 Date: Wed, 23 Nov 94 09:49:09 -0500 From: soperpd@nylon.es.dupont.com (Paul D. Soper) Message-Id: <9411231449.AA18242@nylon.es.dupont.com> To: chemistry@ccl.net Subject: CCL: Summary of conversion of 3d structures to 2D drawings I recently asked for programs which could convert 3D structures to 2D drawings. The replies, which follow, included these programs: Cambridge Crystal Structure Database System CAMEO Catalyst - MSI ChemDraw & Chem3D - Cambridge Scientific Chemeleon - Exographics Chemistry 4D-Draw - ChemInnovation Depict, Daylight Programmers Toolkit - Daylight Simon Kilvington provided the following reference: D.Weininger; "Smiles 3. Depict. Graphical depiction of chemical structures." J. Chemical Information and Computer Sciences, 30 (1990) pp237-243. Layout - MDL Sybyl, Unity, dbtranslate - TRIPOS Bob Zinn suggested the transform xp(i)=y(i)-x(i) yp(i)=(x(i)+y(i)-2*z(i))/2 which he has implemented in MathCAD Many thanks to all who replied. ----------------------------------------------------------------- Paul Soper All the usual disclaimers apply DuPont Central Research soperpd@esvax.dnet.dupont.com P.O. Box 80328 Tel (302)-695-1757 Wilmington, DE 19880-0328 FAX (302)-695-8412 ----------------------------------------------------------------- THE ORIGINAL REQUEST: Do you know of any programs (public domain or commercial) which can take a 3D structure or a connectivity graph and produce a drawing similar to those from ChemDraw or ChemWindows? (These drawings are like those one would find in an organic chemistry textbook.) I'm looking for something more sophisticated than simply removing the z coordinate from an xyz file. REPLIES: ------------------------------------------------------------------------ From: dough@mdli.com If you have access to MACCS, with 3D module, at your site, you can do MEDIT GET FILE - some 3D MDL molfile MEDIT FLATTEN - this generates bond hash and wedge marks - optional... MEDIT CLEAN - this does what the CLEAN command in MACCS Draw menu does It may take a couple of cycles of MEDIT CLEAN to get an acceptable structure. There is also a LAYOUT program which does a lot more in the way of orienting and layout. Other vendors have similar capability - e.g., Daylight's DEPICT, and any of the programs which input SMILES. The Exographics Chemeleon program has some 2D modeling capability, too. ------------------------------------------------------------------------ From: Harold Helson Dear Paul: The program CAMEO (Computer-Assisted Mechanistic Evaluation of Organic Reactions) can read PDB files and redraw them in two-dimensions. There might be a Mac version of this program available now. If you are interested, you can contact Professor William L. Jorgensen: bill@adrik.chem.yale.edu Sincerely, Harold Helson (Former CAMEO programmer) ------------------------------------------------------------------------ From: bob.zinn@chemgate.chem.lsu.edu (bob zinn) in a program I wrote a few years ago, to display molecules from x,y,z coordinates as stereo pairs, I plotted xp(i)=y(i)-x(i) and yp(i)=(x(i)+y(i)-2*z(i))/2 as one of the pictures. the other one had the coordinates transformed by a small rotation around the center. If you have mathcad available, I can send a copy of the program. It kind of worked ok for the proteins a professor was working with. The rotation was kinda slow, when I was trying to see how things lined up in the molecule. I think the 3d-2d transformation shown above came from one of mathcad's examples. -bz- Robert R. "bz" Zinn Department of Chemistry Louisiana State University Baton Rouge, LA. 70803-1804 (504) 388-5381 audio (504) 388-3458 (FAXual) bob.zinn@chemgate.chem.lsu.edu chsec@lsumvs.sncc.lsu.edu ------------------------------------------------------------------------ From: wallyr@netcom.com (Walter E. Reiher III) I am aware of two such systems: software distributed by Daylight Chemical Information Systems and by Tripos Inc. I have not personally used the Daylight software, so I'm not 100% certain they can take a 3D structure + connection table and create such a depiction, but I'm pretty sure then can: they can certainly create a depiction from a connection table specified as a SMILES string. I have used the Tripos software in the Unity database package and the Molecular Spreadsheet. I would advise you that the depictions from the Tripos software are generally dismal; they seldom look anything like what a chemist would draw using a chemical drafting program. What I've seen of the Daylight depictions aren't great but better than Tripos'. Cambridge Scientific, the ChemDraw people, may be able to do this since Chem3D and ChemDraw seem to work together; it's worth a call to them. Hope this helps! Wally ======================================================================== Walter E. Reiher III, Ph.D. WallyR@netcom.com Consultant in Computational Chemistry P.O. Box 61056 voice 408-720-0240 Sunnyvale, CA 94088 fax 408-720-0378 ------------------------------------------------------------------------ From: ellen@nautilus.ariad.com (Ellen R. Laird) Greetings, Paul: If your site maintains a Sybyl license, the following may be of interest: I have seen a brief demonstration of a new SPL script that I am told is integrated into the newest version of Sybyl (6.1). For the cases to which I saw it applied, the results were very pleasing. - Ellen ------------------------------------------------------------------------------- ~~~~~~ ~~~~~~~~ Ellen R. Laird ~~~~~~~~~~ ellen@ariad.com ~~~~~~~~~~ ~~~~~~~~ ~~~~~~ARIAD Pharmaceuticals, Inc. 26 Landsdowne St. Cambridge MA 02139 (617) 494-0400, ext 234 fax: 494-8144 ------------------------------------------------------------------------------- ------------------------------------------------------------------------ From: nxb96@acs.org (Nanette Butterworth) Hello, There is a product by ExoGraphics called Consystant/Chemeleon which does exactly that. The 3-D formats it supports are: AlchemyIII, Mol MDL's Mol Beilstein's ROSDAL Tripos' SYBYL, Mol2 Tripos' SYBYL Line Notation BioSym BioCad HyperChem, Hin The 2-D formats is supports are: ISISDraw Molecular Presentation Graphics ChemPrint (near future) ChemWindows/ChemIntosh The price of this product for ACS members is $159. On December 1 the price may be reduced even lower. To order this product call ACS at1-800-227-5558 and select 9, 1, 1 on the voice menu. Good luck! NB ------------------------------------------------------------------------ From: MARTIN%cmda@randb.abbott.com The pictures are ok, not great, by using the Daylight software Depict. Also Sybyl will do this. Both give postscript output. Yvonne Martin Abbott Laboratories ------------------------------------------------------------------------ From: "A.Masunov" Try the software accompanying Cambridge Crystal Structure Database. I've seen the output of the last version. It contains nice structural formulas even for cage molecules. Regards, Artem --------------------------Artem E. Masunov---------------------------- | Chemistry Department, Hunter College, City University of New York | | E-mail: AEMHC@cunyvm.cuny.edu, tel: 212/725-0317, fax:772-5332 | ---------------------------------------------------------------------- ------------------------------------------------------------------------ From: Mike Wang Here is a program which may indirectly help you if you know the IUPAC names of the structures: Chemistry 4D-Draw (tm) is an advanced drawing program with an intelligent module, NamExpert, that understands IUPAC organic nomenclature rules. The program interprets chemical names and automatically creates high quality structures. It provides intelligent drawing tools for creating publication-quality graphics. It allows you to create structure templates with user-defined trivial names. Systems: Macintosh and Windows From: ChemInnovation Software 8190E Mira Mesa Bl., #428 San Diego, California 92126, USA (619)566-2846, Fax (619)566-4138 Hope this helps. ------------------------------------------------------------------------ From: Leif Norskov Catalyst from MSI and Unity from Tripos will both do that. Catalyst does it very nicely, too. But in both cases it is a bit like using a Ferrari instead of a bicycle to go a few blocks across town. Sincerely, Leif Norskov Novo Nordisk A/S Copenhagen Denmark lnl@novo.dk ------------------------------------------------------------------------ From: Dave Cosgrove Paul, This one cropped up a few months ago, but I don't think a summary was posted. Perhaps you could post a summary when you've got some answers, just for the archive! My own solutions to this problem are two-fold : There is a Depict toolkit from Daylight (try yosi@daylight.com) that will take a SMILES string and produce a set of 2D structures. We have some quibbles about the pictures produced ( straight chain alkanes come out as a straight line, for instance ), but the toolkit is cheap(ish) for what it does. I think you would probably need to buy the SMILES toolkit as well, but I don't think the two together come to more than 5000 pounds sterling ( I don't have a dollar price). With the SMILES toolkit you are no longer restricted to SMILES strings, since you can read any file and build the molecule into a SMILES string before calling Depict to produce the coordinates. These are toolkits, however, you need to build them into a program, in any of C, C++, FORTRAN or even, I believe, Ada and Pascal. If you have Sybyl, you can persuade it to produce fairly dodgy 2D pictures, from a SMILES string, using the following commands: SMILESTOMOL M1 TRUE MOL OUT M1 Again, this uses a SMILES string as input. In principle you can get Sybyl to create a SMILES string for you, from a file you have read in, but in my experience this is frequently unsuccessful. Regards, Dave *** --- __o __o __o *** *** ------ \<, \<, \<, *** *** ----- ( )/ ( ) ( )/ ( ) ( )/ ( ) *** ------------------------------------------------------------------------ From: Simon Kilvington Paul, the Daylight programmers toolkit will do what you want - sorry I don't have an address, but I do have a reference to a description of how the connection table to 2D representation works if you want to write your own version. D.Weininger; "Smiles 3. Depict. Graphical depiction of chemical structures." J. Chemical Information and Computer Sciences, 30 (1990) pp237-243. hope this helps, though I expect a lot of other people will have told you the same thing. Simon. (srk@soton.ac.uk) ------------------------------------------------------------------------ From: Tom Moock x1301 In response to your question about 3D -> 2D conversion: I don't know of a program that takes 3d coordinates and returns a "2D" representation of it. It brings to mind some sort of 2D optimization, or flattening, of the structure, that still retains some of the original relative atom positions. However, there are programs that take a connection table, with NO coordinate info, and generates a 2D picture. Here at MDL we have a program called LAYOUT, although the demand for it has been light in the last several years. Daylight also has a program DEPICT that runs on smiles codes, and does a similar thing. There are a few other database products (Questel Darc) that do not store coordinates in their databases, but generate them upon retrieval. -Tom Moock MDL Info Sys ------------------------------------------------------------------------ From: Brian Karlak I've found that dbtranslate, in Tripos' suite of Unity products, can perform the 3D -> 2D coordinate translation by translating the 3D structure into SMILES or SLN (which contain only connectivity info, thus stripping the coordinate info) and then translating that file into a sybmol, sybmol2 or maccs file. The double translation can be performed with a single Unix command and is very fast. Brian Karlak Onyx Pharmaceuticals ------------------------------------------------------------------------ From ADAMO@CHEMNA.DICHI.UNINA.IT Wed Nov 23 11:14:19 1994 Received: from CHEMNA.DICHI.UNINA.IT for ADAMO@CHEMNA.DICHI.UNINA.IT by www.ccl.net (8.6.9/930601.1506) id KAA26760; Wed, 23 Nov 1994 10:41:31 -0500 From: Received: from CHEMNA.DICHI.UNINA.IT by CHEMNA.DICHI.UNINA.IT (PMDF V4.3-10 #3559) id <01HJTQEBUIA800016B@CHEMNA.DICHI.UNINA.IT>; Wed, 23 Nov 1994 16:42:13 +0100 (CET) Date: Wed, 23 Nov 1994 16:42:13 +0100 (CET) Subject: IGLO 3 basis set To: chemistry@ccl.net Message-id: <01HJTQEC17EQ00016B@CHEMNA.DICHI.UNINA.IT> X-VMS-To: IN%"chemistry@ccl.net" X-VMS-Cc: ADAMO MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Dear net-ters, do you know an anonymous ftp site where is possible to find IGLO 3 basis set? I need, at least, the double set of polarization functions of this basis set for H,B,C,N,O,F. Thank Carlo ------------------------------------------------------------------------------- Carlo Adamo | tel. +39-81-5476504 Dipartimento di Chimica | fax +39-81-5527771 via Mezzocannone 4 | e-mail ADAMO@CHEMNA.DICHI.UNINA.IT I-80134 Napoli | Italy | ________________________________________________________________________________ From djh@ccl.net Wed Nov 23 12:14:09 1994 Received: from xipe.ccl.net for djh@ccl.net by www.ccl.net (8.6.9/930601.1506) id LAA27401; Wed, 23 Nov 1994 11:15:47 -0500 From: David Heisterberg Received: for djh@ccl.net by xipe.ccl.net (8.6.9/920428.1525) id LAA00669; Wed, 23 Nov 1994 11:15:46 -0500 Date: Wed, 23 Nov 1994 11:15:46 -0500 Message-Id: <199411231615.LAA00669@xipe.ccl.net> To: chemistry@ccl.net Subject: GVB open shell singlet Content-Length: 761 Dear All, I've been trying, without any success, to run a GVB-OSS calculation on a transition metal complex with GAMESS. RHF, ROHF triplet, and GVB-PP calculations run like a champ. I've tried using orbitals from each of these as an initial guess for the OSS and get either wild oscillations or termination with an eigenvector of zero norm. Can anyone suggest something? The HOMO and LUMO are of B2g and B1u symmetry so there shouldn't be a problem with a non-totally symmetric density (yes/no?). Thanks for any pointers you might have. -- David J. Heisterberg (djh@ccl.net) Gee, it's so beautiful, I gotta The Ohio Supercomputer Center give somebody a sock in the jaw. Columbus, Ohio -- Little Skippy (Percy Crosby) From jkl@ccl.net Wed Nov 23 12:17:50 1994 Received: for jkl@ccl.net by www.ccl.net (8.6.9/930601.1506) id LAA27913; Wed, 23 Nov 1994 11:38:20 -0500 Date: Wed, 23 Nov 1994 11:38:20 -0500 From: Jan Labanowski Message-Id: <199411231638.LAA27913@www.ccl.net> To: chemistry@ccl.net Subject: Book: LATTICE METHODS FOR MULTIPLE INTEGRATION Cc: jkl@ccl.net For people who do grids, it may be of great interest: Ian H. Sloan and Stephen Joe Oxford University Press, New York and Oxford 1994. ISBN 0-19-853472-8 250 pages, 60 line figures Price: $US55 Orders from OUP Customer Services, 2001 Evans Road, Cary, NC 27513, phone 800-451-7556 fax 919-677-1303. Postage and packaging $2.50. This book is the first devoted to lattice methods, a recently developed method for the evaluation of multiple integrals in many variables, which arise in quantum physics and chemistry, statistical mechanics, Bayesian statistics, and many other fields. The book begins with a review of existing methods, before presenting lattice rules in a thorough self-contained manner, with numerous illustrations and examples. Group theory and number theory enter the story, but the treatment is such that no prior knowledge of these subjects is required. Both the theory and practical implementation are covered. An algorithm is presented along with tables not available elsewhere, allowing the practical evaluation of multiple integrals in up to at least 12 variables. Most importantly, the algorithm produces a very efficient estimate of the error. The book provides a fast track for readers wanting to move rapidly to using lattice mathods in practical calculations. It concludes with the results of extensive numerical comparisons with other methods, such as the Monte Carlo method. Jan Labanowski jkl@ccl.net (No, I am not a contributor to this book and have no commercial or career interest). From chaka@lubrizol.com Wed Nov 23 14:14:13 1994 Received: from interlock.lubrizol.com for chaka@lubrizol.com by www.ccl.net (8.6.9/930601.1506) id OAA00632; Wed, 23 Nov 1994 14:06:07 -0500 From: Received: by interlock.lubrizol.com id AA08248 (InterLock SMTP Gateway 1.1 for chemistry@ccl.net); Wed, 23 Nov 1994 14:06:00 -0500 Message-Id: <199411231906.AA08248@interlock.lubrizol.com> Received: by interlock.lubrizol.com (Internal Mail Agent-1); Wed, 23 Nov 1994 14:06:00 -0500 Date: Wed, 23 Nov 1994 13:35:34 -0500 To: chemistry@ccl.net Subject: Call for Papers - ACS Central Regional Meeting ************************************************************************** CALL FOR PAPERS Symposium on Industrial Applications of Quantum Chemistry 27th ACS Central Regional Meeting Akron, Ohio May 31 - June 2, 1995 Technical papers and poster presentations are invited on industrial or commercial applications of quantum mechanics to all areas of chemistry, including analytical, physical, inorganic, organic, solid state, polymer, physical, and biochemistry. The symposium will be held on Thursday, June 1 and the morning of Friday, June 2. Invited speakers include: Ernest R. Davidson, Indiana University David A. Dixon, DuPont Michel Dupuis, IBM Corporation John McKelvey, Eastman Kodak Nelson G. Rondon, The Dow Chemical Company Rick Ross, PPG Industries The meeting, which is hosted by the ACS Akron Section, will be held in the new convention facility, the J.S. Knight Center, located near the University of Akron. Send abstracts and three copies (original on ACS Abstract Form) by January 9, 1995, to: Anne M. Chaka Research Division The Lubrizol Corporation 29400 Lakeland Boulevard Wickliffe, Ohio 44092-2298 216-943-1200 x2027 chaka@lubrizol.com ****************************************************************************** P.S. One of the main goals of the symposium is to facilitate communication and exchange between industry and academia so that the latest theoretical techniques can be used to solve problems of commercial importance. For those in industry with little or no experience in quantum chemistry, an ACS short course on Quantum Mechanics will be held before the meeting on May 30th in Akron. The course is intended to serve as an introduction to basic molecular orbital theory and how it can be applied to chemical problems. Topics to be covered will include semiempirical and ab initio methods (Hartree-Fock and Density Functional Theory), basis sets, reaction mechanisms, transition state theory, spectroscopy, and thermodynamic properties. For more information about the short course, contact Anne Chaka. ****************************************************************************** From wipke@SECS.UCSC.EDU Wed Nov 23 15:14:15 1994 Received: from MOLENG.UCSC.EDU for wipke@SECS.UCSC.EDU by www.ccl.net (8.6.9/930601.1506) id OAA01170; Wed, 23 Nov 1994 14:33:33 -0500 Received: by SECS.UCSC.EDU (MX V3.1C) id 20444; Wed, 23 Nov 1994 11:33:15 PST Date: Wed, 23 Nov 1994 11:33:12 PST From: "W. Todd Wipke" To: chemistry@ccl.net Message-ID: <00987E4E.76F715F3.20444@SECS.UCSC.EDU> Subject: UCSC SURF95 Summer Research Opportunities The University of California Santa Cruz welcomes applications for our NSF Summer Research Fellowship program (SURF95) for research in chemistry and biochemistry with faculty of the Chemistry and Biochemistry Department. Applicants must be citizens or permanent residents of the United States or its possessions to be eligible for the program. To receive application forms and information, send email to "fileserv@secs.ucsc.edu" and in the BODY of the msg put "SEND SURF" without the quotes. Computational chemistry and molecular design is a central focus of this program, and fellows participate in a summer symposium on Molecular Engineering. -Todd Wipke SURF Director From mckee@chem.auburn.edu Wed Nov 23 15:21:30 1994 Received: from mallard.duc.auburn.edu for mckee@chem.auburn.edu by www.ccl.net (8.6.9/930601.1506) id OAA00829; Wed, 23 Nov 1994 14:16:39 -0500 From: Received: from chem.auburn.edu (mckee.chem.auburn.edu) by mallard.duc.auburn.edu (5.0/SMI-SVR4) id AA23879; Wed, 23 Nov 1994 13:16:36 -0600 Received: by chem.auburn.edu (5.0/SMI-SVR4) id AA13121; Wed, 23 Nov 1994 13:17:16 +0600 Date: Wed, 23 Nov 1994 13:17:16 +0600 Message-Id: <9411231917.AA13121@chem.auburn.edu> To: chemistry@ccl.net Subject: details of FDIV bug in Pentium X-Sun-Charset: US-ASCII Content-Length: 9524 "taken from comp.arch" In article 10362@vitsemi.com, coe@vitsemi.com (Tim Coe) writes: Much of the following explanation was previously posted to comp.sys.intel. A more complete tentative software model of the Pentium divider that explains all divide errors that I am aware of is included with this post. On a Packard Bell P90 PC I performed the following calculation using Microsoft Windows Desk Calculator: (4195835 / 3145727) * 3145727 The result was 4195579. This represents an error of 256 or one part in ~16000. ak@ananke.s.bawue.de (Andreas Kaiser) writes >Usually, the division is correct (what did you expect?). Just a few >operands are divided wrong. My results (P90) with ~25.000.000.000 >random arguments (within 1..2^46), with even results divided by two >until odd, to assure unique mantissa patterns (the binary exponent >doesn't care, of course). > > 3221224323 > 12884897291 > 206158356633 > 824633702441 > 1443107810341 > 6597069619549 > 9895574626641 > 13194134824767 > 13194134826115 > 13194134827143 > 13194134827457 > 13194138356107 > 13194139238995 > 26388269649885 > 26388269650425 > 26388269651561 > 26388276711601 > 26388276712811 > 52776539295213 > 52776539301125 > 52776539301653 > 52776539307823 > 52776553426399 > > Gruss, Andreas > >-------------------- >-- Andreas Kaiser -- internet: ak@ananke.s.bawue.de >-------------------- fidonet: 2:246/8506.9 Analysis of these numbers reveals that all but 2 of them are of the form: 3*(2^(K+30)) - 1149*(2^(K-(2*J))) - delta*(2^(K-(2*J))) where J and K are integers greater than or equal to 0, and delta is a real number that has varying ranges depending on J but can generally be considered to be between 0 and 1. The 2*J terms in the above equation leads to the conclusion that the Pentium divider is an iterative divider that computes 2 bits of quotient per cycle. (This is in agreemnent with the quoted 39 cycles per extended long division from the Pentium data book. The technical name for this type of divider is radix 4) The extremely low probability of error (1 in 10^10) implies that the remainder is being held in carry save format. (Carry save format is where a number is represented as the sum of two numbers. This format allows next remainder calculation to occur without propagating carries. The reason that carry save format is implied by the error probability is that it is very difficult but not impossible to build up long coincident sequences of ones in both the sum word and the carry word.) I assumed the digit set was -2, -1, 0, 1, and 2. (Having 5 possible digits in a radix 4 divider allows a necessarry margin for error in next digit selection. When doing long division by hand the radix 10 and 10 possible digits allow no margin for error.) Taking the above into consideration I wrote the tentative model of Pentium divide hardware included below so that I might watch what bit patterns developed in the remainder. After running the numbers that were known to fail and numbers near them that appeared not to fail I determined the conditions for failure listed in the program. Analysis of the precise erroneous results returned on the bad divides indicates that a bit (or bits) is being subtracted from the remainder at or near its most significant bit. A modeling of this process is included in the program. The program accurately explains all the published errors and accurately predicted the error listed at the beginning of the article. The determination of the quotient from the sequence of digits is left as an exercise for the reader ;-). I would like to thank Dr. Nicely for providing this window into the Pentium architecture. -Tim Coe coe@vitsemi.com An example run of the program (using the first reported error): ---Enter dividend mantissa in hex: 8 ---Enter divisor mantissa in hex: bfffffb829 ---next digit 1 ---1111000000000000000000000001000111110101101111111111111111111100 ---0000000000000000000000000000000000000000000000000000000000000100 ---11110000000000000000000000010001 iteration number 1 ---. ---. ---. ---next digit -1 ---0011111111100100101011110100110000010111010000000000000000000000 ---1101111111111111111110110110010010010000000000000000000000000000 ---00011111111001001010101010110000 iteration number 14 ---next digit 2 ---A bug condition has been detected. ---Enter 0 for correct result or 1 for incorrect result: 1 ---0000000001101101010100001000000111110110011111111111111111111100 ---1111111100100101010110100110010010010010000000000000000000000100 ---11111111100100101010101011100101 iteration number 15 ---next digit 0 ---1111110100100000001010111001010110010001111111111111111111100000 ---0000000100101010100000000000010010010000000000000000000000100000 ---11111110010010101010101110011001 iteration number 16 ---. ---. ---. #include main() { unsigned r0, r1, r2, r3, r4, r5, r6, s0, s1; unsigned t0, t1, t2, t3, cycle, f, incorrect; unsigned thr_m2_m1, thr_m1_0, thr_0_1, thr_1_2, positive, errornum; char line[30], *linepoint; r0 = 0x0bffffc0; r1 = 0; r2 = 0x0800bf60; r3 = 0; printf("Enter dividend mantissa in hex: "); scanf("%s", line); linepoint = line; while (*linepoint != '\0') linepoint++; while (linepoint < line + 15) *linepoint++ = '0'; *(line+15) = '\0'; sscanf(line+7, "%x", &r3); *(line+7) = '\0'; sscanf(line, "%x", &r2); printf("Enter divisor mantissa in hex: "); scanf("%s", line); linepoint = line; while (*linepoint != '\0') linepoint++; while (linepoint < line + 15) *linepoint++ = '0'; *(line+15) = '\0'; sscanf(line+7, "%x", &r1); *(line+7) = '\0'; sscanf(line, "%x", &r0); r4 = 0; r5 = 0; /* These thresholds are VERY tentative. */ /* There may be bugs in them. */ t0 = r0 >> 22; /* Next threshold is strongly indicated */ /* by the failure of 9895574626641 */ if (t0 < 36) thr_0_1 = 3; /* Next threshold is strongly indicated */ /* by the failure of 824633702441 */ else if (t0 < 48) thr_0_1 = 4; else if (t0 < 56) thr_0_1 = 5; else thr_0_1 = 6; thr_m1_0 = 254 - thr_0_1; if (t0 < 33) thr_1_2 = 11; else if (t0 < 34) { printf("This model does not correctly handle\n"); printf("this divisor. The Pentium divider\n"); printf("undoubtly handles this divisor correctly\n"); printf("by some means that I have no evidence\n"); printf("upon which speculate.\n"); exit(); } else if (t0 < 36) thr_1_2 = 12; else if (t0 < 39) thr_1_2 = 13; /* Next threshold is strongly indicated */ /* by the failure of 1443107810341 */ else if (t0 < 42) thr_1_2 = 14; else if (t0 < 44) thr_1_2 = 15; else if (t0 < 48) thr_1_2 = 16; else if (t0 < 54) thr_1_2 = 18; else if (t0 < 60) thr_1_2 = 20; else thr_1_2 = 23; thr_m2_m1 = 254 - thr_1_2; /* Further error conditions may exist. */ /* I believe they could be accom- */ /* adated by adding conditions to the */ /* following clause. */ if (t0 == 35) errornum = 22; else if (t0 == 41) errornum = 26; else if (t0 == 47) errornum = 30; else errornum = 128; incorrect = 0; cycle = 1; /* The cycle count was chosen to keep */ /* the errors on my 60 line screen and */ /* would be 33 or 34 for extended long. */ while (cycle < 27) { t0 = 255 & ((r2 >> 24) + (r4 >> 24)); if ((t0 > thr_m1_0) || (t0 < thr_0_1)) { s0 = 0; s1 = 0; positive = 0; printf("next digit 0\n"); } else if (t0 > thr_m2_m1) { s0 = r0; s1 = r1; positive = 0; printf("next digit -1\n"); } else if (t0 < thr_1_2) { s0 = ~r0; s1 = ~r1; positive = 4; printf("next digit 1\n"); } else if (t0 & 128) { s0 = (r0 << 1) | (r1 >> 31); s1 = r1 << 1; positive = 0; printf("next digit -2\n"); } else { s0 = ~((r0 << 1) | (r1 >> 31)); s1 = ~(r1 << 1); positive = 4; printf("next digit 2\n"); if ((t0 == errornum) && (((r2 >> 21) & 7) == 7) && (((r4 >> 21) & 7) == 7)) { printf("A bug condition has been detected.\n"); printf("Enter 0 for correct result or 1 for incorrect result: "); scanf("%d", &incorrect); if (incorrect) { if (errornum == 22) s0 = s0 - (3 << 25); else s0 = s0 - (4 << 25); } } } t0 = s0 ^ r2 ^ r4; t1 = s1 ^ r3 ^ r5; t2 = (s0 & r2) | (s0 & r4) | (r2 & r4); t3 = (s1 & r3) | (s1 & r5) | (r3 & r5); r2 = (t0 << 2) | (t1 >> 30); r3 = t1 << 2; r4 = (t2 << 3) | (t3 >> 29); r5 = (t3 << 3) | positive; t0 = r2; f = 32; while (f--) { if (t0 & (1 << 31)) putchar('1'); else putchar('0'); t0 = t0 << 1; } t0 = r3; f = 32; while (f--) { if (t0 & (1 << 31)) putchar('1'); else putchar('0'); t0 = t0 << 1; } putchar('\n'); t0 = r4; f = 32; while (f--) { if (t0 & (1 << 31)) putchar('1'); else putchar('0'); t0 = t0 << 1; } t0 = r5; f = 32; while (f--) { if (t0 & (1 << 31)) putchar('1'); else putchar('0'); t0 = t0 << 1; } putchar('\n'); t0 = r2 + r4; f = 32; while (f--) { if (t0 & (1 << 31)) putchar('1'); else putchar('0'); t0 = t0 << 1; } printf(" iteration number %d\n", cycle++); } } Adrian Cockcroft - adrian.cockcroft@corp.sun.com - Mailstop: UPAL1-431 SMCC Product Marketing Engineering - Phone 415 336 0615 - Fax 415 336 0648 Sun Microsystems, 2550 Garcia Avenue, Mountainview, CA 94043, USA From wallyr@netcom.com Wed Nov 23 16:14:12 1994 Received: from netcom4.netcom.com for wallyr@netcom.com by www.ccl.net (8.6.9/930601.1506) id PAA02003; Wed, 23 Nov 1994 15:26:26 -0500 Received: by netcom4.netcom.com (8.6.9/Netcom) id MAA07111; Wed, 23 Nov 1994 12:26:38 -0800 From: wallyr@netcom.com (Walter E. Reiher III) Message-Id: <199411232026.MAA07111@netcom4.netcom.com> Subject: Re: CCL:DEFECTIVE PENTIUM FPU'S To: chemistry@ccl.net Date: Wed, 23 Nov 1994 12:26:37 -0800 (PST) In-Reply-To: <9411221517.AA28409@monte.br.rohmhaas.com> from "Dr. Tom Pierce" at Nov 22, 94 10:17:37 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 10248 Thanks to John McKelvey for informing us of this disturbing problem. I just took a look at comp.sys.intel to learn more about this problem with Pentium chips. There's a lot of flaming going on over there, but to summarize briefly: . It looks like some folks (outside of Intel) have known about this problem for a couple of weeks now. . There are reports of problems with both single- and double-precision division. . Intel has known about it for a while and hasn't told anyone. They have supposedly fixed the problem but did not mark the chips so we can easily tell a chip has the fix just by looking. . I have not seen a report of anyone who actually has CPU with the fix. . The problem was reported on CNN yesterday (I didn't see it). . Reportedly, an Intel spokesman said on CNN that they will NOT simply replace all defective CPUs in the field because they do not consider the problem to be significant. They will replace chips on a case- by-case basis. It looks like THEY will decide if it's important to YOU whether floating point calculations are right or wrong in your Pentium. . Some folks have reported success with reaching Intel Microprocessor Support at 800-628-8686. (I haven't tried yet.) . A statement attributed to Intel (I can't verify this) said: "Concerned users doing extensive floating point operations requiring extraordinary precision who desire further details can call Intel at 408-765-8914." Terje Mathisen of Hydro Data, Norsk Hydro posted a very small program which tells you if your system has the problem. It's pretty obvious... mine says (sigh): "It has the FDIV bug: (1.0/824633702449.0)*824633702449.0 is not equal to 1.0!" He posted his uuencoded program to comp.sys.intel with assembly source. That message is attached. For convenience, I have decoded the program and uploaded the binary file to ftp.ccl.net/incoming/p87test.zip. Download it by binary FTP and use either Info-ZIP's or PKZIP's unzippers to decompress. Wally ======================================================================== Walter E. Reiher III, Ph.D. WallyR@netcom.com Consultant in Computational Chemistry P.O. Box 61056 voice 408-720-0240 Sunnyvale, CA 94088 fax 408-720-0378 From netcom.com!ix.netcom.com!howland.reston.ans.net!pipex!sunic!trane.uninett.no!eunet.no!nuug!telepost.no!hydro.com!usenet Wed Nov 23 11:20:39 1994 From: Terje.Mathisen@hda.hydro.com (Terje Mathisen) Newsgroups: comp.sys.intel Subject: FDIV bug: Attempted summary and new p87test Date: 13 Nov 1994 14:39:59 GMT Organization: Hydro Data, Norsk Hydro (Norway) Reply-To: Terje.Mathisen@hda.hydro.com (Terje Mathisen) Since I started this thread, I'd like to summarize my current views on this bug: - *If* Intel have know about this problem for several months, and *decided* not to warn users about it, those responsible for that decision should be fired. There is no excuse for knowing about a silent bug like this, and not tell about it. - An error that results in a hardware crash is much less serious than this one which returns wrong answers. - Since the bit-pattern that fails seems to be about 18 bits long (..11110111000001...), the odds of hitting it should be about 1/2^18, or 1/6E7. With 8 significant digits in the answer, this means that the average (for truly random data) precision on a Pentium is less than 16 digits. - I have nothing against x86 cpu's, rather the opposite, since I love writing asm code for them. The company I work for will still buy new Pentium machines, but as soon as I first heard and verified the problem, I specified that new machines would only be aquired from dealers who promized to exchange the cpus as soon as Intel makes the fixed p5s available. Since I first posted p87test, I've gotten email from people who tell me that it thinks their Pentium-90 is a 386. This will happen if you are running under a V86 monitor which virtualizes the eflags register and disallow toggling the AlignmentControl (bit #18) and/or CPUID (bit #21). The new version will perform the test for FDIV precision independently of cpu version, as long as a numeric coprocessor seems to be present. I have also found a bug in the program, where I demanded that the result after FDIV/FMUL should be identical to 1.0. I have changed this to allow a small ulp error. To make the program more useful, it will now also report (and document) the 'secret' CPUID feature bits, on a Pentium or new-model 486. -Terje Mathisen (include std disclaimer) "almost all programming can be viewed as an exercise in caching" PS. I someone wants to make p87test.zip available on an ftp site, that would probably be the best solution. begin 600 p87test.zip M4$L#!!0``(`(`"IY;1V*MU!1>`H``-0C```+````4#@W5$535"Y!4TW%6GM3 MW#@2_Y\JOD.S1Q6P&.)Y`)-07%A@N>4V/"J09&\IBM+8\HR#Q_)9,@SY]*>6 M[''+XPE)*E7G(C&VU*W6K]\R4%[;$Q'R!%24ED7+S&"K[ MNK/M+R\-BU&:DY>#;G^WU]OSN_W^:QP/XRBB1&_!O?;A>BR*)(0A!W_;!Q8I MGH/B4@LQ6D$I(LY4D?/[8:PDA"&\Q9=!5MQ/Y`C")\OF;.`/IJL>G'4&NWCK MVEO/WOKFIFGB<&=U>2D-,X?X0@SV<)KFL6>)]RSQWBH5((FE0IHH*_3PXX3K M_V,QS!_T/9/XI&2`O^],9*[OO@>3`%\'T\&J%3HW*(1#N^[:%4]57$S@].3L M(V@D(8K3D.?;`.O!!MSP_#.'0I=%Z_[J_52JF8='I>Q_?L_VNK:[B. M!8.L`0(K%&20QJ5+`9`>B1^>G=A=.[;=-["Z?WVJ;W%T[OMTPO MM=HVO8)7Y##D"NVJ2;R\9'1/5SM3,&824@%IF*VXDAD#F9]K8=U#@B9.K;P1 MII;9O46S]0#N(6&XA2;9\A+:HV-6`!UX`Z=7'V#]XN1J`T0:C&.7"JVW0=/5 M-!_C7!4L`8WSN0@Y_#Y5/)6Q2*5#;:W>H>YKZK-7EW"4<_:0B3A5+@DZ2&/! M@2:Y8B,.U_&7A4NA2[ET'5_3W<033:?8)(-C4:0:&'*:TG*X53@$.1G.7)\Y6U9>JSYGTEO`=/L1IKG>I7&>97$ZLF3X]$UD-NO9I?#7U9=H7/TEB<&Y#)JZRXOT$WK%[-"@+?ZWA=K^?UO1VT@N6EBS!;,/5"I-PSP=?# MF.IAJ-Q<7D(1[XW=6Q+?1GJ5[;A9L=X#B"`HV,*9^`)0G>1QJHK*`C%9MA@BL4]QCRR"K!)*N&=^JW\'EH:KS#0_'0RDK/ MQ;$W]>!4Y'9P[`W']6MFHP(,I]YP.L]*[[LLX6Z'TQ_=/%:)>+^M]7WG;77H M=KZ86RKL:"L^4P^>1!Y"IG*XI<5FFU@+)V]VR?02$IQ.-T^57L5Z0E5)&\8R M.YH0S=0K`[F)X_`T9@J>-(THTG#%,)K;2^+= M5JY*I*CTJ37`B#Z)#3AQ/*Y>SZM>[]X-GQ4/L^SJG<>F;0I!N8ZSPL2+E^7Z M,0%LF/^:!"TN\W,EP)QF!:C&%D4'DKZ_SU.,]9S$,DO8\RP5V3:*1W$:8S$B MWSC&4:TL8^^6]CU;U+RKI8.I]QK(M0\7.8C(ALV1+"(B]A7[7#H63:;\W M:!P>IGRJ[DL>)(!5NM);[M9OY3BOI'0"2AK8^"@?XJQBUAK>;F7\_2)2KD3$ MD`^_";WF4H4KY2UT[<;'=YR18W=2VU#SE719XV*T7-'8[>021R<\SA=0:[ M7E?_ZPUVM[>W*:99(<<1>119*2\QG#2L]NU'1-A]N,F?L7H.-(HY)M@$C4RL6W$7:G+6J]&U7Q9E9MIH7^"`)F4QX?909^N?3+:07"%W7&6%HC@K8B0$#N%$A]DBPR)I?P4 M?!Q5.7*<28&G)BC$I+7TZP*YM-ST((NHL7*F>;S^74AEIWOHRZ:?R'(Q3/AD MI+!N!P'F%.(9ZM'>BUVVP3!SIP_<<[Z`Q*2SJV'G%P@$J' M?^B!%L?@-*>AYJDDBR1S:"I&31,BA#/I-4`:/;K[V"9T0FNE.] M&)EY;`ZPGS@H,1HEMCDN=__V6VSH0IA4H.BQJ*.BE]%G%?K=3FGY)PWTNYTV M]+\"VC?9Q0OP]=M%U?MX`3XMOA;;0<^6.]@)V1ZH)*\3A(&T)0O5M;Q':_2< M.UF9"/3>9A=SSF:V@4XTFSYMG5H&]I!1N=Q&D]8,FO7,#,9:M/;P0?) MRWY."30+S2GG&M)($%4YN%'HJW,,_W3L@?];=UP#:GB*#&-,JQW=S@[O[CS> M5A;5$S;[=]9EOC)E<.ZQ68+VTID>6%-PI M[$AEQ8A=5IV'?DW<9R9OHN5=T%*;3M[A-1N>-=1.Z[H]\#'!.#Y1EUM5^=7X M#!B41Z/5$>E;9XX]$S-,-+FMV>KA*,6V<]ZXPZD7-B)(E;G>P0&L7USBX5[C MG(^<-).,+J((RX[@J06%X?2N;9U]JV^)O>JQ2%4NDD_8F<82OO"<.F.42H7[ M=YL%^&SKK-5-IYP@_#^QV'J_[>/_WZ2SYNM9<=M_#Z>;G3O/=UHQFY^T%F>I MJM'%7,)@SWS88$G"G<.U*(QE#(NO??O!["26^!D$NP*>YT5&CPDBBW0#ZBK? MM%J++3L4MC=2F14(NR?F=F%SA$VX(,K%!$ZO;XX_M;1Z!+D[;^#7,>GD[/K, MI%S)V_+78CC_PZ4'L5K#`L#*3MRJ2PM!_41V5D*R"!&#===^01SX/0>3)"1A M5C]]<33XF&$T4NN=#4_.0;VA\KH)\>;I0QNO] M\F,GXHG?D?%(H"J+_E[GN=AX=2'2O_4O9LKEGZ^.F!L`W#A?V<6MEI1X\^RU M^2L2.M"POF\AF13)"R2-Q64Q7$`@568(\(]7*`4:8>LI1WV0V2`A7P+<.8N^ M%S1F]P]4&W:4B@F_C@BP]##<7$=U-C<)OJFDV: MFK0/-6K/B[E_A&GVDA"N$D^#7"?[&'R1S?8PLT:.'>5O?F'+>:? M\((A9[WP:_4L^M/E#GU5$U?TT]^R?#\(SZ MLGH!R:MJ`I_YG^)JY!K=[\F'&`:8&L7YB#]WA%GL2NDJ]J!!C10;%]6YYK." M.M?EM<6Y_N>\WQOODWFK@G%:W\J-;[NMW-Q_+.?OZRVOEN\OWR\7RRG+9=7]8 M>8\V],\VG11+;N666^GZAL5AA767[V\]O_#A\J]NY>AMUKUXF]TKWL'[+EMB M_"M7[<,QM%2M?M;V%+/C2G*GN#>Y=[@/N`+W'?<[Q_+[^!#_/)_E9_A%_@K/ M,-_R]_@$T:GF9&%P8&@$)IQ)4#4]1:PN@':E`Y+$.D5@6*9IS28ZA+J[H\%` M,'`@B3'@5]8A)L5.@V(ZVRF$8H%=6&07%MV%U5T:%DP02HFU-6.(0EJV M03=`3YDM_P'?UQ&/;H-HX1$40819,[*7U-<`0M`#@XGCT/[B0*(##%U):[X0 M1F%$LZ@C9P!M#ALI`L^"K(T[*6D2$MG*G*F_ MK1->UV@:JT=DRA;5L.9XXOC0`-B.:1H6]?H=#/C((AZQ84)6IGJ"@1&BI["K M6@IZH77[H6P-!@;EK(8IVZ.]N-.=<*BW7AVA2E<'+I"D3JR4F*:F3VZ%66QT MIO:[_DY0B4P=BT!&LVE/C6[M*4V3AZ<9A?90EW0P%HX>CD2.2.%HM+M+ZGAR M9^Q5KQL4R&O>OE(#<$E+/67*(+Z:EJ?)CN3>%/^?M@V"H2B.9?MMPT[7B\/S M:OL+_@502P$"%``4````"``J>6T=BK=047@*``#4(P``"P`````````!`"`` M````````4#@W5$535"Y!4TU02P$"%``4````"``J>6T=3F=P%-(#``"0!0`` M"P```````````"````"A"@``4#@W5$535"Y#3TU02P4&``````(``@!R```` &G`X````` end From wallyr@netcom.com Wed Nov 23 17:14:11 1994 Received: from netcom2.netcom.com for wallyr@netcom.com by www.ccl.net (8.6.9/930601.1506) id QAA03514; Wed, 23 Nov 1994 16:56:40 -0500 Received: by netcom2.netcom.com (8.6.9/Netcom) id NAA29345; Wed, 23 Nov 1994 13:56:51 -0800 From: wallyr@netcom.com (Walter E. Reiher III) Message-Id: <199411232156.NAA29345@netcom2.netcom.com> Subject: Re: CCL:DEFECTIVE PENTIUM FPU'S (2nd try) To: chemistry@ccl.net Date: Wed, 23 Nov 1994 13:56:51 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 10486 Yikes! The attachment wasn't there when I got my copy of the following message I posted a little while ago...it really WAS there when I sent it! Trying again: ======================================================================== Thanks to John McKelvey for informing us of this disturbing problem. I just took a look at comp.sys.intel to learn more about this problem with Pentium chips. There's a lot of flaming going on over there, but to summarize briefly: . It looks like some folks (outside of Intel) have known about this problem for a couple of weeks now. . There are reports of problems with both single- and double-precision division. . Intel has known about it for a while and hasn't told anyone. They have supposedly fixed the problem but did not mark the chips so we can easily tell a chip has the fix just by looking. . I have not seen a report of anyone who actually has CPU with the fix. . The problem was reported on CNN yesterday (I didn't see it). . Reportedly, an Intel spokesman said on CNN that they will NOT simply replace all defective CPUs in the field because they do not consider the problem to be significant. They will replace chips on a case- by-case basis. It looks like THEY will decide if it's important to YOU whether floating point calculations are right or wrong in your Pentium. . Some folks have reported success with reaching Intel Microprocessor Support at 800-628-8686. (I haven't tried yet.) . A statement attributed to Intel (I can't verify this) said: "Concerned users doing extensive floating point operations requiring extraordinary precision who desire further details can call Intel at 408-765-8914." Terje Mathisen of Hydro Data, Norsk Hydro posted a very small program which tells you if your system has the problem. It's pretty obvious... mine says (sigh): "It has the FDIV bug: (1.0/824633702449.0)*824633702449.0 is not equal to 1.0!" He posted his uuencoded program to comp.sys.intel with assembly source. That message is attached. For convenience, I have decoded the program and uploaded the binary file to ftp.ccl.net/incoming/p87test.zip. Download it by binary FTP and use either Info-ZIP's or PKZIP's unzippers to decompress. Wally ======================================================================== Walter E. Reiher III, Ph.D. WallyR@netcom.com Consultant in Computational Chemistry P.O. Box 61056 voice 408-720-0240 Sunnyvale, CA 94088 fax 408-720-0378 >From netcom.com!ix.netcom.com!howland.reston.ans.net!pipex!sunic!trane.uninett.no!eunet.no!nuug!telepost.no!hydro.com!usenet Wed Nov 23 11:20:39 1994 >From: Terje.Mathisen@hda.hydro.com (Terje Mathisen) Newsgroups: comp.sys.intel Subject: FDIV bug: Attempted summary and new p87test Date: 13 Nov 1994 14:39:59 GMT Organization: Hydro Data, Norsk Hydro (Norway) Reply-To: Terje.Mathisen@hda.hydro.com (Terje Mathisen) Since I started this thread, I'd like to summarize my current views on this bug: - *If* Intel have know about this problem for several months, and *decided* not to warn users about it, those responsible for that decision should be fired. There is no excuse for knowing about a silent bug like this, and not tell about it. - An error that results in a hardware crash is much less serious than this one which returns wrong answers. - Since the bit-pattern that fails seems to be about 18 bits long (..11110111000001...), the odds of hitting it should be about 1/2^18, or 1/6E7. With 8 significant digits in the answer, this means that the average (for truly random data) precision on a Pentium is less than 16 digits. - I have nothing against x86 cpu's, rather the opposite, since I love writing asm code for them. The company I work for will still buy new Pentium machines, but as soon as I first heard and verified the problem, I specified that new machines would only be aquired from dealers who promized to exchange the cpus as soon as Intel makes the fixed p5s available. Since I first posted p87test, I've gotten email from people who tell me that it thinks their Pentium-90 is a 386. This will happen if you are running under a V86 monitor which virtualizes the eflags register and disallow toggling the AlignmentControl (bit #18) and/or CPUID (bit #21). The new version will perform the test for FDIV precision independently of cpu version, as long as a numeric coprocessor seems to be present. I have also found a bug in the program, where I demanded that the result after FDIV/FMUL should be identical to 1.0. I have changed this to allow a small ulp error. To make the program more useful, it will now also report (and document) the 'secret' CPUID feature bits, on a Pentium or new-model 486. -Terje Mathisen (include std disclaimer) "almost all programming can be viewed as an exercise in caching" PS. I someone wants to make p87test.zip available on an ftp site, that would probably be the best solution. begin 600 p87test.zip M4$L#!!0``(`(`"IY;1V*MU!1>`H``-0C```+````4#@W5$535"Y!4TW%6GM3 MW#@2_Y\JOD.S1Q6P&.)Y`)-07%A@N>4V/"J09&\IBM+8\HR#Q_)9,@SY]*>6 M[''+XPE)*E7G(C&VU*W6K]\R4%[;$Q'R!%24ED7+S&"K[ MNK/M+R\-BU&:DY>#;G^WU]OSN_W^:QP/XRBB1&_!O?;A>BR*)(0A!W_;!Q8I MGH/B4@LQ6D$I(LY4D?/[8:PDA"&\Q9=!5MQ/Y`C")\OF;.`/IJL>G'4&NWCK MVEO/WOKFIFGB<&=U>2D-,X?X0@SV<)KFL6>)]RSQWBH5((FE0IHH*_3PXX3K M_V,QS!_T/9/XI&2`O^],9*[OO@>3`%\'T\&J%3HW*(1#N^[:%4]57$S@].3L M(V@D(8K3D.?;`.O!!MSP_#.'0I=%Z_[J_52JF8='I>Q_?L_VNK:[B. M!8.L`0(K%&20QJ5+`9`>B1^>G=A=.[;=-["Z?WVJ;W%T[OMTPO MM=HVO8)7Y##D"NVJ2;R\9'1/5SM3,&824@%IF*VXDAD#F9]K8=U#@B9.K;P1 MII;9O46S]0#N(6&XA2;9\A+:HV-6`!UX`Z=7'V#]XN1J`T0:C&.7"JVW0=/5 M-!_C7!4L`8WSN0@Y_#Y5/)6Q2*5#;:W>H>YKZK-7EW"4<_:0B3A5+@DZ2&/! M@2:Y8B,.U_&7A4NA2[ET'5_3W<033:?8)(-C4:0:&'*:TG*X53@$.1G.7)\Y6U9>JSYGTEO`=/L1IKG>I7&>97$ZLF3X]$UD-NO9I?#7U9=H7/TEB<&Y#)JZRXOT$WK%[-"@+?ZWA=K^?UO1VT@N6EBS!;,/5"I-PSP=?# MF.IAJ-Q<7D(1[XW=6Q+?1GJ5[;A9L=X#B"`HV,*9^`)0G>1QJHK*`C%9MA@BL4]QCRR"K!)*N&=^JW\'EH:KS#0_'0RDK/ MQ;$W]>!4Y'9P[`W']6MFHP(,I]YP.L]*[[LLX6Z'TQ_=/%:)>+^M]7WG;77H M=KZ86RKL:"L^4P^>1!Y"IG*XI<5FFU@+)V]VR?02$IQ.-T^57L5Z0E5)&\8R M.YH0S=0K`[F)X_`T9@J>-(THTG#%,)K;2^+= M5JY*I*CTJ37`B#Z)#3AQ/*Y>SZM>[]X-GQ4/L^SJG<>F;0I!N8ZSPL2+E^7Z M,0%LF/^:!"TN\W,EP)QF!:C&%D4'DKZ_SU.,]9S$,DO8\RP5V3:*1W$:8S$B MWSC&4:TL8^^6]CU;U+RKI8.I]QK(M0\7.8C(ALV1+"(B]A7[7#H63:;\W M:!P>IGRJ[DL>)(!5NM);[M9OY3BOI'0"2AK8^"@?XJQBUAK>;F7\_2)2KD3$ MD`^_";WF4H4KY2UT[<;'=YR18W=2VU#SE719XV*T7-'8[>021R<\SA=0:[ M7E?_ZPUVM[>W*:99(<<1>119*2\QG#2L]NU'1-A]N,F?L7H.-(HY)M@$C4RL6W$7:G+6J]&U7Q9E9MIH7^"`)F4QX?909^N?3+:07"%W7&6%HC@K8B0$#N%$A]DBPR)I?P4 M?!Q5.7*<28&G)BC$I+7TZP*YM-ST((NHL7*F>;S^74AEIWOHRZ:?R'(Q3/AD MI+!N!P'F%.(9ZM'>BUVVP3!SIP_<<[Z`Q*2SJV'G%P@$J' M?^B!%L?@-*>AYJDDBR1S:"I&31,BA#/I-4`:/;K[V"9T0FNE.] M&)EY;`ZPGS@H,1HEMCDN=__V6VSH0IA4H.BQJ*.BE]%G%?K=3FGY)PWTNYTV M]+\"VC?9Q0OP]=M%U?MX`3XMOA;;0<^6.]@)V1ZH)*\3A(&T)0O5M;Q':_2< M.UF9"/3>9A=SSF:V@4XTFSYMG5H&]I!1N=Q&D]8,FO7,#,9:M/;P0?) MRWY."30+S2GG&M)($%4YN%'HJW,,_W3L@?];=UP#:GB*#&-,JQW=S@[O[CS> M5A;5$S;[=]9EOC)E<.ZQ68+VTID>6%-PI M[$AEQ8A=5IV'?DW<9R9OHN5=T%*;3M[A-1N>-=1.Z[H]\#'!.#Y1EUM5^=7X M#!B41Z/5$>E;9XX]$S-,-+FMV>KA*,6V<]ZXPZD7-B)(E;G>P0&L7USBX5[C MG(^<-).,+J((RX[@J06%X?2N;9U]JV^)O>JQ2%4NDD_8F<82OO"<.F.42H7[ M=YL%^&SKK-5-IYP@_#^QV'J_[>/_WZ2SYNM9<=M_#Z>;G3O/=UHQFY^T%F>I MJM'%7,)@SWS88$G"G<.U*(QE#(NO??O!["26^!D$NP*>YT5&CPDBBW0#ZBK? MM%J++3L4MC=2F14(NR?F=F%SA$VX(,K%!$ZO;XX_M;1Z!+D[;^#7,>GD[/K, MI%S)V_+78CC_PZ4'L5K#`L#*3MRJ2PM!_41V5D*R"!&#===^01SX/0>3)"1A M5C]]<33XF&$T4NN=#4_.0;VA\KH)\>;I0QNO] M\F,GXHG?D?%(H"J+_E[GN=AX=2'2O_4O9LKEGZ^.F!L`W#A?V<6MEI1X\^RU M^2L2.M"POF\AF13)"R2-Q64Q7$`@568(\(]7*`4:8>LI1WV0V2`A7P+<.8N^ M%S1F]P]4&W:4B@F_C@BP]##<7$=U-C<)OJFDV: MFK0/-6K/B[E_A&GVDA"N$D^#7"?[&'R1S?8PLT:.'>5O?F'+>:? M\((A9[WP:_4L^M/E#GU5$U?TT]^R?#\(SZ MLGH!R:MJ`I_YG^)JY!K=[\F'&`:8&L7YB#]WA%GL2NDJ]J!!C10;%]6YYK." M.M?EM<6Y_N>\WQOODWFK@G%:W\J-;[NMW-Q_+.?OZRVOEN\OWR\7RRG+9=7]8 M>8\V],\VG11+;N666^GZAL5AA767[V\]O_#A\J]NY>AMUKUXF]TKWL'[+EMB M_"M7[<,QM%2M?M;V%+/C2G*GN#>Y=[@/N`+W'?<[Q_+[^!#_/)_E9_A%_@K/ M,-_R]_@$T:GF9&%P8&@$)IQ)4#4]1:PN@':E`Y+$.D5@6*9IS28ZA+J[H\%` M,'`@B3'@5]8A)L5.@V(ZVRF$8H%=6&07%MV%U5T:%DP02HFU-6.(0EJV M03=`3YDM_P'?UQ&/;H-HX1$40819,[*7U-<`0M`#@XGCT/[B0*(##%U):[X0 M1F%$LZ@C9P!M#ALI`L^"K(T[*6D2$MG*G*F_ MK1->UV@:JT=DRA;5L.9XXOC0`-B.:1H6]?H=#/C((AZQ84)6IGJ"@1&BI["K M6@IZH77[H6P-!@;EK(8IVZ.]N-.=<*BW7AVA2E<'+I"D3JR4F*:F3VZ%66QT MIO:[_DY0B4P=BT!&LVE/C6[M*4V3AZ<9A?90EW0P%HX>CD2.2.%HM+M+ZGAR M9^Q5KQL4R&O>OE(#<$E+/67*(+Z:EJ?)CN3>%/^?M@V"H2B.9?MMPT[7B\/S M:OL+_@502P$"%``4````"``J>6T=BK=047@*``#4(P``"P`````````!`"`` M````````4#@W5$535"Y!4TU02P$"%``4````"``J>6T=3F=P%-(#``"0!0`` M"P```````````"````"A"@``4#@W5$535"Y#3TU02P4&``````(``@!R```` &G`X````` end