Received: by CLI.COM (4.1/1); Tue, 3 Sep 91 17:24:02 CDT Date: Tue, 3 Sep 91 17:24:02 CDT From: Ron Olphie Message-Id: <9109032224.AA04698@CLI.COM> To: nqthm-users, weberwu%inf.fu-berlin.de@unido.informatik.uni-dortmund.de Subject: Welcome Hi Debbie, nqthm-users and nqthm-users-request are setup on cli. I have added Bob Boyer and J Moore to the list. Please note the request mailing address is different than you requested nqthm-users-request. I have setup and archive available via anonymous ftp to cli.com. The file is pub/nqthm/nqthm-users-mail-archive. I'll have to hack our sendmail configuration file to accomplish your request that messages originating from inf.fu-berlin.de. This will take a couple of days so you may not want to activate the list yet. Go ahead and test the nqthm-users-request@cli.com. Ron Received: by CLI.COM (4.1/1); Wed, 4 Sep 91 06:26:24 CDT Date: Wed, 4 Sep 91 06:26:24 CDT From: Ron Olphie Message-Id: <9109041126.AA08060@CLI.COM> To: nqthm-users Subject: nqthm-users Hi Debbie, The exact names are: nqthm-users nqthm-users-request I made the change for your list (nqthm-users-cli) and I am hoping this message will serve as a test. I'll send you ftp instructions for the mail archive when I get to work in a few hours. Thanks, Ron Received: by CLI.COM (4.1/1); Wed, 4 Sep 91 08:45:41 CDT Received: from fubinf by unido.informatik.uni-dortmund.de with UUCP (5.65+/UNIDO-2.0.4.d) via EUnet for cli.com id AA13672; Wed, 4 Sep 91 14:10:11 +0200 Received: from unido.UUCP by inf.fu-berlin.de (4.1/SMI-4.1) id AA16686; Wed, 4 Sep 91 13:43:50 +0200 Received: from cli.com by unido.informatik.uni-dortmund.de with SMTP (5.65+/UNIDO-2.0.4.d) via EUnet for fubinf id AA09212; Wed, 4 Sep 91 13:28:19 +0200 Received: by CLI.COM (4.1/1); Tue, 3 Sep 91 17:24:02 CDT Date: Tue, 3 Sep 91 17:24:02 CDT From: Ron Olphie Message-Id: <9109032224.AA04698@CLI.COM> To: nqthm-users@CLI.COM, fubinf!weberwu Subject: Welcome Hi Debbie, nqthm-users and nqthm-users-request are setup on cli. I have added Bob Boyer and J Moore to the list. Please note the request mailing address is different than you requested nqthm-users-request. I have setup and archive available via anonymous ftp to cli.com. The file is pub/nqthm/nqthm-users-mail-archive. I'll have to hack our sendmail configuration file to accomplish your request that messages originating from inf.fu-berlin.de. This will take a couple of days so you may not want to activate the list yet. Go ahead and test the nqthm-users-request@cli.com. Ron Received: by CLI.COM (4.1/1); Sun, 8 Sep 91 05:20:42 CDT Received: from fubinf.inf.fu-berlin.de by unido.informatik.uni-dortmund.de with SMTP (5.65+/UNIDO-2.0.4.d) via EUnet for cli.com id AA24406; Sun, 8 Sep 91 12:21:17 +0200 Received: from ortler.inf.fu-berlin.de by inf.fu-berlin.de (4.1/SMI-4.1) id AA29385; Sun, 8 Sep 91 12:24:35 +0200 Date: Sun, 8 Sep 91 12:24:34 +0200 From: weberwu@inf.fu-berlin.de (Debora Weber-Wulff) Message-Id: <9109081024.AA29385@inf.fu-berlin.de> To: nqthm-users@cli.com Subject: test of nqthm-users Hi! This is the first test of the nqthm-users mailing list alias. Sorry for the disturbance, please disregard! Debbie Weber-Wulff Received: by CLI.COM (4.1/1); Sun, 8 Sep 91 08:01:35 CDT Received: from fubinf.inf.fu-berlin.de by unido.informatik.uni-dortmund.de with SMTP (5.65+/UNIDO-2.0.4.d) via EUnet for cli.com id AA00531; Sun, 8 Sep 91 15:01:07 +0200 Received: from ortler.inf.fu-berlin.de by inf.fu-berlin.de (4.1/SMI-4.1) id AA29613; Sun, 8 Sep 91 15:04:19 +0200 Date: Sun, 8 Sep 91 15:04:19 +0200 From: weberwu@inf.fu-berlin.de (Debora Weber-Wulff) Message-Id: <9109081304.AA29613@inf.fu-berlin.de> To: dww@inf.fu-berlin.de Subject: A mailing list for the Boyer-Moore prover Got the NQTHM blues? Found a new way to coax NQTHM to assent to the obvious? Curious about the people and projects that use the Boyer-Moore prover? Sign up for the nqthm-users mailing list! We want the mailing list to be a forum for asking for help, for collecting lore on the use of the prover, for finding nice little examples to use in teaching, and for hearing about proofs large and small that have been done with the assistance of NQTHM. It has been suggested that you might be interested in joining this group. Please note that you will only be included on the list if you send a message to one of the nqthm-request addresses below. We have set up an address at Computational Logic, Inc in Texas and one at the Free University of Berlin in Germany. If you are interested in joining, drop a line to the address nearest you: nqthm-users-request@cli.com nqthm-users-request@inf.fu-berlin.de If you have further questions, contact me at dww@inf.fu-berlin.de Debbie Weber-Wulff Free University Institut fuer Informatik Nestorstr. 8-9 D-1000 Berlin 31 Received: by CLI.COM (4.1/1); Mon, 9 Sep 91 11:37:32 CDT Date: Mon, 9 Sep 91 11:37:32 CDT From: Ron Olphie Message-Id: <9109091637.AA05023@CLI.COM> To: nqthm@cli.com Subject: nqthm-users mailing list All, Debbie Weber-Wulff has started an nqthm-users mailing list. Cli will handle the non-European request and Berlin will handle the European requests. If you would like to be on this list, please reply to this message. Ron Received: by CLI.COM (4.1/1); Tue, 10 Sep 91 03:09:19 CDT Received: from fubinf.inf.fu-berlin.de by unido.informatik.uni-dortmund.de with SMTP (5.65+/UNIDO-2.0.4.d) via EUnet for cli.com id AA19993; Tue, 10 Sep 91 10:06:21 +0200 Received: from client4_6.inf.fu-berlin.de by inf.fu-berlin.de (4.1/SMI-4.1) id AA05329; Tue, 10 Sep 91 10:08:05 +0200 Date: Tue, 10 Sep 91 10:08:04 +0200 From: weberwu@inf.fu-berlin.de (Debora Weber-Wulff) Message-Id: <9109100808.AA05329@inf.fu-berlin.de> To: nqthm-users@inf.fu-berlin.de Subject: "pass collapsing" I'm glad there are so many people interested in nqthm-users! We had almost 50 addresses at the last count. I'd like to try and kick off a "lore" discussion with a brief description of a technique Bill Bevier and I used during my visit at CLInc this summer. We called it "pass collapsing". We were working on a proof deep in my parser which had degenerated into a large number of "major" passes, each with a number of minor passes. Compiler writers tend to avoid splitting off passes, but it was quite advantageous to the proof to concentrate on just doing one little thing in each pass. One of the major passes that had been proven correct with respect to our specifications was the composition of four functions: (fiddle4 (fiddle3 (fiddle2 (fiddle1 ...)))). We decided to try and discover a function that would take all four steps in one pass, and to prove that it had the same effect as the composition. We started collapsing fiddle3 and fiddle2, as they had the same case split structure: (DEFN FIDDLE-X (L) (IF (NLISTP L) (...) (IF (IS-INDENTATION (CAR L)) (CONS (TWADDLE (CAR L) ...) (FIDDLE-X (CDR L) ...)) (CONS (CAR L) (FIDDLE-X (CDR L) ...)))) We chose fiddle3 as the basic function and where it accessed (CAR L) we substituted the twaddling term from fiddle2, sort of like a copy-rule. It was easy to prove that fiddle3-fiddle2 was equal to (fiddle3 (fiddle2 ...)). Fiddle1 had a more complex case structure, and needed another lemma concerning the effect of fiddle2 before we could prove that function fiddle3-fiddle2-fiddle1 was the same as the 3-function composition. The last function turned out to be a "proof facilitation" function, it was a function to flatten out one list level - to prove our specification correct about fiddle3 we had needed some list structuring that was not needed further out. This simplified our function somewhat, and was easy to prove equal to the original composition. So we had collapsed 4 functions into 1, resulting in a function that we would have *never* written directly in that style, but that we could prove to comply with our specifications! Has anyone else tried this sort of thing? Do you have any suggestions on collapsing passes that don't fit together too well on their case structure? ----- Debora Weber-Wulff dww@inf.fu-berlin.de Institut fuer Informatik Nestorstr. 8-9 D-W-1000 Berlin 31 Received: by CLI.COM (4.1/1); Tue, 10 Sep 91 23:23:41 CDT Received: by centralsparc.Berkeley.EDU (4.1/1.42) id AA10266; Tue, 10 Sep 91 21:27:23 PDT Date: Tue, 10 Sep 91 21:27:23 PDT From: dooley@centralsparc.Berkeley.EDU (Sam Dooley) Message-Id: <9109110427.AA10266@centralsparc.Berkeley.EDU> To: boyer@cli.com, kaufmann@cli.com, nqthm-users@cli.com Subject: Re: Common Lisp Help Cc: dooley@centralsparc.Berkeley.EDU, langevin@iro.umontreal.ca >Below is a problem reported by an Nqthm user who might be helped by >someone on this list. I think that the problem is that the Common >Lisp being used is attempting to comply with Steele's CLTL2 in a way >that breaks Nqthm, in particular the SLOOP subsystem of Bill Schelter, >which implements a version of the MIT-Loop package. Not having the >Lisp in question, I'm not sure exactly what to do. There may be a >really trivial fix. Allegro 4.x does attempt to comply with the evolving X3J13 standardization effort for CL as described in CLTL2 and other documents. Notable changes that affect compatibility with older Lisps include the depreciation of provide and require, and the redefinition of in-package as a macro (whose argument is no longer evaluated, which no longer allows the keyword :use, and which no longer creates a new package). A newer version of Bill Schelter's sloop package is also used in his implementation of Common Lisp Maxima (a derivative of DOE Macsyma); minor changes to that version of sloop allow it to compile successfully under Allegro, after which Nqthm works just fine. I will send the modifications to sloop directly to Michel Langevin; if anyone else is interested send me email and I will send them to you as well. Sam Dooley dooley@cs.Berkeley.EDU From boyer Tue Sep 10 20:36:07 1991 Received: by CLI.COM (4.1/1); Tue, 10 Sep 91 20:36:03 CDT Date: Tue, 10 Sep 91 20:36:03 CDT From: Robert S. Boyer Message-Id: <9109110136.AA12119@CLI.COM> To: nqthm-users Cc: langevin@iro.umontreal.ca Subject: Common Lisp Help Reply-To: boyer@cli.com Status: R Below is a problem reported by an Nqthm user who might be helped by someone on this list. I think that the problem is that the Common Lisp being used is attempting to comply with Steele's CLTL2 in a way that breaks Nqthm, in particular the SLOOP subsystem of Bill Schelter, which implements a version of the MIT-Loop package. Not having the Lisp in question, I'm not sure exactly what to do. There may be a really trivial fix. Date: Tue, 10 Sep 91 16:27:54 CDT From: Matt Kaufmann To: boyer@CLI.COM Subject: [langevin@iro.umontreal.ca: problem with Allegro CL] Hi, Bob -- Here is a problem that's news to me. I realize that there's an allegro-patch file, but its contents didn't seem relevant to the problem reported below. Rather, I suspect that the problem was with the form (in-package "SLOOP" :use '(LISP)) in the file sloop.lisp (though the warning message above that is also weird). Any comments? -- Matt Return-Path: From: langevin@iro.umontreal.ca (Michel Langevin) Date: Tue, 10 Sep 1991 17:20:18 EDT X-Mailer: Mail User's Shell (7.1.2 7/11/90) To: Matt Kaufmann Subject: problem with Allegro CL Hello Matt, I have try to compile "nqthm.lisp" in Allegro Common Lisp 4.0.1 [Sun4] and I received this message: -------------------------------------------------------------------------- (load "nqthm.lisp") ; Loading /tmp_mnt/net/iros6/langevin/lisp/boyer-moore/nqthm/nqthm.lisp. Warning: in-package argument should not be quoted: 'USER T (load-nqthm) ; Loading /tmp_mnt/net/iros6/langevin/lisp/boyer-moore/nqthm/sloop.lisp. Error: In-package may not modify an existing package; use defpackage instead. Restart actions (select using :continue): 0: Modify the package anyway. (See *cltl1-in-package-compatibility-p*) 1: retry the load of sloop [1c] -------------------------------------------------------------------------- Is it a problem of Allegro Common Lisp or it's something not correct that I do? It is more safe to use KCL? [... I've omitted the rest ...] From boyer Wed Sep 11 18:50:00 1991 Received: by CLI.COM (4.1/1); Wed, 11 Sep 91 18:49:56 CDT Date: Wed, 11 Sep 91 18:49:56 CDT From: Robert S. Boyer Message-Id: <9109112349.AA18322@CLI.COM> To: nqthm-users Subject: How to Get Nqthm Reply-To: boyer@cli.com Status: RO You can obtain Boyer and Moore's prover Nqthm, which is documented in their book ``A Computational Logic Handbook'' (Academic Press, 1988), through anonymous ftp from cli.com. Ftp to cli.com, login as anonymous, any password, cd to /pub/nqthm, get the file README, and follow the directions therein. There is no charge for Nqthm if you obtain it by ftp. For information about getting a tape, ask Ron Olphie, olphie@cli.com, or Laura Tice, tice@cli.com. Or write to them at Computational Logic, Inc., Suite 290, 1717 W. 6th St., Austin, Texas 78712. There is a charge for tapes. Bob Boyer From boyer Wed Sep 11 21:07:43 1991 Received: by CLI.COM (4.1/1); Wed, 11 Sep 91 21:07:40 CDT Date: Wed, 11 Sep 91 21:07:40 CDT From: Robert S. Boyer Message-Id: <9109120207.AA18740@CLI.COM> To: nqthm-users@cli.com Subject: Bledsoe Symposium Announcement Reply-To: boyer@cli.com Status: RO The University of Texas at Austin Department of Computer Sciences presents The 4th Annual FRONTIERS IN COMPUTING: Symposium Honoring Professor W. W. Bledsoe November 15 - 16, 1991 Joe C. Thompson Conference Center Austin, Texas, USA SPEAKERS: Saul Amarel Wolfgang Bibel Hans J. Bremermann Alan Bundy Lawrence J. Henschen Ken Kunen Vladimir Lifschitz Donald Loveland R. Daniel Mauldin John McCarthy J Strother Moore Ross Overbeek Raj Reddy Raymond Reiter Michael M. Richter J. A. Robinson Mark Stickel SCHEDULE: - FRIDAY, November 15, 1991 9:00 a.m. Welcoming Address William H. Cunningham, President The University of Texas at Austin 9:15 a.m. The Use of Proof Plans for Normalization Alan Bundy, Professor University of Edinburgh, Scotland 10:00 a.m. Resolution Completeness Proofs Ken Kunen, Professor University of Wisconsin 10:45 a.m. Coffee Break 11:00 a.m. What are the Limitations of the Situation Calculus? Vladimir Lifschitz, Professor The University of Texas at Austin 11:45 a.m. The Meteor Implementation of Model Elimination with Lemmas Donald W. Loveland, Professor Duke University 12:30 p.m. Lunch Break 1:30 p.m. Similarity, Uncertainty and Case-Based Reasoning Michael M. Richter, Professor University of Kaiserslautern, Germany Scientific Director German Research Institute for Artificial Intelligence 2:15 p.m. Aligning Multiple RNA Sequences Ross Overbeek, Senior Research Scientist Argonne National Laboratory 3:00 p.m. Coffee Break 3:15 p.m. Nature of Scientific Experiments in Computer Science: Experiences from Speech Understanding Systems Research Raj Reddy, Professor & Director of the Robotics Institute Carnegie Mellon University 4:00 p.m. An Example of the Computer as an Experimental Tool R. Daniel Mauldin, Professor University of North Texas 7:00 p.m. Banquet, The Driskill Hotel - SATURDAY, November 16, 1991 9:00 a.m. Problem Solving in AI; Issues in Problem Representation Saul Amarel, Professor Rutgers University 9:45 a.m. Formal Proofs About Computing Machines J Strother Moore, Senior Research Scientist Computational Logic, Inc. 10:30 a.m. Coffee Break 10:45 a.m. Reasoning About Theories in the Situation Calculus Raymond Reiter, Professor University of Toronto, Canada 11:30 a.m. Reasoning in Paraconsistent Logics (with James Lu) & Compiling Recursive Functional Prolog Programs with List Structure into Procedural Languages (with Youngkwan Nam) Lawrence J. Henschen, Professor Northwestern University 12:15 p.m. Lunch Break 1:15 p.m. Proving Program Specifications: Generalities and Examples John McCarthy, Professor Stanford University 2:00 p.m. How the Brain Adjusts Synapses - Maybe (with R.W. Anderson) Hans J. Bremermann, Professor University of California at Berkeley 2:45 p.m. Coffee Break 3:00 p.m. Formal and Informal Proofs J. A. Robinson, Professor Syracuse University 3:45 p.m. Perspectives on Automated Deduction Wolfgang Bibel, Professor Technical University Darmstadt, Germany 4:30 p.m. New Ways of Implementing and Using the Model Elimination Theorem-Proving Procedure Mark Stickel, Principal Scientist SRI International SPONSORED BY: National Science Foundation Computer Science Industrial Associates Program Ricoh California Research Center Alfred and Ellen King Centennial Lectureship Microelectronics and Computer Technology Corporation Computational Logic, Inc. Electronic Data Systems Corporation GENERAL INFORMATION: Reservations: - The Symposium is FREE OF CHARGE. Seating is limited, however, so registration in advance is required. Registration deadline is October 15. - There will be a banquet on Friday evening, November 15, 7:00 - 9:00 p.m., at The Driskill Hotel, in honor of Professor Bledsoe. There is a non-refundable $25/person charge to attend the banquet (see Registration Form). The banquet is an optional event which participants may choose to attend. Locations: - The Symposium will meet in the Joe C. Thompson Conference Center (TCC), in Austin, TX. The TCC is located one block west of IH-35 at the 26th St. exit, on the southwest corner of 26th and Red River Streets, immediately north of the Lyndon B. Johnson Presidential Library and Museum. - While attending the conference, emergency message may be left for participants at (512) 471-3123. - Free parking is available in a lot adjacent to the TCC, accessible from Red River Street. Please inform the guard you will be attending the "Frontiers in Computing Symposium" at the TCC. - Robert Mueller Municipal Airport is located within 10 minutes of the Thompson Conference Center and 15 minutes of downtown Austin. A map follows the Registration Form. Travel: - Because a University football game is scheduled for Saturday afternoon, November 16, it is advisable to make travel and hotel reservations as soon as possible. On the day of the game, local traffic will be slower than usual. For that reason, it is important to allow extra time for traveling to the airport on Saturday afternoon. The optional catered lunch at the TCC at noon on Saturday is recommended since nearby restaurants will likely be crowded (see Registration Form). - A modest amount of financial support is available to help defray travel expenses for graduate students. Requests for support should be sent by October 1 to Joanne Click and should include a curriculum vitae (see address Registration Form). Accommodations: - Participants are responsible for their own meals. At noon on Friday, participants may choose to eat in the TCC cafeteria or go to nearby restaurants. On Friday evening, an optional banquet will be held at The Driskill Hotel for $25/person, payable in advance (see Registration Form). At noon on Saturday, participants may select the optional catered barbecue for $10/person, payable in advance (see Registration Form). The catered barbecue is recommended due to crowding of local restaurants by fans at the nearby football stadium. - For overnight accommodations, contact The Driskill Hotel as soon as possible. A block of rooms is available on a first come-first served basis. A special rate of $55/night single or double is available to those attending the "UT Frontiers in Computing Symposium." The Driskill Hotel is located at 6th and Brazos Streets. Reservations: (512) 474- 5911 or (800) 252-9367. The Driskill provides courtesy transportation to and from the airport between the hours of 7:00 a.m. and 11:00 p.m., 7 days a week. Taxi service is available after-hours. Austin, Texas: - By mid-November, the excruciating heat of August has long passed from Austin, and one can at least hope for warm, clear days with mild nights. But in the worst case, a "blue norther" may sweep down from the Arctic, freezing everything in its path. For Further Information: - To register, or for further information, please contact: Joanne W. Click, Coordinator Office of External Affairs Department of Computer Sciences The University of Texas at Austin Austin, TX 78712-1188 Tel. - (512) 471-9729; Fax - (512) 471-7866 or -8885 Internet: click@cs.utexas.edu REGISTRATION FORM: Name: _______________________________________________________________________ Affiliation: ________________________________________________________________ Mailing Address: ____________________________________________________________ _____________________________________________________________________________ Net Address: ________________________________________________________________ Daytime Phone: ______________________________________________________________ _________ Yes, I plan to attend the banquet on Friday evening, November 15, at The Driskill Hotel. Enclosed is a non-refundable payment of $25/person, made payable to The University of Texas at Austin. _____ I request a vegetarian plate at the banquet. _____ I request a kosher plate at the banquet. --------- Yes, I plan to attend the catered barbecue luncheon at noon on Saturday, November 16, at the Thompson Conference Center. Enclosed is a non-refundable payment of $10/person, made payable to The University of Texas at Austin. MAPS: Up is approximately EAST on both maps. -------------- | | | | | | Airport |__| | | | | | | -------------- | Manor Road | | | | | | | | | | MLK Blvd. | | | ___________________|_________|____________________________________|__________ ------------------|-----------|---- IH-35 ----------------------|---------- | | | 26th St. Manor Rd. | | | ----------------------------------|-------- Red River ------------|---------- | | / \ | | | | | Parking | | | | | | | | | | ------- ------- | | | | | | TCC | | LBJ | | | | | | ------- ------- | | | -------------------------- East Campus Drive - | | | MLK Blvd. | 23rd St. | | | --------- | | | / -------- | 26th St. | || | | | || stadium | | | \ --------- |--Trinity- | | ---------- / | ----------------|---- San Jacinto --------------------------------|---------- | | TCC = Joe C. Thompson Conf. Ctr. ____|_______________________________________________|____________________|___| ----|-------------- IH-35 ------------------------|--------------------|---| 12th St. 6th St. | | ----|-------------------------- Red River ----------|------ | | | | | | ----|-------------------------- Neches -------------|--------- | | | | | | ----|-------------------------- Trinity ------------|---------- | | | | | R | ----|-------------------------- San Jacinto --------|------- | | | | | I | ----|-------------------------- Brazos -------------|--------- | | | The | | V | | Driskill | | | /--\ 6th St. | E | --| |------Congress Ave.-------------------------|--------------------|---| \__/ | | R | | | From weberwu@inf.fu-berlin.de Wed Sep 18 03:27:11 1991 Received: by CLI.COM (4.1/1); Wed, 18 Sep 91 03:26:13 CDT Received: from fubinf.inf.fu-berlin.de by unido.informatik.uni-dortmund.de with SMTP (5.65+/UNIDO-2.0.4.d) via EUnet for cli.com id AA10425; Wed, 18 Sep 91 10:24:02 +0200 Received: from client4_6.inf.fu-berlin.de by inf.fu-berlin.de (4.1/SMI-4.1) id AA24201; Wed, 18 Sep 91 10:26:47 +0200 Date: Wed, 18 Sep 91 10:26:47 +0200 From: weberwu@inf.fu-berlin.de (Debora Weber-Wulff) Message-Id: <9109180826.AA24201@inf.fu-berlin.de> To: nqthm-users@inf.fu-berlin.de Subject: Construction of a 3-element ordinal measure Status: R A question for those of you who have experience convincing NQTHM that your functions really do terminate: I have a function (FOO list stack partialset fullset) that I believe really does terminate. On each recursive call either: 1) the head of the list gets pushed to the stack and the partial set is reset to the full set 2) the top n elements, n >=1 get replaced by one element 3) if n=1, then an element is removed from the partial set. (Yes, it's a parsing problem!) Let l = length of the list d = depth of the stack s = partial set size I thought, naively, that the ordinal (l d . s) would be a wonderful measure: l always decreases, d and s only get larger when l decreases, that seemed like a lexicographic ordering. But the prover rebels (exactly as is stated on page 42 of the handbook), as it can't prove that l is always greater than d - that is not the case. So I've been experimenting with different ordinals ((l . d) . s), (((l . 0) . d) . s), getting extremely complex reasons why the definition is rejected, and I realize that I don't really understand the ordinal concept. I've used the lexicographic ordering with pairs before, that worked. Does anyone have an idea how to construct this measure, and/or can explain ordinal ordering to me? I'd be much obliged! Another question: what do you folks out there that use nqthm use it for? Hardware proofs? Software proofs? Strengthing your frustration tolerance? I'm curious! ----- Debora Weber-Wulff dww@inf.fu-berlin.de Institut fuer Informatik Nestorstr. 8-9 D-W-1000 Berlin 31 From kaufmann@CLI.COM Wed Sep 18 09:33:19 1991 Received: by CLI.COM (4.1/1); Wed, 18 Sep 91 09:33:09 CDT Date: Wed, 18 Sep 91 09:35:30 CDT From: Matt Kaufmann Message-Id: <9109181435.AA04710@client12.CLI.COM> Received: by client12.CLI.COM (4.1/CLI-1.2) id AA04710; Wed, 18 Sep 91 09:35:30 CDT To: nqthm-users@CLI.COM Subject: interactive enhancement Status: R For those of you who don't know.... for several years now there has been an interactive enhancement of the Boyer-Moore `nqthm' prover. (It also gives rudimentary support for full first-order quantification.) As with nqthm, this `pc-nqthm' (Proof-Checker Nqthm) system is publicly available by ftp (and available for a fee on tape). Here's the standard announcement....... A Common Lisp version of an enhancement to the Boyer-Moore theorem-prover that provides interactive capabilities and first-order quantification is now available under the usual conditions: no license, no copyright, no fee, no support. The system runs well in at least three Common Lisps: AKCL, Symbolics, and Lucid. There are no operating system or dialect conditionals, so the code may well run in other implementations of Common Lisp. However, it is important that your Common Lisp supports redefinition of functions. For example, KCL (as opposed to AKCL) is not acceptable. Before bothering to get a copy, first get a copy of the Boyer-Moore theorem-prover. Then, to get a copy of the interactive enhancement, follow these instructions: To get a copy follow these instructions: 1. ftp to Internet host cli.com. (cli.com currently has Internet number 192.31.85.1) 2. log in as ftp, password guest 3. get the file /pub/proof-checker/README-pc 4. read the file README-pc and follow the directions it gives. Inquiries concerning tapes may be sent to: Computational Logic, Inc., Suite 290 1717 W. 6th St. Austin, Texas 78703 A carefully written user's manual is available. For information on obtaining a copy, write to me at the address above. Matt Kaufmann kaufmann@cli.com Received: by CLI.COM (4.1/1); Wed, 2 Oct 91 02:45:04 CDT Message-Id: <9110020745.AA18316@CLI.COM> Received: from HAIFASC3 by vnet.ibm.com (IBM VM SMTP V2R1) with BSMTP id 8409; Wed, 02 Oct 91 03:44:20 EDT Date: Wed, 2 Oct 91 09:45:22 IDT From: "Sergio Fogel" To: nqthm-users@CLI.COM Subject: Problems with compile-nqthm I am trying to install nqthm on our IBM Risc/6000 machine, using akcl. When I run compile-nqthm, the C compiler has trouble dealing with code-nr.lisp (it begins to eat up swap space until the process is killed; it takes as much as 80-90 Mbytes). Is there any way of splitting this file into smaller pieces? If so, what other modifications should I make? Any help will be greately appreciated. Sergio Fogel Advanced VLSI Design Verification IBM - Haifa Research Group. Received: by CLI.COM (4.1/1); Wed, 2 Oct 91 08:30:20 CDT Date: Wed, 2 Oct 91 08:30:20 CDT From: Robert S. Boyer Message-Id: <9110021330.AA19671@CLI.COM> To: fogel@haifasc3.vnet.ibm.com Cc: nqthm-users@CLI.COM Subject: Problems with compile-nqthm Reply-To: boyer@cli.com I believe you should be able to get AKCL to do the splitting for you automatically. AKCL, when running on a RISC, sometimes produces huge intermediate files. For example, in the case of a SPARC, I have seen intermediate files tie up space equal to 60 times the size of the input. There is a feature in AKCL for automatic splitting of files during compilation. The following text is from the file doc/DOC: *SPLIT-FILES* Variable in the COMPILER package: This affects the behaviour of compile-file, and is useful for cases where the C compiler cannot handle large C files resulting from lisp compilation. This scheme should allow arbitrarily long lisp files to be compiled. If the value [default NIL] is a positive integer, then the source file will be compiled into several object files whose names have 0,1,2,.. prepended, and which will be loaded by the main object file. File 0 will contain compilation of top level forms thru position *split-files* in the lisp source file, and file 1 the next forms, etc. Thus a 180k file would probably result in three object files (plus the master object file of the same name) if *split-files* was set to 60000. The package information will be inserted in each file. Bob Received: by CLI.COM (4.1/1); Sun, 20 Oct 91 12:33:46 CDT Date: Sun, 20 Oct 91 12:33:46 CDT From: Robert S. Boyer Message-Id: <9110201733.AA25652@CLI.COM> To: nqthm-users@cli.com Cc: ram@cs.cmu.edu Subject: cmulisp and Nqthm This note is a report on the use of Nqthm (the Boyer-Moore prover) under the beta release of cmulisp, a public domain Common Lisp that has recently been released. I wanted to see what would happen compiling the now 3-years-old, released Nqthm sources under cmulisp, which incorporates some CLTL2 features. (cmulisp may be entirely CLTL2 compatible for all I know.) Information on how to get cmulisp may be found at the very end of this message. *HURRAY and THANKS* to CMU for building and distributing a public domain Common Lisp. Summary. To happily use Nqthm (the one and only released version, the one available by anonymous ftp from cli.com) under cmulisp, it suffices to do the two following extra things: a. Immediately after each call of (load "nqthm.lisp") (i.e., during installation, both compilation and loading) execute (defun provide (x) x) b. Immediately after each call of (load-nqthm) (i.e., during loading), execute (load "allegro-patch.lisp"). If you don't understand when or where you are supposed to execute (load "nqthm.lisp") or (load-nqthm), see the installation instructions for Nqthm, either in the users manual (the book "A Computational Logic Handbook", Boyer and Moore, Academic Press) or the file installation.guide distributed with the Nqthm sources. I have only run Nqthm through the first main ``proveall'' in basic.events, but that's a pretty lengthy test. ** DETAILS worth ignoring ** Here are some detailed reports on the very few dubious matters encoutered during compilation, which required the foregoing deviations from the standard Nqthm operating instructions. ** COMPILE-UNCOMPILED-DEFNS ** The line (COMPILE-FILE FN-FILE) should really be (COMPILE-FILE FN-FILE-NAME) because FN-FILE is a stream, but COMPILE-FILE in cmulisp wants somethingd else better, e.g., a string or symbol. Some Lisps are willing to extract the name from a stream, but not cmulisp. This error has previously raised its head, and is already fixed by the file allegro-patch.lisp, now distributed with Nqthm. Also, this patch causes files created by COMPILE-UNCOMPILED-DEFNS to be smashed even if they exist, as one probably hopes, rather than the ``tender'' default treatment that cmulisp uses, and which may be the CLTL2 default for all I know. ** SLOOP problems ** Sloop is Bill Schelter's excellent version of the MIT Loop macro. Sloop is distributed with Nqthm. Since something like the MIT Loop macro has become standard with CLTL2/ANSI, perhaps eventually we should cause Nqthm to use the default LOOP. But to retain CLTL1 compatibility, or even consistent Nqthm behavior, that may be a bad idea. For all I know, these problems are solved in later versions of sloop. ** PROVIDE is a function that is flushed by CLTL2 and presumably the final ANSI standard. A call to PROVIDE is found in the file sloop.lisp distributed with Nqthm. One possible fix is just to delete the line that contains the call to PROVIDE. This would retain CLTL1 compatibility. However, I have suggested the silly idea of doing a (defun provide (x) nil) in my instructions above just to avoid anyone having to commit the venial sin of violating Schelter's prohibition against changing the sloop.lisp sources. ** Here are some presumably inconsequential sloop compilation errors. In: DEFUN MAKE-NEW-NAME (ITERATE FOR I FROM 1 ...) --> SLOOP:SLOOP LET MACROLET BLOCK ==> (TAGBODY SLOOP::NEXT-LOOP (OR (NULL #) (SLOOP:LOCAL-FINISH)) NIL (OR (< I 536870910) (TYPE-ERROR)) ...) Error: Repeated tagbody tag: NIL. In: DEFUN MAKE-NEW-NAME (ITERATE FOR I FROM 1 ...) --> SLOOP:SLOOP LET MACROLET BLOCK ==> (TAGBODY SLOOP::NEXT-LOOP (OR (NULL #) (SLOOP:LOCAL-FINISH)) NIL (OR (< I 536870910) (TYPE-ERROR)) ...) Error: Repeated tagbody tag: NIL. ** Long Term Package Issue ** A long term Nqthm/CLTL2 issue, is the USER package. (Damn packages, they always get you.) Apparently, the official user package for ANSI Common Lisp will be COMMON-LISP-USER. In the meantime, for a long time, I think that CLTL2/CLTL1 compatible systems such as cmulisp will continue to provide the good old USER package. But if this should stop, a possible fix is to replace all instances of USER as a package name with COMMON-LISP-USER. But this would lose CLTL1 compatibility. Probably a better, because simpler fix, is before loading nqthm.lisp to check that if the package USER does not exist then it is created, ``using'' COMMON-LISP. Anyway, this is not currently a cmulisp problem. ** CMU Lisp announcement ** From: ram+@cs.cmu.edu Subject: Re: Beta release of SunOS/SPARC CMU Common Lisp Newsgroups: comp.lang.lisp >This message announces a general beta release of CMU Common Lisp for >SPARCstation or Sun4 machines running SunOS. The rest of this message >is derived from the cmucl(1) man page and README file. > > Robert A. MacLachlan (ram@cs.cmu.edu) >________________________________________________________________________ > >Sun Release 4.1 1 > >CMUCL(1) USER COMMANDS CMUCL(1) > >NAME > CMU Common Lisp > >DESCRIPTION > CMU Common Lisp is public domain "industrial strength" Com- > mon Lisp programming environment. Many of the X3j13 changes > have been incorporated into CMU CL. Wherever possible, this > has been done so as to transparently allow use of either > CLtL1 or proposed ANSI CL. Probably the new features most > interesting to users are SETF functions, LOOP and the WITH- > COMPILATION-UNIT macro. > >HARDWARE REQUIREMENTS > CMU CL is currently available for Sparcstations and DECsta- > tions (pmaxes) running Mach (or OSF/1). We are beta-testing > a SunOS SPARC version and an IBM RT Mach version. At least > 16 megabytes of memory and 25 megabytes of disk space are > recommended. As usual, more is better. > >SUPPORT > Bug reports should be sent to cmucl-bugs@cs.cmu.edu. Please > consult your local CMU CL maintainer or Common Lisp expert > to verify that the problem really is a bug before sending to > this list. > > We have insufficient staffing to provide extensive support > to people outside of CMU. We are looking for university and > industrial affiliates to help us with porting and mainte- > nance for hardware and software that is not widely used at > CMU. > >OVERVIEW > When compared other Common Lisp implementations (such as > Allegro), CMU CL has two broad advantages: > > -- The new CMU CL compiler (Python) is more sophisticated > than other Common Lisp compilers. It both produces > better code and is easier to use. > > -- The programming environment based on the Hemlock editor > is better integrated than gnu-emacs based environments. > (Though you can still use GNU if you want.) > > CMU CL also has significant non-technical advantages: > > -- It has good local support for CMU users, and is well > integrated with the CMU CS environment. > > -- It is public domain, and is freely available to non-CMU > sites that aren't able to afford a site-license for a > commercial Lisp. > >COMPILER FEATURES > The `Advanced Compiler' chapter of the User's manual exten- > sively discusses Python's optimization capabilities (See > DOCUMENTATION below.) Here are a few high points: > > -- Good efficiency and type-checking at the same time. Com- > piling code safe gives a 2x speed reduction at worst. > > -- In safe code, type declarations are verified, allowing > declarations to be debugged in safe code. When you go to > compile unsafe, you know the declarations are right. > > -- Full source level debugging of compiled code, including > display of the exact call that got an error. > > -- Good efficiency notes that tell you why an operation > can't be open coded or where you are number-consing, and > that provide unprecedented source context > > -- Block compilation, partial evaluation, lightweight func- > tions and proper tail-recursion allow low-cost use of > function call abstraction. > >___________________________________________________________________________ > >This software is "as is", and has no warranty of any kind. CMU and the >authors assume no responsibility for the consequences of any use of this >software. > >This is a general beta release, meaning that anyone can FTP it, but we won't >be very sympathetic about catastrophes resulting from your dependence on CMU >CL. After the bug reports die down, we will announce a full release, and will >then try to be sympathetic toward desperate users. > >See "man cmucl" (man/cmucl.1) for other general information. > >Distribution: > >CMU Common Lisp is only available via anonymous FTP. We don't have the >manpower to make tapes. All of our files are in the AFS file system. Here >are some suggested gateway machines: > lisp-rt1.slisp.cs.cmu.edu > lisp-rt2.slisp.cs.cmu.edu > >Log in with the user "anonymous" and your real userid as password. Due to the >way anonymous FTP access control is done, it is important to "cd" to the >source directory with a single command, and then do a "get" operation. If you >have any trouble with FTP access, please send mail to slisp@cs.cmu.edu. > >The binary release area is /afs/cs.cmu.edu/project/clisp/release. This >directory holds compressed tar files with names of the form: > -_.tar.Z > >FTP compressed tar archives in binary mode. To extract, "cd" to the >directory that is to be the root of the tree, then type: > uncompress >The latest SunOS Sparc release is: > 15a-sun4c_41.tar.Z >This tar file is 10 megabytes, and the resulting tree is 23 megabytes. > >Major release announcements will be made to comp.lang.lisp until there is >enough volume to warrant a comp.lang.lisp.cmu. > >SunOS credit: > >The SunOS support was written by Miles Bader and Ted Dunning. > >SPARC Notes: > >We have not done any SPARC-specific tuning yet. Performance will improve from >10-30% when we add instruction scheduling and register windows. > >Source availability: > >Lisp and documentation sources are available via anonymous FTP. [See the >README file.] All CMU written code is public domain, but CMU CL also makes >use of several imported packages: PCL, CLX and XP. Although these packages >are copyrighted, they may be freely distributed without any licensing >agreement or fee. Received: by CLI.COM (4.1/1); Sun, 20 Oct 91 13:34:15 CDT Message-Id: <9110201834.AA25837@CLI.COM> Received: from lisp-pmax2.slisp.cs.cmu.edu by LISP-PMAX2.SLISP.CS.CMU.EDU id aa09004; 20 Oct 91 14:36:01 EDT To: "Robert S. Boyer" Cc: nqthm-users@CLI.COM Subject: Re: cmulisp and Nqthm In-Reply-To: Your message of Sun, 20 Oct 91 12:33:46 -0600. <9110201733.AA25652@CLI.COM> Date: Sun, 20 Oct 91 14:35:59 -0400 From: Rob_MacLachlan@LISP-PMAX2.SLISP.CS.CMU.EDU Date: Sun, 20 Oct 91 12:33:46 CDT From: Robert S. Boyer Message-Id: <9110201733.AA25652@CLI.COM> To: nqthm-users@CLI.COM Cc: ram@cs.cmu.edu Subject: cmulisp and Nqthm ** Here are some presumably inconsequential sloop compilation errors. In: DEFUN MAKE-NEW-NAME (ITERATE FOR I FROM 1 ...) --> SLOOP:SLOOP LET MACROLET BLOCK ==> (TAGBODY SLOOP::NEXT-LOOP (OR (NULL #) (SLOOP:LOCAL-FINISH)) NIL (OR (< I 536870910) (TYPE-ERROR)) ...) Error: Repeated tagbody tag: NIL. Actually, I'm afraid this isn't inconsequential. Whenever Python mentions the "Error: " severity, it has aborted compilation of the form and compiled a proxy call to ERROR instead. Also, a closer reading of the manual suggests that this is actually a bug in Python. NIL should never be interpreted as a tag, since it is a LIST (as well as a SYMBOL.) I have appended a patch. Rob ________________________________________________________________ (in-package "C") (defun parse-tagbody (body) (declare (list body)) (collect ((segments)) (let ((current (cons nil body))) (loop (let ((tag-pos (position-if-not #'listp current :start 1))) (unless tag-pos (segments `(,@current nil)) (return)) (let ((tag (elt current tag-pos))) (when (assoc tag (segments)) (compiler-error "Repeated tagbody tag: ~S." tag)) (unless (or (symbolp tag) (integerp tag)) (compiler-error "Illegal tagbody statement: ~S." tag)) (segments `(,@(subseq current 0 tag-pos) (go ,tag)))) (setq current (nthcdr tag-pos current))))) (segments))) EOF Date: Sun, 20 Oct 91 18:15:18 CDT From: Robert S. Boyer Message-Id: <9110202315.AA01125@funware.CLI.COM> Received: by funware.CLI.COM (4.1/CLI-1.2) id AA01125; Sun, 20 Oct 91 18:15:18 CDT To: nqthm-users Cc: Rob_MacLachlan@LISP-PMAX2.SLISP.CS.CMU.EDU Subject: CMU Lisp Patch Reply-To: boyer@cs.utexas.edu For the benefit of the naive Lisp patcher (e.g., me), it should be pointed out that the patch kindly just cc'ed to nqthm-users by Rob MacLachlan (which consisted of two forms, an IN-PACKAGE and a DEFUN) should (a) be put into a separate file, (b) compiled, and (c) loaded into CMU Lisp before doing anything with Nqthm. Bob Received: by CLI.COM (4.1/1); Tue, 22 Oct 91 06:58:11 CDT Date: Tue, 22 Oct 91 06:58:11 CDT From: Robert S. Boyer Message-Id: <9110221158.AA05095@CLI.COM> To: nqthm-users Subject: NQTHM doing the wrong induction Reply-To: boyer@cli.com Someone writes: > Do you have a corpus of examples anywhere of cases where NQTHM fails > to get the right induction scheme? I have worked / am working > ... on stronger inductive proof strategies. One way to find examples where Nqthm doesn't do ``the right'' induction is to scan event files for the use of the explicit INDUCT hint, i.e., look for the string "(induct", a clear sign that the user determined that Nqthm would do ``the wrong induction.'' (Curious how common that latter illiterate phrase has become; one ought to say Nqthm is doing ``a wrong induction'' rather than ``the wrong induction.'' There are so many wrong ones.) There are currently 9 event files in the standard Nqthm distribution directory available by anonymous ftp from cli.com, taking up about 1.7 mb. There are a lot more event files that people at Clinc would probably be happy to send to an inquirer who exhausted the first set of opportunities. A note to technical@cli.com might get many responses. Also, a note to yu@rascal.ics.utexas.edu would perhaps get you some recent especially illuminating examples. Yuan Yu is now proving the correctness, with Nqthm, of MC68020 machine code programs. He uses the INDUCT hint in ways not previously imagined, at least not by me. In particular, he uses an INDUCT hint to ``step'' his MC68020 simulator the exact requisite number of steps to ``go around a loop'' in the machine code program in question, an induction that Nqthm would *never* come close to guessing. Enclosed is an example of his -- see the function gcd-induct and its use in an induct hint. Bob ; Proof of the Correctness of a GCD Program #| The following C program computes the greatest common divisor of two integers a and b. We, here, investigate the machine code of this program generated by a widely used C compiler, and verify the correctness of the code. gcd(a, b) long int a, b; { while (a != 0){ if (b == 0) return (a); if (a > b) a = a % b; else b = b % a; }; return (b); } Here is the MC68020 assembly code for the above GCD program. The code is generated by gcc with the optimization option. 0x22c6 : linkw a6,#0 0x22ca : moveml d2-d3,sp@- 0x22ce : movel a6@(8),d2 0x22d2 : movel a6@(12),d3 0x22d6 : tstl d2 0x22d8 : beq 0x22f6 0x22da : tstl d3 0x22dc : bne 0x22e2 0x22de : movel d2,d0 0x22e0 : bra 0x22f8 0x22e2 : cmpl d2,d3 0x22e4 : bge 0x22ee 0x22e6 : divsll d3,d0,d2 0x22ea : movel d0,d2 0x22ec : bra 0x22d6 0x22ee : divsll d2,d0,d3 0x22f2 : movel d0,d3 0x22f4 : bra 0x22d6 0x22f6 : movel d3,d0 0x22f8 : moveml a6@(-8),d2-d3 0x22fe : unlk a6 0x2300 : rts The machine cod for the above program in hex is: : 0x4e56 0x0000 0x48e7 0x3000 0x242e 0x0008 0x262e 0x000c : 0x4a82 0x671c 0x4a83 0x6604 0x2002 0x6016 0xb682 0x6c08 : 0x4c43 0x2800 0x2400 0x60e8 0x4c42 0x3800 0x2600 0x60e0 : 0x2003 0x4cee 0x000c 0xfff8 0x4e5e 0x4e75 Or in decimal: '(78 86 0 0 72 231 48 0 36 46 0 8 38 46 0 12 74 130 103 28 74 131 102 4 32 2 96 22 182 130 108 8 76 67 40 0 36 0 96 232 76 66 56 0 38 0 96 224 32 3 76 238 0 12 255 248 78 94 78 117) |# ; Now we start the correctness proof of this GCD program, defined by ; (gcd-code). (defn gcd-code () '(78 86 0 0 72 231 48 0 36 46 0 8 38 46 0 12 74 130 103 28 74 131 102 4 32 2 96 22 182 130 108 8 76 67 40 0 36 0 96 232 76 66 56 0 38 0 96 224 32 3 76 238 0 12 255 248 78 94 78 117)) ; The functional description of the program (gcd-code). (defn gcd (a b) (if (zerop a) (fix b) (if (zerop b) a (if (lessp b a) (gcd (remainder a b) b) (gcd a (remainder b a))))) ((lessp (plus a b)))) (defn gcd-t1 (a b) (if (zerop a) 6 (if (zerop b) 9 (if (lessp b a) (splus 9 (gcd-t1 (remainder a b) b)) (splus 9 (gcd-t1 a (remainder b a)))))) ((lessp (plus a b)))) (defn gcd-t (a b) (splus 4 (gcd-t1 a b))) (defn gcd-induct (s a b) (if (or (zerop a) (zerop b)) t (if (lessp b a) (gcd-induct (stepn s 9) (remainder a b) b) (gcd-induct (stepn s 9) a (remainder b a)))) ((lessp (plus a b)))) (defn gcd-statep (s a b) (and (equal (mc-status s) 'running) (evenp (mc-pc s)) (rom-addrp (mc-pc s) (mc-mem s) 60) (asm-addrp (mc-pc s) (mc-mem s) (gcd-code)) (ram-addrp (sub 32 12 (read-sp s)) (mc-mem s) 24) (equal a (iread-mem (add 32 (read-sp s) 4) (mc-mem s) 4)) (equal b (iread-mem (add 32 (read-sp s) 8) (mc-mem s) 4)) (numberp a) (numberp b))) (defn gcd-s0p (s a b) (and (equal (mc-status s) 'running) (evenp (mc-pc s)) (rom-addrp (sub 32 16 (mc-pc s)) (mc-mem s) 60) (asm-addrp (sub 32 16 (mc-pc s)) (mc-mem s) (gcd-code)) (ram-addrp (sub 32 8 (read-an 32 6 s)) (mc-mem s) 24) (equal a (iread-dn 32 2 s)) (equal b (iread-dn 32 3 s)) (numberp a) (numberp b))) ; s --> s0. (prove-lemma gcd-s-s0 (rewrite) (implies (gcd-statep s a b) (and (gcd-s0p (stepn s 4) a b) (equal (linked-rts-addr (stepn s 4)) (rts-addr s)) (equal (linked-a6 (stepn s 4)) (read-an 32 6 s)) (equal (read-rn 32 14 (mc-rfile (stepn s 4))) (sub 32 4 (read-sp s))) (equal (movem-saved (stepn s 4) 4 8 2) (readm-rn 32 '(2 3) (mc-rfile s)))))) (prove-lemma gcd-s-s0-rfile (rewrite) (implies (and (gcd-statep s a b) (d4-7a2-5p rn)) (equal (read-rn oplen rn (mc-rfile (stepn s 4))) (read-rn oplen rn (mc-rfile s))))) (prove-lemma gcd-s-s0-mem (rewrite) (implies (and (gcd-statep s a b) (disjoint x l (sub 32 12 (read-sp s)) 24)) (equal (read-mem x (mc-mem (stepn s 4)) l) (read-mem x (mc-mem s) l)))) ; s0 --> exit. ; base case: s0 --> exit. (prove-lemma gcd-s0-base-1 (rewrite) (implies (and (gcd-s0p s a b) (zerop a)) (and (equal (mc-status (stepn s 6)) 'running) (equal (mc-pc (stepn s 6)) (linked-rts-addr s)) (equal (iread-dn 32 0 (stepn s 6)) b) (equal (read-rn 32 14 (mc-rfile (stepn s 6))) (linked-a6 s)) (equal (read-rn 32 15 (mc-rfile (stepn s 6))) (add 32 (read-an 32 6 s) 8)) (equal (read-mem x (mc-mem (stepn s 6)) l) (read-mem x (mc-mem s) l))))) (prove-lemma gcd-s0-base-rfile-1 (rewrite) (implies (and (gcd-s0p s a b) (zerop a) (d2-7a2-5p rn) (leq oplen 32)) (equal (read-rn oplen rn (mc-rfile (stepn s 6))) (if (d4-7a2-5p rn) (read-rn oplen rn (mc-rfile s)) (get-vlst oplen 0 rn '(2 3) (movem-saved s 4 8 2)))))) (prove-lemma gcd-s0-base-2 (rewrite) (implies (and (gcd-s0p s a b) (not (zerop a)) (zerop b)) (and (equal (mc-status (stepn s 9)) 'running) (equal (mc-pc (stepn s 9)) (linked-rts-addr s)) (equal (iread-dn 32 0 (stepn s 9)) a) (equal (read-rn 32 14 (mc-rfile (stepn s 9))) (linked-a6 s)) (equal (read-rn 32 15 (mc-rfile (stepn s 9))) (add 32 (read-an 32 6 s) 8)) (equal (read-mem x (mc-mem (stepn s 9)) l) (read-mem x (mc-mem s) l))))) (prove-lemma gcd-s0-base-rfile-2 (rewrite) (implies (and (gcd-s0p s a b) (not (zerop a)) (zerop b) (d2-7a2-5p rn) (leq oplen 32)) (equal (read-rn oplen rn (mc-rfile (stepn s 9))) (if (d4-7a2-5p rn) (read-rn oplen rn (mc-rfile s)) (get-vlst oplen 0 rn '(2 3) (movem-saved s 4 8 2)))))) ; induction case: s0 --> s0. (enable integerp) (enable iremainder) (prove-lemma gcd-s0-s0-1 (rewrite) (implies (and (gcd-s0p s a b) (not (zerop a)) (not (zerop b)) (lessp b a)) (and (gcd-s0p (stepn s 9) (remainder a b) b) (equal (read-rn oplen 14 (mc-rfile (stepn s 9))) (read-rn oplen 14 (mc-rfile s))) (equal (linked-a6 (stepn s 9)) (linked-a6 s)) (equal (linked-rts-addr (stepn s 9)) (linked-rts-addr s)) (equal (movem-saved (stepn s 9) 4 8 2) (movem-saved s 4 8 2)) (equal (read-mem x (mc-mem (stepn s 9)) l) (read-mem x (mc-mem s) l))))) (prove-lemma gcd-s0-s0-2 (rewrite) (implies (and (gcd-s0p s a b) (not (zerop a)) (not (zerop b)) (not (lessp b a))) (and (gcd-s0p (stepn s 9) a (remainder b a)) (equal (read-rn oplen 14 (mc-rfile (stepn s 9))) (read-rn oplen 14 (mc-rfile s))) (equal (linked-a6 (stepn s 9)) (linked-a6 s)) (equal (linked-rts-addr (stepn s 9)) (linked-rts-addr s)) (equal (movem-saved (stepn s 9) 4 8 2) (movem-saved s 4 8 2)) (equal (read-mem x (mc-mem (stepn s 9)) l) (read-mem x (mc-mem s) l))))) (prove-lemma gcd-s0-s0-rfile-1 (rewrite) (implies (and (gcd-s0p s a b) (not (zerop a)) (not (zerop b)) (lessp b a) (d4-7a2-5p rn)) (equal (read-rn oplen rn (mc-rfile (stepn s 9))) (read-rn oplen rn (mc-rfile s))))) (prove-lemma gcd-s0-s0-rfile-2 (rewrite) (implies (and (gcd-s0p s a b) (not (zerop a)) (not (zerop b)) (not (lessp b a)) (d4-7a2-5p rn)) (equal (read-rn oplen rn (mc-rfile (stepn s 9))) (read-rn oplen rn (mc-rfile s))))) ; Put together. (prove-lemma gcd-s0p-info (rewrite) (implies (gcd-s0p s a b) (and (numberp a) (numberp b)))) (prove-lemma gcd-s0-exit (rewrite) (implies (gcd-s0p s a b) (and (equal (mc-status (stepn s (gcd-t1 a b))) 'running) (equal (mc-pc (stepn s (gcd-t1 a b))) (linked-rts-addr s)) (equal (iread-dn 32 0 (stepn s (gcd-t1 a b))) (gcd a b)) (equal (read-rn 32 14 (mc-rfile (stepn s (gcd-t1 a b)))) (linked-a6 s)) (equal (read-rn 32 15 (mc-rfile (stepn s (gcd-t1 a b)))) (add 32 (read-an 32 6 s) 8)) (equal (read-mem x (mc-mem (stepn s (gcd-t1 a b))) l) (read-mem x (mc-mem s) l)))) ((induct (gcd-induct s a b)) (disable gcd-s0p iread-dn linked-rts-addr linked-a6))) (prove-lemma gcd-s0-exit-rfile (rewrite) (implies (and (gcd-s0p s a b) (d2-7a2-5p rn) (leq oplen 32)) (equal (read-rn oplen rn (mc-rfile (stepn s (gcd-t1 a b)))) (if (d4-7a2-5p rn) (read-rn oplen rn (mc-rfile s)) (get-vlst oplen 0 rn '(2 3) (movem-saved s 4 8 2))))) ((induct (gcd-induct s a b)) (disable gcd-s0p))) (disable gcd-s0p-info) (prove-lemma gcd-correctness (rewrite) (implies (gcd-statep s a b) (and (equal (mc-status (stepn s (gcd-t a b))) 'running) (equal (mc-pc (stepn s (gcd-t a b))) (rts-addr s)) (equal (iread-dn 32 0 (stepn s (gcd-t a b))) (gcd a b)) (equal (read-rn 32 14 (mc-rfile (stepn s (gcd-t a b)))) (read-rn 32 14 (mc-rfile s))) (equal (read-rn 32 15 (mc-rfile (stepn s (gcd-t a b)))) (add 32 (read-an 32 7 s) 4)))) ((disable gcd-statep gcd-s0p linked-rts-addr linked-a6))) (prove-lemma gcd-rfile (rewrite) (implies (and (gcd-statep s a b) (d2-7a2-5p rn) (leq oplen 32)) (equal (read-rn oplen rn (mc-rfile (stepn s (gcd-t a b)))) (read-rn oplen rn (mc-rfile s)))) ((disable gcd-statep gcd-s0p))) (prove-lemma gcd-mem (rewrite) (implies (and (gcd-statep s a b) (disjoint x l (sub 32 12 (read-sp s)) 24)) (equal (read-mem x (mc-mem (stepn s (gcd-t a b))) l) (read-mem x (mc-mem s) l))) ((disable gcd-statep gcd-s0p))) (disable gcd-t) ; To prove that (gcd a b) does compute the greatest common divisor, we need ; to prove the following two theorems: ; 1. (gcd a b) divides a and (gcd a b) divides b. ; I.e., (gcd a b) is a common divisor of a and b. ; 2. any divisor of a and b is no greater than (gcd a b). (prove-lemma remainder-remainder (rewrite) (implies (equal (remainder b c) 0) (equal (remainder (remainder a b) c) (remainder a c)))) (prove-lemma gcd-is-cd (rewrite) (and (equal (remainder a (gcd a b)) 0) (equal (remainder b (gcd a b)) 0))) (prove-lemma gcd-the-greatest (rewrite) (implies (and (not (zerop a)) (not (zerop b)) (equal (remainder a x) 0) (equal (remainder b x) 0)) (not (lessp (gcd a b) x))) ((induct (gcd a b)))) From weberwu%fubinf.uucp@unido.informatik.uni-dortmund.de Tue Oct 22 03:51:36 1991 Received: by CLI.COM (4.1/1); Tue, 22 Oct 91 03:51:16 CDT Received: from fubinf by unido.informatik.uni-dortmund.de with UUCP (5.65+/UNIDO-2.0.4.d) via EUnet for cli.com id AA18268; Tue, 22 Oct 91 09:40:36 +0100 Received: from client4_6.inf.fu-berlin.de by inf.fu-berlin.de (4.1/SMI-4.1) id AA12034; Tue, 22 Oct 91 09:13:19 +0100 Date: Tue, 22 Oct 91 09:13:19 +0100 From: fubinf!weberwu (Debora Weber-Wulff) Message-Id: <9110220813.AA12034@inf.fu-berlin.de> To: nqthm-users@unido.informatik.uni-dortmund.de Status: R I've got an hour to kill between meetings, perhaps it's time to start collecting "Boyer-Moore lore". This is the first installment, containing some bits of wisdom gleaned during my last visit with the experts - Bill Bevier and Matt Kaufmann. Please share with us any bits of lore you might have found while using the prover. Also feel free to expound on a topic, offer an even better way to do things, or correct misconceptions on my part! The Lore of the Logik (Part 1) * If you find you can't prove a lemma (IMPLIES P (EQUAL X Y)) because it rewrites a variable, prove (IMPLIES P ((EQUAL X Y) T)) instead. * When should one use the shells (which are not abstract data types, even though they look like them)? It is a matter of style, you can make either approach work. Explicitly constructing your own types is more work, as you have to write all the accessors and constructors yourself. You also can't express many interesting types in shells (like lists of even numbers). But shells are useful as the shell functions won't be opened up during simplification. It's just clearer when you see the prover is having trouble with (TOKEN-NAME X) than with (CADDAR x). And there seem to be some lemmata that are introduced "for free" when a shell is added to the history. * It's often better to return the parameter itself on a base case in a definition. (IF (NLISTP BAR) (IF (NLISTP BAR) BAR instead of the way I NIL ... used to do it .... You will be bombarded with cases like "Well, what if BAR is not a list and not NIL?" * Main question to ask if the prover can't prove something "obvious": Did it choose the right induction scheme? When it picks the wrong one, it usually blows the proof attempt. Some people have gotten into the habit of always giving the prover the appropriate induction hint ((INDUCT (FOO A B))). This also results in a slightly faster proof, as it doesn't have to consider a number of induction schemata. (End of Part 1) --- Debora Weber-Wulff dww@inf.fu-berlin.de Institut fuer Informatik +49 30 89691 124 Nestorstr. 8-9 (INCLUDE "standard.disclaimer") D-W-1000 Berlin 31 (PRINTN (WITTY-MESSAGE TODAY)) Received: by CLI.COM (4.1/1); Tue, 22 Oct 91 10:56:59 CDT Date: Tue, 22 Oct 91 10:56:59 CDT From: Matt Kaufmann Message-Id: <9110221556.AA06014@CLI.COM> To: nqthm-users Subject: reply to Debora Weber-Wulff's message of Tue, 22 Oct 91 Just a couple of comments on Debbie's message. >> * If you find you can't prove a lemma (IMPLIES P (EQUAL X Y)) because it rewrites >> a variable, prove (IMPLIES P ((EQUAL X Y) T)) instead. -- should say, prove (IMPLIES P (EQUAL (EQUAL X Y) T)) instead. An observation about using shells -- if you try to use shells whose constructors take many arguments and there are lots of type restrictions, you may find that the prover is very slow in processing those ADD-SHELL events. It's not uncommon, when using a shell, to avoid type restrictions and then define a predicate to define a subclass of those shell objects, intuitively the "good" shell objects. About giving induction hints: >> This also results in a slightly faster proof, as it >> doesn't have to consider a number of induction schemata. Just thought I'd mention that in my experience, the time the prover spends in trying to find the right induction is at most a few seconds, and usually much less than that -- so for me, hinting the induction saves time not by avoiding the need for heuristically searching for it, but instead by other means -- e.g. keeping the prover from wasting time in an initial attempt to do the proof without induction before giving up and using induction on the original (more or less) goal. -- Matt Received: by CLI.COM (4.1/1); Mon, 28 Oct 91 09:42:57 CST Received: from fubinf by unido.informatik.uni-dortmund.de with UUCP (5.65+/UNIDO-2.0.4.d) via EUnet for cli.com id AA14911; Mon, 28 Oct 91 16:38:30 +0100 Received: from client4_1.inf.fu-berlin.de by inf.fu-berlin.de (4.1/SMI-4.1) id AA09478; Mon, 28 Oct 91 16:35:11 +0100 Date: Mon, 28 Oct 91 16:35:11 +0100 From: fubinf!weberwu (Debora Weber-Wulff) Message-Id: <9110281535.AA09478@inf.fu-berlin.de> To: nqthm-users@unido.informatik.uni-dortmund.de Subject: NQTHM use in hardware design verification? I'm forwarding this request for information to the list. Debbie ----- Begin Included Message ----- From ki1.chemie.fu-berlin.de!vm.gmd.de!TECHSEL.BITNET!myoeli@methan.chemie.fu-berlin.de Mon Oct 28 16:26:49 1991 To: -v@cs.Technion.AC.IL, nqthm-users-request@inf.fu-berlin.de Subject: BM mailing list Cc: myoeli@cs.Technion.AC.IL Hi! I am interested in the applications of the BM-prover to the formal verification of hardware designs. I would enjoy receiving info on activities in this area. Greetings, Michael Yoeli +++++++++++++++++++++++++++ Dr. Michael Yoeli Professor Emeritus Department of Computer Science Technion - Israel Institute of Technology Technion City, Haifa 32000 Israel Phone: +972-4-294367 (office) +972-4-243837 (home) Fax: +972-4-294353 E-Mail: myoeli@techsel.bitnet or myoeli@cs.Technion.AC.IL Telex: 46406 TECON IL ----- End Included Message ----- Received: by CLI.COM (4.1/1); Thu, 31 Oct 91 09:42:35 CST Received: from margaux.inria.fr by corton.inria.fr (5.65c8d/90.0.9) via Fnet-EUnet id AA07007; Thu, 31 Oct 1991 16:45:24 +0100 (MET) Received: by margaux.inria.fr, Thu, 31 Oct 91 16:44:40 +0100 Date: Thu, 31 Oct 91 16:44:40 +0100 From: Gerard Huet Message-Id: <9110311544.AA17004@margaux.inria.fr> To: nqthm-users@cli.com Coq Version 5.6 is available! Hello. We are releasing Coq, our Proof Assistant for the Calculus of Inductive Constructions. Should you be interested in trying it out, proceed as follows. Connect to our ftp server by ftp nuri.inria.fr with Name anonymous and Password your email address. If your name server does not find nuri, access with ftp 128.93.1.26 Then do cd esprit/bra/coq get README get coq.tar.Z quit Now uncompress coq.tar.Z, untar coq, and follow the README instructions. Coq runs in CAML V3.1, also available on nuri in directory lang/caml/V3.1. Versions are currently available for the following machines: Sun3, Sun4, Decstation, SONY68k, SONYR3000, Apollo, and Macintosh/AUX. We shall appreciate all comments, suggestions, bug reports. Send your mail to: coq@margaux.inria.fr Received: by CLI.COM (4.1/1); Thu, 31 Oct 91 09:53:00 CST Date: Thu, 31 Oct 91 09:53:00 CST From: Robert S. Boyer Message-Id: <9110311553.AA21698@CLI.COM> To: nqthm-users Cc: huet@margaux.inria.fr Subject: Coq Reply-To: boyer@cli.com Three cheers to Gerard Huet & Co. for making Coq, a proof assistant for the Calculus of Inductive Constructions, freely available by anonymous ftp! Bob Received: by CLI.COM (4.1/1); Thu, 31 Oct 91 10:33:50 CST Date: Thu, 31 Oct 91 10:33:50 CST From: Robert S. Boyer Message-Id: <9110311633.AA22024@CLI.COM> To: nqthm-users, theorem-provers@mc.lcs.mit.edu Subject: Knuth Challenge Problem, for Any Proof Checker Reply-To: boyer@cli.com Don Knuth is interested in having someone proof-check Theorem 4 in his paper ``Textbook Examples of Recursion'' [1]. This theorem concerns a generalization of Takeuchi's function. In a letter to John Cowles (cowles@master.uwyo.edu), September 19, 1991, Knuth remarks ``I checked the proof of that theorem by hand several times, but I have resolved never ever to check it again! At no other time in my life have I felt so dependent on mechanical proof checking as I do with respect to the proof of that theorem.'' John Cowles has used Nqthm to verify Theorem 1 in the same paper, also a Knuth challenge for proof-checking programs. Theorem 1 concerns the 91 function. About that impressive result of Cowles, Knuth remarks ``I am glad to know that the generalized 91 function does indeed have the properties I thought it would. But I would in fact be infinitely more glad to know that the generalized Takeuchi function satisfies the properties claimed for it in Theorem 4 of my paper.'' Bob Boyer [1] D. Knuth, ``Textbook Examples of Recursion'' in V. Lifschitz (editor), Artificial Intelligence and Mathematical Theory of Computation: Papers in Honor of John McCarthy. Academic Press, 1991. pp. 7-26. Received: by CLI.COM (4.1/1); Thu, 31 Oct 91 17:02:25 CST Received: by enet-gw.pa.dec.com; id AA04941; Thu, 31 Oct 91 15:05:38 -0800 Message-Id: <9110312305.AA04941@enet-gw.pa.dec.com> Received: from ixion.enet; by decwrl.enet; Thu, 31 Oct 91 15:05:39 PST Date: Thu, 31 Oct 91 15:05:39 PST From: "Hemendra Talesara, DEC Marlboro, (508) 467-5541" To: nqthm-users@cli.com Cc: talesara@ixion.enet.dec.com Apparently-To: nqthm-users@cli.com Subject: FWD: Robin Milner - 1991 Turing Award Winner -----------------Forwarded item dated 31-OCT-1991 18:08:56.46----------------- Delivery-date: Thu, 31 Oct 1991 12:22:36 UTC-0800 From: To: Message-ID: <9110311905.AA06270@inet-gw-1.pa.dec.com> Subject: Turing and Karl V. Karlstrom awards The 1991 recipients for the A.M. Turing and Karl V. Karlstrom awards have been announced. Professor Robin Milner of the University of Edinburgh is the 1991 Turing Award winner, and Professor David A. Patterson, Chairman of the Department of Electrical Engineering and Computer Science at Berkeley, is the Karl V. Karlstrom Outstanding Educator Award winner. The short citation for Prof. Milner follows: "Working in challenging areas of computer science for twenty years, Robin Milner has established an international reputation for several distinct and complete achievements: LCF, probably the first theoretically based yet practical tool for machine- assisted proof construction; ML, the first language to include polymorphic type inference and a type-safe exception-handling mechanism; CCS, a general theory of concurrency; and full abstraction, the study of the relationship between operational and denotational semantics." The short citation for Prof. Patterson follows: "For his pioneering work on RISC (Reduced Instruction Set Computing), his course series work on RISC that produced a whole generation of academicians, and for his novel approach to teaching computer science to non-computer science majors." Both Milner and Patterson will be attending the award ceremony at CSC'92. Received: by CLI.COM (4.1/1); Fri, 1 Nov 91 07:10:52 CST Received: by enet-gw.pa.dec.com; id AA28241; Fri, 1 Nov 91 05:14:05 -0800 Message-Id: <9111011314.AA28241@enet-gw.pa.dec.com> Received: from ixion.enet; by decwrl.enet; Fri, 1 Nov 91 05:14:05 PST Date: Fri, 1 Nov 91 05:14:05 PST From: "Hemendra Talesara, ISB Marlboro, DTN:297-5541" To: nqthm-users@cli.com Cc: talesara@ixion.enet.dec.com Apparently-To: nqthm-users@cli.com Subject: FWD: EUARTSD Workshop Announcement; please redistribute as appropriate -----------------Forwarded item dated 31-OCT-1991 19:13:09.30----------------- From: HPSRAD::DECWRL::"info-hol@ted.pa.dec.com" "MAIL-11 Daemon 31-Oct-1991 1906" To: info-hol@ted.cs.uidaho.edu CC: Subj: EUARTSD Workshop Announcement; please redistribute as appropriate *********************************************************************** * CALL FOR PAPERS * * * * Workshop on the * * Effective Use of Automated Reasoning Technology in * * System Development * * * * * * April 6-8, 1992, * * Naval Research Laboratory, Washington, D.C. * *********************************************************************** Mathematics and logic are fundamental tools needed to construct complex computer-based systems that must satisfy critical requirements (e.g., for safety and security). Work in formal methods, particularly in specification techniques, is increasing our ability to apply these tools where they are needed. Once a system is formally specified, it becomes possible to check rigorously whether the specification has certain (also formally specified) properties desired of it. Technology to support reasoning about formal specifications, including automated theorem provers and other analysis tools, has been developing in parallel with formal specification methods. At present, a particular formal specification technique is typically tied to a specific automated theorem prover, and one must choose in advance, based on the kinds of theorems one intends to prove about a system, which formal specification language and theorem prover to use. The purpose of this workshop is to explore issues in the application of automated reasoning technology to systems with critical requirements, to investigate how different automated tools might be brought to bear on a single system specification, and to consider how future automated tools might be organized to promote greater interchangeability of component parts. The workshop is sponsored by the Technical Panel on Trustworthy Computing Technology (XTP-1) under The Technical Cooperation Program (TTCP), an agreement under which the US, UK, Canada, Australia, and New Zealand share defense research and development information. Attendance will be limited to 40 individuals and is by invitation on the basis of a submitted paper, extended abstract, or position statement. Copies of all accepted papers will be mailed to participants prior to the workshop and will be published subsequently in a publicly available TTCP report. Important dates: January 10, 1992: Submissions due at the address listed below. February 7, 1992: Acceptances and invitations to participate mailed; (Information for authors regarding paper format to be provided at this time.) March 6, 1992: Camera-ready copies of papers due. April 6-8, 1992: Workshop held [More information on reverse side] Location and Date: The workshop will be held at the Naval Research Laboratory, Washington, D.C. April 6-8, 1992. Areas of Interest: 1. Application of different automated reasoning tools to the same problem or specification. 2. Methods for exchanging useful data among automated theorem provers, software engineering tools, and other analysis tools. 3. Methods for promoting the interchangeability of component parts of automated reasoning tools. 4. Establishing a formal basis for exchanging information among automated reasoning tools and between formal specification processing tools and automated theorem provers. 5. The effectiveness of alternative user interfaces and interaction styles for automated reasoning tools. 6. Significant applications of automated reasoning technology to system development. Organizing Committee: Carl Landwehr, Naval Research Laboratory, USA, Chair C. Terrence Ireland, NSA, USA Milan Kuchta, Canadian Systems Security Centre, Canada William Scherlis, DARPA, USA Please send inquiries and (FOUR COPIES OF) your proposed workshop contributions to: Carl E. Landwehr XTP-1 Workshop Code 5542 Naval Research Laboratory, Washington, D.C. 20375-5000 Phone: +1(202)767-3381 Fax: +1(202)404-7942 Internet: landwehr@itd.nrl.navy.mil **************************************************************************** ------- End of Forwarded Message Received: by CLI.COM (4.1/1); Fri, 1 Nov 91 10:55:52 CST Received: by SAIL.Stanford.EDU (5.57/25-eef) id AA16816; Fri, 1 Nov 91 09:00:20 -0800 Date: Fri, 1 Nov 91 09:00:20 -0800 From: Carolyn Talcott Message-Id: <9111011700.AA16816@SAIL.Stanford.EDU> To: nqthm-users@cli.com Subject: abstract Reply-To: clt@sail.stanford.edu The following report is available upon request to clt@sail.stanford.edu @techreport{nagayama-talcott-91bmp, author = {Nagayama, Misao and Talcott, Carolyn}, title = {An NQTHM Mechanization of ``An Exercise in the Verification of Multi-Process Programs''}, institution = {Computer Science Department, Stanford University}, number = {STAN-CS-91-1370}, year = 1991 } Abstract: This report presents a formal verification of the local correctness of a mutex algorithm using the Boyer-Moore theorem prover. The formalization follows closely an informal proof of Manna and Pnueli. The proof method of Manna and Pnueli is to first extract from the program a set of states and induced transition system. One then proves suitable invariants There are two variants of the proof. In the first (atomic) variant, compound tests involving quantification over a finite set are viewed as atomic operations. In the second (molecular) variant, this assumption is removed, making the details of the transitions and proof somewhat more complicated. The original Manna-Pnueli proof was formulated in terms of finite sets. This led to a concise and elegant informal proof, however one that is not easy to mechanize in the Boyer-Moore logic. In the mechanized version we use a dual isomorphic representation of program states based on finite sequences. Our approach was to outline the formal proof of each invariant, making explicit the case analyses, assumptions and properties of operations used. The outline served as our guide in developing the formal proof. The resulting sequence of events follows the informal plan quite closely. The main difficulties encountered were in discovering the precise form of the lemmas and hints necessary to guide the theorem prover. The complete formal proofs (input to the Boyer-Moore prover) appear as appendices. Some comments on formalization techniques, difficulties, and alternatives are included as comments in the theorem prover input. Received: by CLI.COM (4.1/1); Sun, 3 Nov 91 11:11:56 CST Received: from fubinf by unido.informatik.uni-dortmund.de with UUCP (5.65+/UNIDO-2.0.4.f) via EUnet for cli.com id AA16499; Sun, 3 Nov 91 18:09:30 +0100 Received: from methan.chemie.fu-berlin.de by inf.fu-berlin.de (4.1/SMI-4.1) id AA16027; Sun, 3 Nov 91 17:49:11 +0100 Received: by methan.chemie.fu-berlin.de (= 130.133.2.81) (using /\@@/\ Smail 3.1.22 with VHS rerouting) id ; Sun, 3 Nov 91 17:47 MET Received: by ki1.chemie.fu-berlin.de (/\==/\ Smail3.1.22.1 #22.4) id ; Sun, 3 Nov 91 13:27 MET Received: from DEARN by vm.gmd.de (IBM VM SMTP R1.2.2MX) with BSMTP id 6909; Sun, 03 Nov 91 13:27:10 CET Received: from VM.TAU.AC.IL by DEARN (Mailer R2.08) with BSMTP id 7300; Sun, 03 Nov 91 13:27:09 CET Received: from TECHSEL.BITNET (MYOELI) by VM.TAU.AC.IL (Mailer R2.07) with BSMTP id 2366; Sun, 03 Nov 91 14:27:58 IST Received: from csa.cs.technion.ac.il by csmail.cs.Technion.AC.IL (4.1/3.14) id AA14532; Sun, 3 Nov 91 14:22:57 IST Received: by csa.cs.technion.ac.il (4.1/3.14) id AA02546; Sun, 3 Nov 91 14:26:06 IST Date: Sun, 3 Nov 91 14:26:06 IST From: myoeli@csa.cs.technion.ac.il (Michael Yoeli) Return-Path: Message-Id: <9111031226.AA02546@csa.cs.technion.ac.il> To: fubinf!nqthm-users Subject: Research Topic Cc: myoeli@cs.Technion.AC.IL Message MY/BM/1 It has been suggested by Ms.D.Weber-Wulff that I provide a summary indicating my interest in the BM Theorem-Prover. Presently, my main interest is in the formal verification of sequential circuits, both synchronous and asynchronous (cf.[1]). This note will refer to synchronous circuits only. The appli- cability of the BMTP to hardware verification is widely recog- nized. However, this verification tool is rather far from being easily applicable by a design engineer who is not a verification expert. Hence efforts to bridge this gap by providing suitable interface programs are rather essential. Important contributions in this direction are [2],[3],[4]. The project we are presently interested in, is related to [2]- [4], but differs in details, as outlined below. Consider a synchronous circuit the components of which are com- binational modules and clocked latches. Using higher-order logic and infinite streams of Boolean values, the netlist of such a circuit can directly be represented by a set of mutually recur- sive equations over infinite Boolean streams (cf. [5],[3]). One easily verifies that such a set of equations has a unique solution, provided each cycle of the given circuit contains at least one latch (cf. [4],[5]). Following the approaches of [3] and [4], the relevant set of equations can be suitably prepro- cessed toward the application of the BMTP. Frequently, the behavior of a synchronous circuit can be conve- niently specified by means of LTTL (linear-time temporal logic) formulas (cf.[1]). Such a formula is easily transformed mechani- cally into a first-order logic formula. In view of the above, our project has the following target: A preprocessing program is to be developed, which will accept the netlist of a synchronous circuit, as well as a LTTL formula, and transform the two into suitable inputs to the BMTP. Such a veri- fication package should be user-friendly to the extent that design engineers without much background in formal verification will be able to use it in their design practice. I would welcome comments on the above program. References: [1] Michael Yoeli (ed.), Tutorial: Formal Verification of Hardware Design, IEEE Computer Society Press, 1990. [2] Dominique Borrione, Laurence Pierre, Ashraf Salem, "PREVAIL: A Proof Environment for VHDL Descriptions", Workshop on Correct Hardware Design Methodologies, Torino, Italy, June 12-14, 1991. [3] Laurence Pierre, Representation fonctionnelle et preuve automa- tise de circuits digitaux, Ph.D.Thesis, Universite de Provence, Marseille, December 1990. [4] Alexandre Bronstein, MLP: String-functional Semantics and Boyer- Moore Mechanization for the Formal Verification of Synchronous Circuits, Ph.D.Thesis, Stanford University, December 1989. [5] John T.O'Donnell, "Hardware Description with Recursion Equations", 8th Int'l Conf. CHDL, 1987, pp.363-382. ----------------------------------------------------------------- Dr. Michael Yoeli Professor Emeritus Department of Computer Science Technion - Israel Institute of Technology Technion City, Haifa 32000 Israel Phone: +972-4-294367 (office) +972-4-243837 (home) Fax: +972-4-294353 E-Mail: myoeli@techsel.bitnet or myoeli@cs.Technion.AC.IL Telex: 46406 TECON IL Received: by CLI.COM (4.1/1); Tue, 5 Nov 91 17:01:15 CST Received: from rascal.ics.utexas.edu by cs.utexas.edu (5.64/1.113) with SMTP id AA26576; Tue, 5 Nov 91 17:04:45 -0600 Received: by rascal.ics.utexas.edu (4.0/SMI-4.0) id AA27490; Tue, 5 Nov 91 17:04:09 CST Date: Tue, 5 Nov 91 17:04:09 CST From: boyer@rascal.ics.utexas.edu (Bob Boyer) Message-Id: <9111052304.AA27490@rascal.ics.utexas.edu> To: nqthm-users@cli.com Subject: Tech Report Announcement Reply-To: boyer@cs.utexas.edu The following new technical report may be obtained either by post from the University of Texas or, in postscript form, by anonymous ftp from rascal.ics.utexas.edu (128.83.138.20), as the file /pub/mc.ps. ``Automated Correctness Proofs of Machine Code Programs for a Commercial Microprocessor,'' Robert S. Boyer and Yuan Yu, Technical Report TR-91-33, University of Texas Computer Sciences Department, Austin, Texas 78712, 15 pages, November 1991. Abstract. We have formally specified a substantial subset of the MC68020, a widely used microprocessor built by Motorola, within the mathematical logic of the automated reasoning system Nqthm, i.e., the Boyer-Moore Theorem Prover. Using this MC68020 specification, we have mechanically checked the correctness of MC68020 machine code programs for Euclid's GCD, Hoare's Quick Sort, binary search, and other well-known algorithms. The machine code for these examples was generated using the Gnu C and the Verdix Ada compilers. We have developed an extensive library of proven lemmas to facilitate automated reasoning about machine code programs. We describe a two stage methodology we use to do our machine code proofs. To order by mail specify title, author, number, date. Price $1.50. Please send a U.S. bank check or international money order payable to "The University of Texas" and mail payment along with your request to: Technical Report Center Department of Computer Sciences University of Texas at Austin Taylor Hall 2.124 Austin, TX 78712-1188 Robert S. Boyer and Yuan Yu Computer Sciences Department University of Texas at Austin Austin, Texas 78712 Received: by CLI.COM (4.1/1); Tue, 12 Nov 91 20:15:17 CST Received: by inet-gw-1.pa.dec.com; id AA14981; Tue, 12 Nov 91 18:19:14 -0800 Received: by jumbo.pa.dec.com; id AA09546; Tue, 12 Nov 91 18:19:12 -0800 From: horning@Pa.dec.com (Jim Horning) Message-Id: <9111130219.AA09546@jumbo.pa.dec.com> Date: Tue, 12 Nov 91 18:18:54 PST To: nqthm-users@CLI.COM, theorem-provers@mc.lcs.mit.edu, logic@cs.stanford.edu Cc: horning@Pa.dec.com X-Folder-Carbon: 91-Sent4 Subject: DECspec (Larch) Toolset now available [My apologies to anyone for whom this is a redundant message. Shankar suggested I use these lists to supplement comp.specification and my private interest list.] From: horning@src.dec.com (Jim Horning) Newsgroups: comp.specification Subject: Larch toolset now available Followup-To: horning@src.dec.com, decspec@tle.dec.com Distribution: world Organization: DEC Systems Research Center Keywords: Larch, LSL, LCL, tools A Larch Shared Language and Larch/C interface language toolset is now available for research and experimental use. The toolset still has some rough edges that we are discovering as we use it, and it has seen little real use. The following information is excerpted from the README file: The toolset is available by anonymous FTP from the pub/DEC/Larch/toolset directory on gatekeeper.dec.com, subject to a no-fee license. This directory contains a copy of the license (license.txt) controlling the terms under which this toolset may be used. We solicit input on usability and functionality from early users, and plan to release another version of the toolset in 3-6 months based on this feedback and our own experience. We expect that the next release will be adequate for writing full-scale specifications. We plan to continue its development, but it will also be supplied without warranty, for research use. If you are interested in learning about Larch, we suggest you start by reading "Report on the Larch Shared Language: Version 2.3" and the "Introduction to LCL, A Larch/C Interface Language". Postscript forms of both reports are included in the kit (as ./lsl/doc/lsl_report.ps and ./lcl/doc/lcl_report.ps). Hardcopies may be ordered via e-mail to src-report@src.dec.com, requesting reports SRC-58 (LSL) and SRC-74 (LCL). We also suggest that you look at the employee database example in ./eg/db and the C string package example in ./eg/cstr. Bugs may be reported by mail. See the section below for details. We ask for your cooperation in providing complete bug reports. The software in this kit is protected by copyright. Please complete and return the license which is included in the kit. Instructions are included below. -------------------------------------------------------------------- GETTING THE KIT: The Unix distribution kit of the DECspec Toolset X1.0-4 is available in a compressed tar file larch_0_1_4.tar.Z. The toolset is available by anonymous FTP from the pub/DEC/Larch/toolset directory on gatekeeper.dec.com. This directory contains the complete toolset (larch_0_1_4.tar.Z), a copy of the license (license.txt), and this README file. The license describes the terms under which this toolset may be used. The README file contains instructions for fetching and installing this toolset. To use anonymous FTP, you will need to log into FTP with both name and password of "anonymous". To fetch the license alone: Use ftp to transfer the license to your Unix machine. ftp gatekeeper.dec.com cd pub/DEC/Larch/toolset get license.txt quit To fetch the entire kit (includes license): Create a new directory in which to unpack the kit, move to that directory, and then ftp the kit to your Unix machine. The kit must be transferred in binary mode. mkdir larch cd larch ftp gatekeeper.dec.com binary cd pub/DEC/Larch/toolset get larch_0_1_4.tar.Z quit -------------------------------------------------------------------- UNPACKING: Uncompress the kit. uncompress larch_0_1_4.tar.Z Unpack the tar file. tar xvf larch_0_1_4.tar The directory structure will be . the root directory of the DECspec build tree ./README this file ./Makefile top level makefile ./license.txt DECspec license agreement ./src the source file directories ./src/lsl source files for lsl ./src/lcl source files for lcl ./src/cmn source files that are shared by lsl and lcl ./lsl the lsl base directory ./lcl the lcl base directory ./l[cs]l/doc documentation for the lsl and lcl toolset. The LCL report, lcl_report.ps, and LSL report, lsl_report.ps are here. ./l[cs]l/e the directory in which the executables will be put. We recommend using symbolic links or aliases to these executables. ./l[cs]l/lib contains the standard initialization files, and CTrait.lsl in ./lcl/lib. ./l[cs]l/o will contain the object files (.o files) ./l[cs]l/tst contains the respective test files ./l[cs]l/tst/res results of tests are placed here. ./l[cs]l/tst/bmk contains benchmark test results for comparison with results. ./l[cs]l/gram contains the respective grammars ./lsl/handbook contains the lsl handbook traits ./eg/db employee database example ./eg/cstr string package example You may delete the tar file after you have successfully unpacked it. -------------------------------------------------------------------- LICENSE: You have copied over a kit for the DECspec tools for writing Larch specifications for C programs. These tools are available from Digital Equipment Corporation free of charge to institutions who would like to use the toolset for research purposes. The only requirement is that you complete and sign the license which is included on the kit. The license is an agreement that Digital retains ownership of the product and that you won't give it to someone else. Please fill in the license according to the instructions below and return it to Rebecca Will Digital Equipment Corporation ZKO2-3/N30 110 Spit Brook Road Nashua, NH 03062 The license is located in file, ./license.txt, in the top level directory of the unpacked DECspec kit. 1. Enter the date at the top of page 1 2. Enter a full corporate name, state of incorporation and principal office address at the top of page 1. Please do not use acronyms or other phrases as a substitute for the full legal name 3. Enter the street address, city, state and zip code of the institution site in Clause 2.3 on page 2 4. Enter your name and address in Clause 14.1 on page 6 5. Sign the license on page 6 -------------------------------------------------------------------- INSTALLING... ------------------------------------------------------------------- DOCUMENTATION: ./lcl/doc/lcl_report.ps describes LCL by walking you through an example. We suggest you read this first. Documentation on LSL is available in ./lsl/doc/lsl_report.ps. The grammars for lsl and lcl are available in ./lsl/gram and ./lcl/gram. We suggest you look at the last page of the ./lsl/doc/lsl_report.ps for the LSL reference grammar, and at ./lcl/gram/lcl_refgram.ps for the LCL reference grammar. ./lsl/doc/lsl.doc, ./lsl/doc/lsl2tex.doc, and ./lcl/doc/lcl.doc contain man pages describing the respective tools. ------------------------------------------------------------------- CURRENT QUALITY, KNOWN PROBLEMS, DEFICIENCIES: o Parentheses are not allowed in type definitions. This has been temporarily disabled because it is not implemented correctly. e.g., int (*g)[2]; /* will not work. */ Use intermediate type definitions as a workaround. e.g., typedef int TmpT[2]; TmpT *g; o Type definitions of arrays of and pointers to structs or unions are not allowed because they cause sort naming conflicts. The following will not work: typedef struct {int i;} *T1; typedef struct {int i;} T1[2]; Need to create intermediate type definitions to solve the naming problem: typedef struct {int i;} TmpT; typedef TmpT *T1; typedef TmpT T2[2] o Reuse of tagged structs not yet implemented. In other words, the tag is allowed in the struct definition, but not allowed to declare struct members or variables. e.g., "typedef struct _j1 {struct _j1 *next;} s_t;" - declaration of the "next" is not allowed. o Some operators in the .lcs file are translated to their base form instead of the form the appear in the .lcl file. e.g., ' appears as \post, ^ appears as \pre. This needs to be fixed. o Function parameters are allowed in specifications, but we do not do any semantic checking. In fact, if a function parameter appears in a specification, we do not perform full checking on the rest of the specification. We should continue checking the rest of the specification. o const is only allowed as the first thing in variable or parameter declarations. It is not allowed in typedefs or after *'s as it is in C. We don't do checking on const parameters. o Anonymous structs (without a name) are not allowed for renaming in uses clauses. Use a typedef as a workaround. e.g., "uses x(struct {int i;} for s):" is not allowed, but "typedef struct {int i:} s_t; uses (s_t for s)" is. o "__" is not always inserted when sort names are built for use in the .lcs file. Usually "__" is used to separate the user portion of the sort name from the checker generated portion. This should not cause any problem other than inconsistent looking names in the .lcs file. o The C string package example does not contain an implementation. The current implementation is out-of-date with the specification, so we did not include it. o In LET clauses, the sort of the identifier being defined must be explicitly specified. o Semantics for the components clause in abstract types in not implemented. A components clause in the source also disables the rest of the checking. This needs to be fixed. o The sizeof operator only works on terms ( e.g., sizeof(a + 3) ). It should also work on type definitions ( e.g., sizeof(int) ) o The same name or type are not allowed on the left-hand side of a renaming in a uses clause. e.g., uses lsl_test1(a1 for abc); uses lsl_test2(a1 for def); The second occurrence of "a1" is not allowed and it should be. ------------------------------------------------------------------- REPORTING BUGS: Users may report bugs by sending mail to decspec@tle.dec.com. It will help us to track and fix bugs if you provide the following additional information Hardware: Operating System and Version: DECspec version (printed on 1st line of .lcs files): Severity: 0-9 (see below) Is the problem preventing you from making progress with DECspec? Problem description, including any source files or pointers to source files (please try to narrow the problem down to a small example): Any workarounds you've found: How was the problem found? ordinary use (e. g., trying to specify a specific interface)? trying out features described in our documentation? other? Which of the following symptoms occurred (list all that apply): system level error (OS crashes, OS hangs, loss of unrelated data) program crash (ACCVIO/memory fault, core dump, etc.) program hangs program reports a fatal error loss of related data unfriendly behavior incorrect behavior poor or incorrect error messages documentation is wrong documentation is missing enhancement request other (please elaborate) SEVERITY: Please classify the seriousness of the problem according to the following scale. Treat this classification as if you were trying to use DECspec for serious work; i. e. do not lower the priority of a bug simply because you're just trying to learn about Larch or not using it on a real problem. 0 = User Misunderstanding 1 = Cosmetic defect, can still get job done 2 3 = Implementing a workaround is simple 4 5 = Implementing a workaround is difficult 6 7 = Incorrect/incomplete results are produced, no workaround 8 9 = A major feature is not working We thank you for your cooperation, and your participation in this effort. ------------------------------------------------------------------- Received: by CLI.COM (4.1/1); Tue, 19 Nov 91 09:16:49 CST Received: from TRMETU.BITNET by VTVM2.CC.VT.EDU (IBM VM SMTP V2R1) with BSMTP id 6629; Tue, 19 Nov 91 10:13:49 EST Received: from TRBILUN.BITNET by TRMETU.BITNET (Mailer R2.07) with BSMTP id 3936; Tue, 19 Nov 91 16:24:50 TUR Received: from dicle.bcc.bilkent.edu.tr by bcc.bilkent.edu.tr (4.1/SMI-4.1) id AA17523; Tue, 19 Nov 91 16:22:30 +0200 Date: Tue, 19 Nov 91 16:22:30 +0200 From: erkan%TRBILUN.bitnet@VTVM2.CC.VT.EDU (Erkan Ucar) Message-Id: <9111191322.AA17523@bcc.bilkent.edu.tr> To: nqthm-users@cli.com November 19, 1991 Dear Nqthm-users I am a graduate student and a research assistant in Bilkent University, Ankara. I obtained Nqthm theorem prover but unfortunately I do not have the user's manual or any document about it (except the on-line readme and installation.guide.) To continue my research, I urgently need the user's manual to follow some details. It has been written that there is an extremely comprehensive user's manual available. I have also written to Computational Logic, Inc. I will be glad if you can send the necessary information about it. I will be happy to join the nqthm mailing list. It will be fantastic to communicate people about this research. Thanking for your kind cooperation and waiting for your early reply, I remain, Erkan UCAR Department of Computer Engineering and Information Science, Bilkent University, Bilkent, 06533, Ankara, TURKEY. e-mail: erkan@trbilun.bitnet Received: by CLI.COM (4.1/1); Tue, 19 Nov 91 12:00:26 CST Received: from STORK.LCS.MIT.EDU by theory.lcs.mit.edu (5.65c/TOC-1.2S) id AA01865; Tue, 19 Nov 91 12:58:50 EST From: meyer@theory.lcs.mit.edu (Albert R. Meyer) Received: by stork.lcs.mit.edu (5.65c/TOC-1.2C) id AA14611; Tue, 19 Nov 91 12:58:34 EST Date: Tue, 19 Nov 91 12:58:34 EST Message-Id: <199111191758.AA14611@stork.lcs.mit.edu> To: nqthm-users@CLI.COM Subject: private correspondence I'd like to contact the maintainer of this email list without intruding on the rest of the subscribership. Who is it? Yours truly, Albert R. Meyer MIT Lab. for Computer Science Received: by CLI.COM (4.1/1); Wed, 20 Nov 91 18:24:55 CST Date: Wed, 20 Nov 91 18:24:55 CST From: Robert S. Boyer Message-Id: <9111210024.AA24928@CLI.COM> To: nqthm-users@cli.com, theorem-provers@mc.lcs.mit.edu Subject: New Book Automated Reasoning: Essays in Honor of Woody Bledsoe, Robert S. Boyer, editor, 1991, Kluwer Academic Publishers, 365 pages. Chapters METEORs: High Performance Theorem Provers using Model Elimination O. L. Astrachan and D. W. Loveland The Metatheorist: Automatic Proofs of Theorems in Analysis Using Non-Standard Techniques, Part II A. M. Ballantyne Perspectives on Automated Deduction W. Bibel A Biographical Sketch of W. W. Bledsoe Anne Olivia Boyer and Robert S. Boyer MJRTY---A Fast Majority Vote Algorithm Robert S. Boyer and J Strother Moore How the Brain Adjusts Synapses---Maybe Hans J. Bremermann and Russell W. Anderson The Use of Proof Plans for Normalization Alan Bundy What Are the Limitations of the Situation Calculus? M. Gelfond, V. Lifschitz, and A. Rabinov Reasoning In Paraconsistent Logics J. Lu, L. Henschen, V. Subrahmanian, and N. da Costa Compiling Recursive Functional Prolog Programs with List Structure into Procedural Languages Young K. Nam and Lawrence J. Henschen Aligning Multiple RNA Sequences Ross Overbeek and Ian Foster Similarity, Uncertainty and Case-Based Reasoning in Patdex Michael M. Richter and Stefan Wess Formal and Informal Proofs J. A. Robinson PTTP and Linked Inference Mark E. Stickel Automated Reasoning and Bledsoe's Dream for the Field Larry Wos Ordering info Price: $89.00, Dfl. 160.00, Pounds Sterling 54.00. ISBN 0-7923-1409-3. Ordering from USA and Canada: Kluwer Academic Publishers Group P.O. Box 358, Accord Station Hingham, MA 02018-0358 Tel: (617) 871-6600 Telex: 200190 KLUER UR FAX: 6178716528 Ordering from the rest of the world: Kluwer Academic Publishers Group Sales Department P.O. Box 322 3300 AH Dordrecht The Netherlands Tel: (0)78-524400 Telex: 20083 KADC NL FAX: (0)78-183273 Received: by CLI.COM (4.1/1); Mon, 25 Nov 91 15:53:59 CST Received: by ihb.compuserve.com (5.65/5.910516) id AA00463; Mon, 25 Nov 91 16:52:06 -0500 Date: 25 Nov 91 16:39:50 EST From: Val Schorre <70376.1735@CompuServe.COM> To: nqthm Subject: change of address Message-Id: <911125213950_70376.1735_EHJ30-2@CompuServe.COM> OLDADDRESS val@culv.unisys.com NEW ADDRESS 70376.1735@CompuSesrve.COM Dewey Val Schorre Received: by CLI.COM (4.1/1); Fri, 29 Nov 91 05:11:45 CST Received: from TRMETU.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP V2R1) with BSMTP id 4122; Fri, 29 Nov 91 06:09:43 EST Received: from TRBILUN.BITNET by TRMETU.BITNET (Mailer R2.07) with BSMTP id 0869; Fri, 29 Nov 91 13:05:58 TUR Received: from dicle.bcc.bilkent.edu.tr by bcc.bilkent.edu.tr (4.1/SMI-4.1) id AA13341; Fri, 29 Nov 91 12:25:40 +0200 Date: Fri, 29 Nov 91 12:25:40 +0200 From: erkan%TRBILUN.bitnet@CUNYVM.CUNY.EDU (Erkan Ucar) Message-Id: <9111290925.AA13341@bcc.bilkent.edu.tr> To: nqthm-users@cli.com November 29, 1991 Hi; Does anybody know how to obtain or get info. about: "R.S.Boyer,M.W.Green and J.S.Moore. The Use of a Formal Simulator to Verify a Simple Real Time Control Program. Technical Report ICSCA-CMP-29, University of Texas at Austin, 1982." Thanking for your kind cooperation and waiting for your early reply, I remain, Erkan UCAR Department of Computer Engineering and Information Science, Bilkent University, Bilkent, 06533, Ankara, TURKEY. e-mail: erkan@trbilun.bitnet Received: by CLI.COM (4.1/1); Tue, 17 Dec 91 08:15:08 CST Date: Tue, 17 Dec 91 08:14:45 CST From: Received: by plague.local (5.57/Ultrix3.0-C) id AA06025; Tue, 17 Dec 91 13:29:09 -0200 Message-Id: <9112171529.AA06025@plague.local> To: garland@larch.lcs.mit.edu, guttag@larch.lcs.mit.edu, mtv@godiva.lcs.mit.edu, horning@pa.dec.com, saxe@pa.dec.com, urban@pa.dec.com, lamport@pa.dec.com, kjones@pa.dec.com, peterg@pa.dec.com, gnelson@pa.dec.com, Jeannette.Wing@cs.cmu.edu, jst@id.dth.dk, nm@id.dth.dk, ramesh@id.dth.dk, wild@tle.enet.dec.com, mckeeman@tle.enet.dec.com, feldman@tle.enet.dec.com, uhm@cs.rhbnc.ac.uk, fv@lri.lri.fr, cc@lri.lri.fr, bidoit@dmi.ens.fr, tnn@tern.cl.cam.ac.uk, dam@ai.mit.edu, maa@research.att.com, doug@research.att.com, pjw@research.att.com, dmgold1@tycho.ncsc.mil, sri@cc.gatech.edu, chen@cs.cornell.edu, leavens@bambam.cs.iastate.edu, lapolla@dipl.rdd.lmsc.lockheed.com, ramu@cadsun.corp.mot.com, hemmendd@athena.union.edu, djr@zola.ics.uci.edu, leveson@zola.ics.uci.edu, omalley@ics.uci.edu, FN304@jaguar.uofs.edu, carol@falcon.cs.uofs.edu, spr@cs.brown.edu, pratt@cs.stanford.edu, snyder@cs.bu.edu, davidg@thorax.oracorp.com, garrel@thorax.oracorp.com, moore@cli.com, JEFF@mecan1.maine.edu, CLAUS@mecan1.maine.edu, steveb@vlsi.cs.caltech.edu, kemm%cs@hub.ucsb.edu, greene@mcc.com, gerhart@sw.mcc.com, riecke@saul.cis.upenn.edu, tgd@tesla.cs.orst.edu, zachary@denali.utah.edu, nachum@cs.uiuc.edu, GITZLAFF%PURCCVM.BITNET@vm1.nodak.edu, hsiang@sbcs.sunysb.edu, mkim@cs.ubc.ca, atkinson@scs.carleton.ca, dw@swatter.fly.toronto.edu, cliff@computer-science.manchester.ac.uk, philc@ux.rfhsm.lon.ac.uk, dts@lfcs.edinburgh.ac.uk, R.E.Milne@stl.stc.co.uk, mboasson@ajpo.sei.cmu.edu, hofstede@cs.utwente.nl, broy@lan.informatik.tu-muenchen.dbp.de, hettler@informatik.tu-muenchen.dbp.de, gramlich@uklirb.informatik.uni-kl.de, canver@informatik.uni-ulm.de, ruess@informatik.uni-ulm.de, khb@informatik.uni-kiel.dbp.de, ulrich@informatik.uni-dortmund.de, bert@uranus.imag.fr, Pack.Heng@irisa.fr, jouvelot@isatis.ensmp.fr, lescanne@loria.fr, ckirchne@loria.crin.fr, terje@hrp.no, marimar@ts.tid.es, aa!zj@srawgw.sra.co.jp, pal@cs.uq.oz.au, logic@theory.lcs.mit.edu, decspec@tle.dec.com, nqthm-users@cli.com, theorem-provers@mc.lcs.mit.edu, logic@cs.stanford.edu, rewriting@loria.fr, REGGIO%IGECUNIV.bitnet@uicvm.uic.edu, roy@cs.uiuc.edu, conradi%vax.runit.unit.uninett%norunix.bitnet@CUNYVM.CUNY.EDU, cousot@poly.polytechnique.fr, olejohan@i fi.uio.no, deutsch@parcplace.com, gries@cs.cornell.edu, jdan@eng.sun.com, hancock@movies.enet.dec.com, harel@wisdom.weizmann.ac.il, Harter@hpsrad.enet.dec.com, hehner@csri.toronto.edu, peter@ecs.soton.ac.uk, nigelh@csr.uvic.ca, horwitz@cs.wisc.edu, gannon@gannonssun.cs.umd.edu, kotov@isi.itfs.nsk.su, bkb@informatik.uni-bremen.de, lazowska@krakatoa.cs.washington.edu, Leonard@ricks.enet.dec.com, lipp@rdvax.enet.dec.com, London@cs.pdx.edu, MADEY%PLEARN.BITNET@searn.sunet.se, jamesgmitchell@sun.com, C0515010%EMDUPM11.BITNET@cunyvm.cuny.edu, Neumann@csl.sri.com, unido!unipas!padawitz@uunet.uu.net, Brian.Randell@newcastle.ac.uk, reps@cs.wisc.edu, John.Reynolds@proof.cs.cmu.edu, Rushby@csl.sri.com, ms@hpl.hp.co.uk, fbs@gvax.cs.cornell.edu, shankar@krypton.csl.sri.com, ms@info.ucl.ac.be, sufrin@prg.oxford.ac.uk, dt@cui.unige.ch, wulf@virginia.edu, fisher@iris.ucdavis.edu, apengell@axion.bt.co.uk, cherubini@austin.enet.dec.com, goodwin@malin.enet.dec.com, wilcox@wucs1.wustl.edu, olender@sor.cs.colostate.edu, synge@seasid.enet.dec.com, weide@cis.ohio-state.edu, prem@allegra.att.com, wkh@dce.austin.ibm.com, ad@sunbim.be, fso@daimi.aau.dk, mictro@daimi.aau.dk, morrison@uiuc.edu, huntsman@opus.ccl.byu.edu Subject: The Larch Prover (LP), Release 2.2 Date: Tue, 17 Dec 91 13:29:08 -0200 From: "Stephen J. Garland" X-Mts: smtp (Please ignore duplicate copies of this announcement if you happen to be on more than one of the distribution lists to which it is being sent.) LP, The Larch Prover -------------------- Release 2.2 November 27, 1991 LP [1] is an interactive proof-assistant for a subset of multisorted first-order logic. It is designed to work efficiently on large problems and to be used by relatively naive users. Among its current uses are analyzing formal specifications [2], reasoning about concurrent algorithms and hardware designs [4,5], and proving theorems in algebra [3]. LP's design is based on the assumption that initial attempts to state conjectures correctly, and then prove them, usually fail. As a result, LP is designed to carry out routine (and possibly lengthy) steps in a proof automatically and to provide useful information about why proofs fail, if and when they do. LP is not designed to find difficult proofs automatically; instead, LP makes it easy for users to employ standard techniques such as proofs by cases, induction, and contradiction. LP allows users to axiomatize theories by equations (i.e., quantifier-free formulas), operator theories (e.g., commutativity), deduction rules (equivalent to universal-existential formulas), and induction rules. LP automatically orients most equations into terminating rewrite rules, which it then uses in equational term-rewriting to simplify axioms and conjectures. LP automatically applies deduction rules to derive consequences from newly asserted, simplified, or proved equations and rewrite rules. LP can be obtained by anonymous ftp from larch.lcs.mit.edu (18.26.0.95). You should use a dialog such as csh>>ftp larch.lcs.mit.edu Name: anonymous Password: ftp> cd pub/lp ftp> binary ftp> get lp2.2.lib.tar.Z ftp> get lp2.2.decmips.Z ftp> quit to get the file lp2.2.lib.tar.Z (~420K), which contains documentation and a runtime library for LP, together with one of the following compressed executable versions of LP: lp2.2.decmips.Z for DEC/MIPS 3100 or 5000 workstations (~1.1 meg) lp2.2.mips.Z for MIPS workstations (~1.1 meg) lp2.2.sparc.Z for Sun Sparcstations (~1.4 meg) lp2.2.sun3.Z for Sun-3 workstations under Sun Unix 4.3 (~260K) lp2.2.vax.Z for DEC VAX computers under Berkeley Unix 4.3 with NFS or a compatible version of Unix such as Ultrix (~260K) To install LP, uncompress the executable file and install it as lp in /usr/local/bin (or in any other directory on your search path). Also, install LP's runtime library by typing the following commands: uncompress lp.2.2.lib.tar.Z mkdir /usr/local/lib/lp mv lp.2.2.lib.tar.Z /usr/local/lib/lp cd /usr/local/lib/lp tar xf lp.2.2.lib.tar If you cannot create /usr/local/lib/lp, you can install LP's runtime library in some other directory and alias the the command "lp" to "lp -d directory-name". To run LP on some other machine (e.g., a Sony or Hewlett-Packard workstation), or under some other operating system (e.g., Berkeley 4.2 Unix or Berkeley 4.3 Unix without NFS), you should get the compressed tar file lp2.2.code.tar.Z (~535K) containing source code, as well as lp2.2.lib.tar.Z, and compile your own executables. To compile LP, you will need a CLU compiler and runtime system. For VAX and 68000 based architectures, these are available by anonymous ftp from pion.lcs.mit.edu (18.26.0.64) in the directory pub/clu. For other architectures, such as the DEC/MIPS workstations and Sun Sparcstations, a portable CLU compiler is available by anonymous ftp from mintaka.lcs.mit.edu (18.26.0.36) in the directory pub/pclu. If you use this implementation of CLU, which translates CLU sources into C, you may also want to get the compressed tar file lp2.2.c.tar.Z containing the C translations of the CLU sources (getting these files saves the time required for retranslation). See the file INSTALLING in the distribution for information about compiling LP and about overcoming installation problems. No license is required for using LP. The file COPYRIGHT in the distribution contains further information about using and redistributing LP. If you have problems with this distribution, or if you find bugs in LP, please contact Stephen Garland MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139 or send network mail to garland@larch.lcs.mit.edu. If you decide to become a user of LP, please send us mail at the above address, both so that we know who our users are and so that we can mail you announcements of workshops, new releases, and bug fixes. References ---------- [1] S. J. Garland and J. V. Guttag. A Guide to LP, The Larch Prover. MIT Laboratory for Computer Science, December 1991. Also available from DEC Systems Research Center, 130 Lytton Avenue, Palo Alto, CA 94301, as Report 82. A PostScript file containing this report is part of the distribution. [2] S. J. Garland, J. V. Guttag, and J. J. Horning. "Debugging Larch Shared Language specifications," IEEE Transactions on Software Engineering 16:9 (September 1990), pp. 1044-1057. Also available as DEC Systems Research Center Report 60 (July 1990). [3] U. Martin and M. Lai, "Some experiments with a completion theorem prover," Journal of Symbolic Computation, to appear, 1991. [4] J. B. Saxe, S. J. Garland, J. V. Guttag, and J. J. Horning, "Using transformations and verification in circuit design," DEC Systems Research Center Report 78, September 1991. [5] J. Staunstrup, S. J. Garland, and J. V. Guttag. "Localized verification of circuit descriptions," Proc. Int. Workshop on Automatic Verification Methods for Finite State Systems, Grenoble, France, Lecture Notes in Computer Science 407, Springer-Verlag, 1989, pp. 349-364. Received: by CLI.COM (4.1/1); Wed, 18 Dec 91 04:45:03 CST Received: from fubinf by mail.Germany.EU.net with UUCP (5.65+/UNIDO-2.1.0.a) via EUnet for cli.com id AA08023; Wed, 18 Dec 91 11:40:49 +0100 Received: by inf.fu-berlin.de (4.1/SMI-4.1) id AA16853; Wed, 18 Dec 91 10:51:14 +0100 Date: Wed, 18 Dec 91 10:51:14 +0100 From: fubinf!weberwu (Debora Weber-Wulff) Message-Id: <9112180951.AA16853@inf.fu-berlin.de> To: nqthm-users@Germany.EU.net I have a question for the NQTHM-experts: I have about 15 character classes that are used in my scanner. At the moment I introduce them to the scanner as a parameter which is an alist of elements consisting of a character class name and a list of the ASCII codes used. (setq cc (bind 'le (list '(65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122)) ;; #\a #\b #\c ... (bind 'di (list '(48 49 50 51 52 53 54 55 56 57)) ;; #\0 #\1 #\2 #\3 #\4 #\5 #\6 #\7 #\8 #\9 ... ))) where bind constructs an alist element. Would it be "better" (i.e. is it easier on the proof effort) to have functions for each of the classes: ; like this (defn le-p (ch) (and (numberp ch) (or (and (lessp 64 ch) (lessp ch 91)) (and (lessp 96 ch) (lessp ch 123))))) ; or like this (defn di-p (ch) (member ch '(48 49 50 51 52 53 54 55 56))) Does anyone have experience on the differences between "hard-wiring" things like this in functions vs. using them as paramaters and defining functions like proper-cc-list to check that the set of cc's is okay? With the latter, for example, I can quickly check that the character classes are disjunct - collect up the ranges, flatten them and test for setp. This does not seem as easy to prove with the hard-wired function. Debbie Weber-Wulff dww@inf.fu-berlin.de Received: by CLI.COM (4.1/1); Tue, 28 Jan 92 11:41:15 CST Received: from fubinf by mail.Germany.EU.net with UUCP (5.65+/UNIDO-2.1.0.b) via EUnet for cli.com id AA18859; Tue, 28 Jan 92 18:38:34 +0100 Received: from methan.chemie.fu-berlin.de by inf.fu-berlin.de (4.1/SMI-4.1) id AA06987; Tue, 28 Jan 92 18:16:21 +0100 Received: by methan.chemie.fu-berlin.de (/\@@/\ Smail3.1.25.1 #25.7) id ; Tue, 28 Jan 92 18:05 MET Received: by ki1.chemie.fu-berlin.de (/\@@/\ Smail3.1.25.1 #25.8) id ; Tue, 28 Jan 92 17:59 MET Received: from DEARN by vm.gmd.de (IBM VM SMTP R1.2.2MX) with BSMTP id 6155; Tue, 28 Jan 92 18:03:04 CET Received: from vm.uni-c.dk by DEARN (Mailer R2.08) with BSMTP id 0995; Tue, 28 Jan 92 18:03:03 CET Received: from NEUVM1 by vm.uni-c.dk (Mailer R2.07) with BSMTP id 2581; Tue, 28 Jan 92 18:01:53 DNT Received: from danpost.uni-c.dk by vm.uni-c.dk (IBM VM SMTP V2R1) with TCP; Tue, 28 Jan 92 18:01:52 DNT Received: from id.dth.dk by danpost.uni-c.dk (5.65/1.34) id AA06721; Tue, 28 Jan 92 17:02:55 GMT Received: from ithil.id.dth.dk (ithil) by iddth.id.dth.dk (5.65c+/1.34) id AA04891; Tue, 28 Jan 1992 18:03:13 GMT Received: by ithil.id.dth.dk (4.1/SMI-4.1-PB1.0) id AA12064; Tue, 28 Jan 92 17:59:15 +0100 Date: Tue, 28 Jan 92 17:59:15 +0100 From: bojsen@id.dth.dk (Per Bojsen) Message-Id: <9201281659.AA12064@ithil.id.dth.dk> To: fubinf!nqthm-users Subject: New on nqthm-users mailing list Hello, I'm new on this list, so before I ask any questions I'll give a short presentation of my NQTHM related work. I'm a graduate student at the Computer Science department of the Technical University of Lyngby. I'm a member of a small Design Automation Group here at the department. My project concerns the application of formal methods in hardware design (primarlily VLSI chips). I'm focusing my attention at the architectural synthesis level where algorithms described in the form of so-called data flow graphs (DFGs) are synthesized into an register transfer level (RTL) description. What I actually intend to do is to formalize/mechanize the variant of DFGs that we use, which are token flow based (i.e., derived from Petri nets). This kind of DFGs were originally developed at the University of Eindhoven. Actually, the DFGs are really control/data flow graphs because they not only describe data flow but also control flow in the algorithms. Also, they are executable, i.e., simulatable. After having formalized the DFGs in NQTHM i hope to be able to prove some interesting theorems about DFGs. Now to my question: does anybody know what the following fatal error means and how it can be avoided? FATAL ERROR: SET-DIFF-N called with inappropriate arguments. I've had it a number of times lately, and have been able to avoid it by rearranging the order of events. I use NQTHM with AKCL 1.605. Regarding the License Agreement for NQTHM: does CLI have a fax number, and if so, is it OK to fax the Agreement to CLI? -- Per Bojsen The Design Automation Group Email: bojsen@ithil.id.dth.dk MoDAG Technical University of Denmark pb@id.dth.dk Received: by CLI.COM (4.1/1); Tue, 28 Jan 92 12:10:33 CST Received: from fubinf by mail.Germany.EU.net with UUCP (5.65+/UNIDO-2.1.0.b) via EUnet for vm.gmd.de id AA18859; Tue, 28 Jan 92 18:38:34 +0100 Received: from methan.chemie.fu-berlin.de by inf.fu-berlin.de (4.1/SMI-4.1) id AA06987; Tue, 28 Jan 92 18:16:21 +0100 Received: by methan.chemie.fu-berlin.de (/\@@/\ Smail3.1.25.1 #25.7) id ; Tue, 28 Jan 92 18:05 MET Received: by ki1.chemie.fu-berlin.de (/\@@/\ Smail3.1.25.1 #25.8) id ; Tue, 28 Jan 92 17:59 MET Received: from DEARN by vm.gmd.de (IBM VM SMTP R1.2.2MX) with BSMTP id 6155; Tue, 28 Jan 92 18:03:04 CET Received: from vm.uni-c.dk by DEARN (Mailer R2.08) with BSMTP id 0995; Tue, 28 Jan 92 18:03:03 CET Received: from NEUVM1 by vm.uni-c.dk (Mailer R2.07) with BSMTP id 2581; Tue, 28 Jan 92 18:01:53 DNT Received: from danpost.uni-c.dk by vm.uni-c.dk (IBM VM SMTP V2R1) with TCP; Tue, 28 Jan 92 18:01:52 DNT Received: from id.dth.dk by danpost.uni-c.dk (5.65/1.34) id AA06721; Tue, 28 Jan 92 17:02:55 GMT Received: from ithil.id.dth.dk (ithil) by iddth.id.dth.dk (5.65c+/1.34) id AA04891; Tue, 28 Jan 1992 18:03:13 GMT Received: by ithil.id.dth.dk (4.1/SMI-4.1-PB1.0) id AA12064; Tue, 28 Jan 92 17:59:15 +0100 Date: Tue, 28 Jan 92 17:59:15 +0100 From: bojsen@id.dth.dk (Per Bojsen) Message-Id: <9201281659.AA12064@ithil.id.dth.dk> To: fubinf!nqthm-users Subject: New on nqthm-users mailing list Hello, I'm new on this list, so before I ask any questions I'll give a short presentation of my NQTHM related work. I'm a graduate student at the Computer Science department of the Technical University of Lyngby. I'm a member of a small Design Automation Group here at the department. My project concerns the application of formal methods in hardware design (primarlily VLSI chips). I'm focusing my attention at the architectural synthesis level where algorithms described in the form of so-called data flow graphs (DFGs) are synthesized into an register transfer level (RTL) description. What I actually intend to do is to formalize/mechanize the variant of DFGs that we use, which are token flow based (i.e., derived from Petri nets). This kind of DFGs were originally developed at the University of Eindhoven. Actually, the DFGs are really control/data flow graphs because they not only describe data flow but also control flow in the algorithms. Also, they are executable, i.e., simulatable. After having formalized the DFGs in NQTHM i hope to be able to prove some interesting theorems about DFGs. Now to my question: does anybody know what the following fatal error means and how it can be avoided? FATAL ERROR: SET-DIFF-N called with inappropriate arguments. I've had it a number of times lately, and have been able to avoid it by rearranging the order of events. I use NQTHM with AKCL 1.605. Regarding the License Agreement for NQTHM: does CLI have a fax number, and if so, is it OK to fax the Agreement to CLI? -- Per Bojsen The Design Automation Group Email: bojsen@ithil.id.dth.dk MoDAG Technical University of Denmark pb@id.dth.dk Received: by CLI.COM (4.1/1); Tue, 28 Jan 92 13:12:00 CST Date: Tue, 28 Jan 92 13:12:31 CST From: Matt Kaufmann Message-Id: <9201281912.AA06872@client12.CLI.COM> Received: by client12.CLI.COM (4.1/CLI-1.2) id AA06872; Tue, 28 Jan 92 13:12:31 CST To: bojsen@id.dth.dk Cc: nqthm-users@cli.com In-Reply-To: Per Bojsen's message of Tue, 28 Jan 92 17:59:15 +0100 <9201281659.AA12064@ithil.id.dth.dk> Subject: New on nqthm-users mailing list >> Regarding the License Agreement for NQTHM: does CLI have a fax number, >> and if so, is it OK to fax the Agreement to CLI? The fax number at CLI is (512) 322-0656. I've checked, and you may FAX the agreement if you wish, but you also should return a copy of the agreement with an original signature. >> Now to my question: does anybody know what the following fatal error >> means and how it can be avoided? >> >> FATAL ERROR: SET-DIFF-N called with inappropriate arguments. >> >> I've had it a number of times lately, and have been able to avoid it >> by rearranging the order of events. I use NQTHM with AKCL 1.605. This message is one that many nqthm users are familiar with. It appears when the prover has "run out" of variable names for destructor elimination or generalization. I think it's fair to say that probably no proof has ever failed for this reason, that would have succeeded if there were more such names "available". I believe that usually this message is a sign that there is some kind of infinite loop in progress. Thus, it makes sense that rearranging the order of events (as you have done) could help: more recent rewrite rules are applied first, and thus the order of events can definitely affect the course of the proof. I don't have any general advice on how to avoid this message, except perhaps for the following very vague advice of an extremely general nature. My impression is that usually the prover has gone into "extremely" nested generalization and/or elimination by the time this message occurs. I tend to keep the prover "on a short leash" so that I abort proofs long before that behavior ever occurs. Often, if I inspect the output just before the first elimination or generalization occurs, I can see how to formulate a useful rewrite rule that would further "normalize" the expressions produced by simplification. Then when I try the proof again, perhaps elimination and generalization is avoided entirely, or at least the proof gets "further along" so that I can see how to formulate additional useful rewrite rules. I wish I could be more specific, but using this (or, I think, any automated reasoning assistant) is still (in 1992) often a delicate process. Chapter 13 of Boyer and Moore's "A Computational Logic Handbook" (Academic Press, Boston, 1988) has some useful hints on how to use the prover effectively. -- Matt Kaufmann Received: by CLI.COM (4.1/1); Tue, 28 Jan 92 13:53:45 CST Received: from rascal.ics.utexas.edu by cs.utexas.edu (5.64/1.120) with SMTP id AA14078; Tue, 28 Jan 92 13:56:22 -0600 Received: by rascal.ics.utexas.edu (4.0/SMI-4.0) id AA10532; Tue, 28 Jan 92 13:55:29 CST Date: Tue, 28 Jan 92 13:55:29 CST From: yu@rascal.ics.utexas.edu (Yuan Yu) Message-Id: <9201281955.AA10532@rascal.ics.utexas.edu> To: kaufmann@CLI.COM Cc: bojsen@id.dth.dk, nqthm-users@CLI.COM In-Reply-To: Matt Kaufmann's message of Tue, 28 Jan 92 13:12:31 CST <9201281912.AA06872@client12.CLI.COM> Subject: New on nqthm-users mailing list Would it be possible to make Nqthm more friendly -- printing out something like ``Your proof attempt might go into some ..., so we stop it!''? A message of ``FATAL ERROR'' is just too scary for new users. Received: by CLI.COM (4.1/1); Wed, 29 Jan 92 08:52:30 CST Received: from ithil.id.dth.dk (ithil) by iddth.id.dth.dk (5.65c+/1.34) id AA13431; Wed, 29 Jan 1992 15:56:56 GMT Received: by ithil.id.dth.dk (4.1/SMI-4.1-PB1.0) id AA13296; Wed, 29 Jan 92 15:52:58 +0100 Date: Wed, 29 Jan 92 15:52:58 +0100 From: bojsen@id.dth.dk (Per Bojsen) Message-Id: <9201291452.AA13296@ithil.id.dth.dk> To: nqthm-users@CLI.COM In-Reply-To: Matt Kaufmann's message of Tue, 28 Jan 92 13:12:31 CST <9201281912.AA06872@client12.CLI.COM> Subject: New on nqthm-users mailing list > This message is one that many nqthm users are familiar with. It > appears when the prover has "run out" of variable names for > destructor elimination or generalization. I think it's fair to say > that probably no proof has ever failed for this reason, that would > have succeeded if there were more such names "available". I believe > that usually this message is a sign that there is some kind of > infinite loop in progress. Thus, it makes sense that rearranging > the order of events (as you have done) could help: more recent > rewrite rules are applied first, and thus the order of events can > definitely affect the course of the proof. This makes sense to me, especially since the problems started to appear when I added som ELIM lemmas. And the message disappeared whenever I moved a lemma up before the ELIM lemmas. Or when I disable the ELIM lemmas in question. Maybe they are bad ELIM lemmas, I'll have to look into that, I guess. This leads to the following question: is it (or would it be) possible to disable a lemma as being an ELIM lemma, for example, but leave it enabled as a rewrite lemma? -- Per Bojsen The Design Automation Group Email: bojsen@ithil.id.dth.dk MoDAG Technical University of Denmark pb@id.dth.dk Received: by CLI.COM (4.1/1); Mon, 3 Feb 92 05:40:52 CST Received: from fubinf by mail.Germany.EU.net with UUCP (5.65+/UNIDO-2.1.0.b) via EUnet for cli.com id AA28207; Mon, 3 Feb 92 12:38:36 +0100 Received: from methan.chemie.fu-berlin.de by inf.fu-berlin.de (4.1/SMI-4.1) id AA06057; Mon, 3 Feb 92 12:15:57 +0100 Received: by methan.chemie.fu-berlin.de (/\@@/\ Smail3.1.25.1 #25.7) id ; Mon, 3 Feb 92 12:05 MET Received: by ki1.chemie.fu-berlin.de (/\@@/\ Smail3.1.25.1 #25.8) id ; Mon, 3 Feb 92 12:00 MET Received: from DEARN by vm.gmd.de (IBM VM SMTP R1.2.2MX) with BSMTP id 1172; Mon, 03 Feb 92 12:04:02 CET Received: from vm.uni-c.dk by DEARN (Mailer R2.08) with BSMTP id 0768; Mon, 03 Feb 92 12:04:01 CET Received: from NEUVM1 by vm.uni-c.dk (Mailer R2.07) with BSMTP id 3328; Mon, 03 Feb 92 12:04:35 DNT Received: from danpost.uni-c.dk by vm.uni-c.dk (IBM VM SMTP V2R1) with TCP; Mon, 03 Feb 92 12:04:34 DNT Received: from id.dth.dk by danpost.uni-c.dk (5.65/1.34) id AA18144; Mon, 3 Feb 92 11:05:20 GMT Received: from ithil.id.dth.dk (ithil) by iddth.id.dth.dk (5.65c+/1.34) id AA25183; Mon, 3 Feb 1992 11:03:55 GMT Received: by ithil.id.dth.dk (4.1/SMI-4.1-PB1.0) id AA18943; Mon, 3 Feb 92 12:01:22 +0100 Date: Mon, 3 Feb 92 12:01:22 +0100 From: bojsen@id.dth.dk (Per Bojsen) Message-Id: <9202031101.AA18943@ithil.id.dth.dk> To: fubinf!nqthm-users Subject: NQTHM emacs mode? Does anybody know if there is an NQTHM emacs mode available somewhere? If so, where can I get it? Thanks in advance. -- Per Bojsen The Design Automation Group Email: bojsen@ithil.id.dth.dk MoDAG Technical University of Denmark pb@id.dth.dk Received: by CLI.COM (4.1/1); Tue, 4 Feb 92 13:10:44 CST Received: from fubinf by mail.Germany.EU.net with UUCP (5.65+/UNIDO-2.1.0.b) via EUnet for cli.com id AA03648; Tue, 4 Feb 92 20:08:37 +0100 Received: from sparc5.inf.fu-berlin.de by inf.fu-berlin.de (4.1/SMI-4.1) id AA15755; Tue, 4 Feb 92 19:48:07 +0100 Date: Tue, 4 Feb 92 19:48:07 +0100 From: fubinf!weberwu (Debora Weber-Wulff) Message-Id: <9202041848.AA15755@inf.fu-berlin.de> To: nqthm-users@Germany.EU.net Subject: NQTHM-MODE for EMACS There has been a request for nqthm "tools" from the net. Bill Bevier has kindly offered his emacs customization files for general use on a no-documentation-no-service-no-warranty basis. I am willing to send a copy of these files to anyone interested in them. Send an email to me at dww@inf.fu-berlin.de with subject NQTHM-MODE, and I'll return a compressed/tarred/uuencoded file. The main advantage of these files is that I can have NQTHM in one buffer, my files other buffers, and with Ctrl-C E I can send an event to NQTHM, with Ctrl-C B I can have a whole buffer submitted, and with Ctrl-C R a marked region is submitted and I can go for coffee while it proves. There are also some little functions that check for unbalanced parentheses and such. If any readers on the list have other tools (I'd like a graphic interface with proof tree management and script version control, please ;-), this is the place to let the world know about it. Debora Weber-Wulff dww@inf.fu-berlin.de Institut fuer Informatik +49 30 89691 124 Nestorstr. 8-9 (INCLUDE "standard.disclaimer") D-W-1000 Berlin 31 (PRINTN (WITTY-MESSAGE TODAY)) Received: by CLI.COM (4.1/1); Thu, 13 Feb 92 11:26:52 CST Date: Thu, 13 Feb 92 11:28:11 CST From: Matt Kaufmann Message-Id: <9202131728.AA11909@client12.CLI.COM> Received: by client12.CLI.COM (4.1/CLI-1.2) id AA11909; Thu, 13 Feb 92 11:28:11 CST To: nqthm-users@CLI.COM Subject: demos To interested nqthm users (especially new ones): I have created some introductory demos of the Boyer-Moore theorem prover that are self-explanatory and can be run by anyone. They are available by ftp from Internet host cli.com (cli.com currently has Internet number 192.31.85.1). All files happen to be on the directory pub/proof-checker/demos/ on cli.com, which is visible by anonymous ftp. For further explanation, see the file README in that directory, which for your convenience I include below. If you have any comments, I'd be most interested. -- Matt Kaufmann ------- file ~ftp/pub/proof-checker/demos/README on cli.com ------- This directory contains some demos that you can run yourself. To run the demos interactively, follow the instruction at the top of the file "run.lisp", which may involve a little editing. To run the demos in batch mode, do the editing specified at the top of "run.lisp", and make sure that there is a shell command available called "nqthm" that runs the Boyer-Moore theorem prover. Then execute the command source script in Unix. If you have any questions, please feel free to contact me (Matt Kaufmann) by email at kaufmann@cli.com. NOTE: the compressed tar file demos.tar.Z and checksum file SUM were created by the Unix command source make.demos.tar.z To uncompress and untar, simply execute the following commands at a shell in Unix: uncompress demos.tar.Z tar xvf demos.tar rm demos.tar Received: by CLI.COM (4.1/1); Thu, 13 Feb 92 14:57:45 CST Received: from rascal.ics.utexas.edu by cs.utexas.edu (5.64/1.120) with SMTP id AA13925; Thu, 13 Feb 92 15:01:43 -0600 Received: by rascal.ics.utexas.edu (4.0/SMI-4.0) id AA03367; Thu, 13 Feb 92 15:00:26 CST Date: Thu, 13 Feb 92 15:00:26 CST From: boyer@rascal.ics.utexas.edu (Bob Boyer) Message-Id: <9202132100.AA03367@rascal.ics.utexas.edu> To: nqthm-users@cli.com Subject: New Tech Report Reply-To: boyer@cs.utexas.edu The following new technical report may be obtained either by post from the University of Texas or, in dvi or postscript form, by anonymous ftp from rascal.ics.utexas.edu (128.83.138.20), as the file /pub/mc20-1.dvi or as the file /pub/mc20-1.ps. ``A Formal Specification of Some User Mode Instructions for the Motorola 68020'' Robert S. Boyer and Yuan Yu, Technical Report TR-92-04, University of Texas Computer Sciences Department, Austin, Texas 78712, 125 pages, February, 1992. Abstract. We present a formal specification of approximately 80% of the `user mode' instructions of the Motorola MC68020 microprocessor. The specification is given in the form of definitions in the logic of Nqthm, the Boyer-Moore system. The definitions are displayed in a conventional mathematical syntax. The specification has been used in the mechanical verification of several dozen machine code programs, whose binary was generated by `industrial strength' C and Ada compilers. To order by mail specify title, author, number, date. Price $5.00. Please send a U.S. bank check or international money order payable to "The University of Texas" and mail payment along with your request to: Technical Report Center Department of Computer Sciences University of Texas at Austin Taylor Hall 2.124 Austin, TX 78712-1188 Robert S. Boyer and Yuan Yu Computer Sciences Department University of Texas at Austin Austin, Texas 78712 P. S. It sometimes seems desireable to use `binary' mode within `ftp' to get a dvi file successfully. Received: by CLI.COM (4.1/1); Wed, 19 Feb 92 14:55:36 CST Date: Wed, 19 Feb 92 14:55:36 CST From: Matt Kaufmann Message-Id: <9202192055.AA05492@CLI.COM> To: kundu@decwrl.dec.com, kunen@cs.wisc.edu, alex@jessica.stanford.edu, alex@obelix.pa.dec.com, talesara@hpsrad.dec.com, clt@sail.stanford.edu, cowles@corral.uwyo.edu, shankar@csl.sri.com, Albert.Koelmans@newcastle.ac.uk, verkest%lima.imec.be@imec.be, mccune@mcs.anl.gov, yu@rascal.ics.utexas.edu, lsil!mhost!osas1!vijay@fernwood.mpk.ca.us, langevin@iro.umontreal.ca, annap@biobio.cs.uiuc.edu, nqthm-users@cli.com, dmg@cli.com, technical@cli.com Subject: nqthm applications survey To nqthm users: A survey of formal methods tools and techniques will be included in the proceedings of the "FM91" conference. The purpose of this message is to solicit responses from Nqthm users to a survey (shown below). Apparently there will be at most a couple of pages allotted for all the Nqthm applications, so responses should be limited to rather "major" applications, say those that have taken at least (roughly) a couple of months or more of effort. I will pass responses along to the appropriate person. Replies should be fairly short, since apparently there will be at most a couple of pages for all the Nqthm applications. By the way, Pc-Nqthm applications are also welcome. If you care to respond, please do so (to kaufmann@cli.com) by Wednesday, February 26. Thank you. Survey of applications: Name of application project Participants Contact name and address Level of effort Brief description - Outline the nature of the application, the tools/techniques employed. - What role did the formal methods play in the development process? - What were the benefits? - What were the drawbacks? - What lessons can be drawn, recommendations made? Published articles and reports [end] Received: by CLI.COM (4.1/1); Mon, 24 Feb 92 16:40:05 CST Received: from fubinf by mail.Germany.EU.net with UUCP (5.65+/UNIDO-2.1.0.b) via EUnet for cli.com id AA25740; Mon, 24 Feb 92 23:39:04 +0100 Received: from unido.UUCP by inf.fu-berlin.de (4.1/SMI-4.1) id AA06652; Mon, 24 Feb 92 22:16:16 +0100 Received: from mcsun by mail.Germany.EU.net with UUCP (5.65+/UNIDO-2.1.0.b) via EUnet for fubinf id AA13012; Mon, 24 Feb 92 21:41:42 +0100 Received: from DEARN by mcsun.EU.net with SMTP; id AA09423 (5.65a/CWI-2.146); Mon, 24 Feb 1992 20:26:23 +0100 Received: from vm.uni-c.dk by DEARN (Mailer R2.08) with BSMTP id 8878; Mon, 24 Feb 92 14:05:34 CET Received: from NEUVM1 by vm.uni-c.dk (Mailer R2.07) with BSMTP id 2840; Mon, 24 Feb 92 14:04:17 DNT Received: from danpost.uni-c.dk by vm.uni-c.dk (IBM VM SMTP V2R1) with TCP; Mon, 24 Feb 92 14:04:16 DNT Received: from id.dth.dk by danpost.uni-c.dk (5.65/1.34) id AA09016; Mon, 24 Feb 92 13:03:02 GMT Received: from ithil.id.dth.dk (ithil) by iddth.id.dth.dk (5.65c+/1.34) id AA13425; Mon, 24 Feb 1992 14:02:42 +0100 Received: by ithil.id.dth.dk (4.1/SMI-4.1-PB1.0) id AA17966; Mon, 24 Feb 92 14:00:05 +0100 Date: Mon, 24 Feb 92 14:00:05 +0100 From: bojsen@id.dth.dk (Per Bojsen) Message-Id: <9202241300.AA17966@ithil.id.dth.dk> To: fubinf!nqthm-users Subject: Finding expensive events Enclosed is a little csh script which takes the output of the PROVEALL command (*.proofs) and generates a listing of the names of the expensive events (i.e., the slow ones) and the three numbers of the time triple. The script takes one or two arguments, the first being the name of the *.proofs file (you may omit the proofs suffix) and the second the limit (in seconds) of `expensiveness'. The default value of the latter is 60 seconds. I use the second number of the time triple (i.e., the time taken to prove the lemmas) as the measure of expensiveness. The script could easily be changed to use the sum of the time triple values instead (just change the `$3' in the awk command line to `$2 + $3 + $4'. Caveat: I haven't tested it). I use the script to find those events which takes very long time compared with the rest of the events in the event history. A number of times a closer investigation of these events have revealed the presence of `bad' lemmas in my history whose presence had an adverse effect on proof times and almost never were necessary. One example of this is the following lemma: (prove-lemma lessp-length (rewrite) (implies (lessp (length L1) (length L2)) (not (equal L1 L2)))) When enabled some of my proofs would take hundreds or even thousands of seconds; when disabled the same proofs only take a few seconds. ----8<--------8<--------8<--------8<--------8<--------8<--------8<--------8<---- #! /bin/csh -b if ( $#argv < 1 ) then echo "${0}: Needs arguments." exit 2 endif if ( $#argv < 2 ) then set limit = 60 else set limit = $2 endif if ( $1:e == "proofs" ) then set proofs = $1 else if ( -e $1.proofs ) then set proofs = $1.proofs else if ( -e $1 ) then set proofs = $1 else echo "${0}: ${1}: No such file." exit 1 endif sed -e '/^\[.*\]/ \!d' -e '/^\[.*\]/ N' -e '/^\[.*\]/ N' -e 's/^\[ *\([0-9.]*\) *\([0-9.]*\) *\([0-9.]*\) *\] *\n[ ]*\n\([A-Z].*\)$/\4 \1 \2 \3/' $proofs | awk -e '$3 >= '"$limit"' { print }' ----8<--------8<--------8<--------8<--------8<--------8<--------8<--------8<---- -- Per Bojsen The Design Automation Group Email: bojsen@ithil.id.dth.dk MoDAG Technical University of Denmark pb@id.dth.dk Received: by CLI.COM (4.1/1); Wed, 26 Feb 92 08:38:01 CST Received: by enet-gw.pa.dec.com; id AA17104; Wed, 26 Feb 92 06:42:27 -0800 Message-Id: <9202261442.AA17104@enet-gw.pa.dec.com> Received: from hpsrad.enet; by decwrl.enet; Wed, 26 Feb 92 06:42:30 PST Date: Wed, 26 Feb 92 06:42:31 PST From: "HEMENDRA TALESARA, DEC Marlborough, FT SYSTEMS, (508) 467-5541" To: nqthm-users@cli.com Cc: talesara@hpsrad.enet.dec.com Apparently-To: nqthm-users@cli.com Subject: FWD: CHDL'93 call for papers -----------------Forwarded item dated 26-FEB-1992 09:07:43.68----------------- From: DECWRL::"CRM24@BNR.CA" "David (D.G.) Agnew" To: , , , , , CC: Subj: CHDL'93 call for papers If possible please include the following announcement in any newsletter or distribution you may do. If anyone wants nicely printed hard copies to distribute, please contact me. Thanks, Dave Agnew e-mail: crm24@bnr.ca --------------------------------------------------------------- CHDL'93 call for papers: CCCC HH HH DDDDD LL II 9999 33333 CCCC HH HH DDDDDD LL 99 99 33 CC HHHHHH DD DD LL 99 99 3333 CC HHHHHH DD DD LL 99999 33 CCCC HH HH DDDDDD LLLLL 99 33 CCCC HH HH DDDD LLLLL 9999 33333 IFIP Conference on Hardware Description Languages and Their Applications Chateau Laurier Hotel Ottawa, CANADA April 26-28, 1993 CHDL '93 will be immediately followed by the VHDL International Users Forum (VIUF) April 29-30, 1993 at the Chateau Laurier TWENTIETH ANNIVERSARY OF CHDL CONFERENCE: held every 2 years since 1973, CHDL has rotated between Europe, North America and Asia. This meeting originated under IEEE/ACM sponsorship, and since 1981 has been organized by IFIP working group 10.2. The topic has a long history with over 100 HDLs published in the 1970s, but until the mid-1980s HDLs were mostly used in teaching, research and architectural modelling of computers. More recently HDLs have become central to system design and VLSI, due to many factors including: > the increasing complexity and broader usage of digital electronics, requiring increased use of modelling and simulation; > the current migration of VLSI design from schematic capture to logic synthesis based on HDLs; > the standardization of HDLs. The result is that HDL-based design methods are increasingly becoming the norm for electronic hardware design. TOPICS: The future of HDLs looks brighter than ever in the 1990s. Several emerging or potential new design technologies depend on HDLs, for example > high-level synthesis > formal verification > design frameworks > DSP design and dataflow languages > protocol specification and design languages > FSM capture, implementation and verification > code generation for on-chip embedded control > mixed hardware-software co-design and co-verification > hardware testing and testability > mixed textual/graphical design capture > HDL-based design methods e.g. executable specifications > parallel control specification for parallel processing or concurrent hardware processes AUTHOR INFORMATION: Contributions on these or related topics are desired. Regular papers and short papers are welcome. Regular papers may be on original research, or review or tutorial submissions. Short papers should be on recent research results, to be presented in a special session in a workshop format to encourage discussion. All papers will appear in the conference proceedings. Regular papers will be printed in book form as well, and selected papers will also be published in the Journal on Formal Methods in System Design. Papers (6 copies) should be submitted by Oct. 5, 1992 to OCRI (address below). For regular papers, the full paper (up to 20 double-spaced pages) should be sent. For short papers, only a 4 page summary is needed. Proposals for special sessions are also welcome, and should be sent to the conference chairman. Conference Chairman ------------------- David Agnew Bell-Northern Research P.O. Box 3511, Station C Ottawa, Ontario, CANADA K1Y 4H7 Phone: 613-763-3197 Fax: 613-763-7241 e-mail: crm24@bnr.ca Program Chairman ---------------- Prof. Luc Claesen IMEC/Kath. University of Leuven Kapeldreef, 75 B-3001 Leuven, BELGIUM Phone: (+32-16)28 12 03 Fax: (+32-16)22 94 00 e-mail: claesen@imec.be Conference Management --------------------- OCRI (Ottawa Carleton Research Institute) c/o Debby Sullivan 340 March Road, Suite 400 Kanata, Ontario, CANADA K2K 2E4 Phone: 613-592-8160 Fax: 613-592-8163 e-mail: trio@carleton.ca Track co-chairmen ----------------- Frameworks: Mark Whitton, Bell-Northern Research, Ottawa High-level synthesis: Pierre Paulin, Bell-Northern Research Formal methods: Prof. Ed Cerny, University of Montreal VHDL: Prof. Mostapha Aboulhamid, University of Montreal Important Dates --------------- September 1, 1992: Special sessions proposals due October 5, 1992: Deadline for paper submissions December 18, 1992: Notification of acceptance February 1, 1993: Camera-ready copy due Program Committee: (members of IFIP working group 10.2 on HDLs): ---------------------------------------------------------------- Einar J. Aas, Norway Mario Barbacci, USA Raul Camposano, Germany Edmund Clarke, USA Carlos Delgado Koos, Spain Reinder Hartenstein, Germany Franz Klaschka, Germany Petra Michel, Germany Adam Pawlak, Germany Franz Rammig, Germany P.A. Subrahmanyam, USA Ronald Waxman, USA Michael Yoeli, Israel F. Anceau, France Gaetano Borriello, USA Luc Claesen, Belgium Werner Damm, Germany Daniel Gajski, USA Steven Johnson, USA C.J. Koomen, Netherlands George J. Milne, Scotland Robert Piloty, Germany Peter Schwarz, Germany Mr. Tsuneta Sudo, Japan Klaus Woelcken, Germany P. Bakowski, France Dominique Borrione, France Alex Bronstein, USA John Darringer, USA Werner Grass, Germany Nabuaki Kawato, Japan David Luckham, USA Hillel Ofek, USA Paolo Prinetto, Italy William Sherwood, USA Flavio Rech Wagner, Brazil Akihiko Yamada, Japan % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by enet-gw.pa.dec.com; id AA15589; Wed, 26 Feb 92 06:17:09 -0800 % Received: by inet-gw-1.pa.dec.com; id AA07075; Wed, 26 Feb 92 06:10:57 -0800 % Received: by ted.cs.uidaho.edu (16.6/1.34) id AA22849; Wed, 26 Feb 92 05:23:16 -080 % Sender: info-hol-request@ted.cs.uidaho.edu % Errors-To: info-hol-request@ted.cs.uidaho.edu % Received: from gateway.bnr.ca by ted.cs.uidaho.edu (16.6/1.34) id AA22812; Wed, 26 Feb 92 05:23:10 -080 % Received: from BNRECADA.BNR.CA by gateway.bnr.ca (5.61/1.34) id AA28181; Wed, 26 Feb 92 08:25:29 -050 % Message-Id: <9202261325.AA28181@gateway.bnr.ca> % Received: from BNRECADA.BNR.CA by BNRECADA.BNR.CA (IBM VM SMTP R1.2.1) with BSMTP id 1793; Wed, 26 Feb 92 08:25:25 EST % Date: 26 Feb 92 08:25:00 EST % To: , , , , , % Subject: CHDL'93 call for papers Received: by CLI.COM (4.1/1); Sat, 29 Feb 92 19:05:38 CST Received: from kafka.cns.caltech.edu by cns.caltech.edu (4.1/1.34) id AA05313; Sat, 29 Feb 92 17:02:58 PST Date: Sat, 29 Feb 92 17:02:58 PST From: kprasad@cns.caltech.edu (K. Prasad) Message-Id: <9203010102.AA05313@cns.caltech.edu> To: nqthm-users@cli.com Subject: HOL/Noyer-Moore/Statecharts?? Am posting this for a friend. Thanks for any comments. +++ ----8<--------8<--------8<--------8<--------8<--------8<-------- I have a few requirement specifications that are expressed as Statecharts. I am interested in knowing if HOL or the Boyer-Moore logic gives me any more functionality than Statecharts. For example, what value would I get if I migrated from Statecharts to using one of these theorem provers? Can I reason about the specifications better and make them more complete? Right now, I feel that my specifications are "sort of" incomplete. Thanks in advance. Received: by CLI.COM (4.1/1); Wed, 1 Apr 92 18:11:28 CST Received: by enet-gw.pa.dec.com; id AA13634; Wed, 1 Apr 92 16:13:38 -0800 Message-Id: <9204020013.AA13634@enet-gw.pa.dec.com> Received: from hpsrad.enet; by decwrl.enet; Wed, 1 Apr 92 16:13:38 PST Date: Wed, 1 Apr 92 16:13:38 PST From: "HEMENDRA TALESARA, DEC FT SYSTEMS, (508)467-5541 01-Apr-1992 1917" To: nqthm-users@Pa.dec.com Apparently-To: nqthm-users@cli.com Subject: FWD: post-doc positions at UBC ------------------Forwarded item dated 1-APR-1992 17:46:27.95------------------ From: DECWRL::"joyce@cs.ubc.ca" "Jeffrey Joyce" To: CC: Subj: post-doc positions at UBC OPEN POST DOCTORAL POSITIONS Department of Computer Science University of British Columbia Vancouver, Canada The Integrated Systems Design Group has several open post-doctoral positions for individuals with research interests in the following areas: + formal methods + formal hardware verification + hardware description languages + machine-assisted theorem-proving + VLSI design methodology + real-time software development + CASE methodology and tools The expected annual salary for these positions is $41,000 (Canadian dollars). The main duty of an individual in this position would be to contribute to the research activities of the Integrated Systems Design Group. This individual would also be required to teach one 13-week course (3 hours of lectures per week). These positions are offered as 1-year appointments with the possibility of re-appointment for a second year. Appointments to these position are expected to commence in August 1992. The Integrated Systems Design Group, headed by Drs. J. Joyce and C-J. Seger, is one of six research groups in the Computer Science Department at the University of British Columbia. Our research centers upon principles, techniques, methodologies and tools for the specification, design and implementation and verification of integrated software/hardware systems. We are especially interested in formal methods such as machine-assisted theorem-proving, symbolic simulation and model checking to increase confidence in the correctness and reliability of hardware/software designs. Individuals appointed to these post-doctoral positions would have the opportunity to enjoy a stimulating research oriented environment. The UBC Computer Science Department has experienced rapid development in size and diversity over the past four years. The number of faculty members in the Department of Computer Science has grown from 18 in 1988 to our current size of 27 tenured or tenure-track faculty members. During this time, the size of graduate program has doubled to approximately ninety full-time graduate students. Post-doctoral fellows would also have the opportunity to enjoy our beautiful park-like setting on the Pacific Coast (the nearest beach is 15 minutes away by walking). The combination of ocean and snow-capped mountains offers outstanding opportunities for outdoor recreation. Application Procedure: ====================== Qualified individuals (with a Ph.D. or expecting to receive a Ph.D. before September 1, 1992) may apply by writing to either Dr. Joyce or Dr. Seger at the address given below. Applications should include: + a full Curriculum Vitae (including list of publications) + two or three reprints of recent publications (including thesis abstract) + names of three individuals who could be asked to provide a reference (please include email address as well as postal address and phone number) Send applications to: Dr. J. Joyce/Dr. C-J. Seger Department of Computer Science University of British Columbia 6356 Agricultural Road Vancouver, CANADA V6T 1Z2 tel: (604) 822-4327 (Joyce) (604) 822-8179 (Seger) fax: (604) 822-5485 email: joyce@cs.ubc.ca seger@cs.ubc.ca Applications must be received before May 8, 1992 -- however, offers may be made before May 8, 1992 to outstanding applicants. Prospective applicants are advised that delivery of mail by regular post from the USA to Canada can take as long as three weeks. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by enet-gw.pa.dec.com; id AA06762; Wed, 1 Apr 92 14:42:10 -0800 % Received: by inet-gw-1.pa.dec.com; id AA09583; Wed, 1 Apr 92 14:41:45 -0800 % Received: by ted.cs.uidaho.edu (16.6/1.34)id AA14429; Wed, 1 Apr 92 13:39:59 -0800 % Sender: info-hol-request@ted.cs.uidaho.edu % Errors-To: info-hol-request@ted.cs.uidaho.edu % Received: from grolsch.cs.ubc.ca by ted.cs.uidaho.edu (16.6/1.34)id AA14425; Wed, 1 Apr 92 13:39:50 -0800 % Received: by grolsch.cs.ubc.ca id AA12282 (5.65c/IDA-1.3.5 for info-hol@ted.cs.uidaho.edu); Wed, 1 Apr 1992 13:42:40 -0800 % Date: 1 Apr 92 21:42 % From: Jeffrey Joyce % To: % Message-Id: <4492*joyce@cs.ubc.ca> % Subject: post-doc positions at UBC Received: by CLI.COM (4.1/1); Fri, 3 Apr 92 14:20:49 CST Date: Fri, 3 Apr 92 14:22:32 CST From: Matt Kaufmann Message-Id: <9204032022.AA05809@thunder.CLI.COM> Received: by thunder.CLI.COM (4.1/CLI-1.2) id AA05809; Fri, 3 Apr 92 14:22:32 CST To: theorem-provers@ai.mit.edu, technical@cli.com, nqthm-users@cli.com Cc: PRINETTO@POLITO.IT Subject: Hardware Verification course, July 6 - 10 I've been asked to forward the following course announcement. Feel free to forward it further as you see fit. I've been told: >> People in L'Aquila will be able to confirm the course 2-3 weeks before, not >> earlier. Please forward the program to people on your mailing list that >> are probably interested in formal techniques. Date: Tue, 24 Mar 1992 19:42 GMT+1 From: PRINETTO@POLITO.IT Subject: summer course program: please forward To: borrione@imag.imag.fr, ac@hplb.hpl.hp.com, camurati@POLITO.IT, claesen@imec.be, Edmund_Clarke@G.GP.CS.CMU.EDU, denicola@icnucevm.cnuce.cnr.it, xbr4d75r%DDATHD21.bitnet@CUNYVM.CUNY.EDU, kaufmann@cli.com, milne@computer-science.strathclyde.ac.uk, prinetto@polpp.TO.CNR.IT, fabio@duke.Colorado.EDU, soulas@rem63ax.edf.fr X-Envelope-To: kaufmann@cli.com X-Vms-To: @LECTURER.DIS Advanced Course on Formal Verification Techniques in VLSI Design ---------------------------------------------------------------- SSGRR - L'Aquila, Italy 6 - 10 July 1992 Objectives ---------- If we are to take full advantage of VLSI's enormous potentialities, zero- defect design is an essential goal. No designer will ever be able to verify the correctness of his work without the help of appropriate CAD tools. Simulation is the state of the art technique to prove correctness, but its drawbacks are widely known. An alternative approach is ``formal verification'', where the proof is mathematical, rather than experimental. Mathematical demonstration overcomes the limits of test case simulation, since it is valid for all input stimuli under specified assumptions. Formal techniques are getting out of their infancy and we already witness their introduction in industrial environments. The course aims at introducing the most widely adopted formal veri- fication techniques, outlining the related theories and their limits. State-of-the-art techniques and novel research efforts will be considered, as well as their relationship with VHDL. The applicability of each ap- proach will be shown in practice during demos, guided and hands-on experi- ments on popular tools. Formal verification's merits and limits will be critically assessed, the synergy between verification and synthesis toward zero-defect VLSI de- signs will be analyzed, and industrial experience will be discussed. The main topics of this course are: high-level description and validation of hardware designs with process algebras (the Circal system), Petri Nets (the EVAL system), and VHDL (the Prevail proof environment); propositional logic (BDD's and tautology checking); first-order logic (the Boyer-Moore and OTTER theorem provers); higher-order logic (the HOL system); temporal logic and model checking (the SMV system). As application examples, switch- level descriptions, control-dominated FSM's, data paths & control units, and properties of communicating FSM's will be considered. The impact of formal verification techniques on synthesis and testing will be analyzed. Target Audience --------------- The course is mainly devoted to managers, designers, engineers, and students who want to get acquainted with novel techniques and tools to formally specify, validate, and prove hardware designs. Faculty ------- Course Director Prof. Paolo PRINETTO Politecnico di Torino, Turin (I) Lecturers D. BORRIONE (IMAG/Artemis, Grenoble (F)) A.J. CAMILLERI (Hewlett Packard Labs, Bristol (UK)) P. CAMURATI (Politecnico di Torino, Turin (I)) L. CLAESEN (IMEC / Kath. Univ. Leuven, Leuven (B)) E.M. CLARKE (Carnegie-Mellon University, Pittsburgh (USA)) R. DE NICOLA (Universita' di Roma "La Sapienza", Rome (I)) H. EVEKING (Technische Hochschule Darmstadt, Darmstadt (D)) M. KAUFMANN (CLI, Austin (USA)) G.J. MILNE (Strathclyde University, Glasgow (UK)) P. PRINETTO (Politecnico di Torino, Turin (I)) F. SOMENZI (University of Colorado, Boulder (USA)) B. SOULAS (Electricite' de France, Paris (F)) Course Contents --------------- ------------------- Monday, July 6 1992 ------------------- 09.00 - 09.30 Course presentation (P. Prinetto) 09.30 - 11.00 Towards zero-defect designs (P. Prinetto) 11.00 - 13.00 The Boyer-Moore theorem prover: basic principles (M. Kaufmann) 14.30 - 16.30 Verification from transistor switch level upwards (L. Claesen) 16.30 - 17.30 Guided hands-on experience: the Boyer-Moore theorem prover (M. Kaufmann) 17.30 - 18.30 Guided hands-on experience: switch-level verification (L. Claesen) 18.30 - 20.00 Optional hands-on experience: the Boyer-Moore theorem prover (M. Kaufmann, P.Camurati, P. Prinetto) Optional hands-on experience: switch-level verification (L. Claesen, P.Camurati, P. Prinetto) -------------------- Tuesday, July 7 1992 -------------------- 09.00 - 11.00 BDDs, tautology checking & demo (H. Eveking) 11.00 - 13.00 Temporal Logic & Model Checking: basic principles (E.M. Clarke) 14.30 - 16.30 Higher-order logic & HOL (A. Camilleri) 16.30 - 17.30 Guided hands-on experience: the SMV system (E.M. Clarke) 17.30 - 18.30 Guided hands-on experience: the HOL system (A. Camilleri) 18.30 - 20.00 Optional hands-on experience: the SMV system (E.M. Clarke, P. Camurati, P. Prinetto) Optional hands-on experience: the HOL system (A. Camilleri, P. Camurati, P. Prinetto) ---------------------- Wednesday, July 8 1992 ---------------------- 09.00 - 11.00 First-order logic & OTTER (P. Camurati) 11.00 - 13.00 Formal verification of designs described in VHDL (D. Borrione) 14.30 - 16.30 Predicate/Transition Petri Nets and the EVAL system (B. Soulas) 16.30 - 17.30 Guided hands-on experience: the PREVAIL VHDL proof environment (D. Borrione) 17.30 - 18.30 Guided hands-on experience: the EDF approach to communication protocol specification, validation, verification, and test (B. Soulas) 18.30 - 20.00 Optional hands-on experience: the PREVAIL VHDL proof environment (D. Borrione, P.Camurati, P. Prinetto) Optional hands-on experience: the EVAL system (B. Soulas, P.Camurati, P. Prinetto) --------------------- Thursday, July 9 1992 --------------------- 09.00 - 13.00 Process Algebras (R. De Nicola) 14.30 - 16.30 The Circal System: basic principles (G.J. Milne) 16.30 - 17.30 Guided hands-on experience: the Circal System (G.J. Milne) 17.30 - 18.30 Guided hands-on experience: the OTTER theorem prover (P. Prinetto) 18.30 - 20.00 Optional hands-on experience: the Circal System (G.J. Milne, P.Camurati, P. Prinetto) Optional hands-on experience: the OTTER theorem prover (P.Camurati, P. Prinetto) -------------------- Friday, July 10 1992 -------------------- 09.00 - 12.00 FSM verification and its application to synthesis and testing \ demo (F. Somenzi) 12.00 - 13.00 Roundatble Affiliations ------------ prof. Dominique BORRIONE Institut IMAG Laboratoire Artemis B.P. 53X F-38041 Grenoble Cedex France Tel: + 33 76 514604 ext 5240 Fax: + 33 76 519637 E-mail: borrione@imag.imag.fr dr. Albert J. CAMILLERI Hewlett Packard Labs. Information Systems Centre Filton Road Stoke Gifford Bristol BS12 6QZ UK Tel: + 44 272 799910 ext 24196 Fax: + 44 272 790554 E-mail: ac@hplb.hpl.hp.com dr. Paolo CAMURATI Politecnico di Torino Dip. di Automatica e Informatica Corso Duca degli Abruzzi 24 I-10129 Turin Italy Tel: + 39 11 564.7009 Fax: + 39 11 564.7099 E-mail: camurati@polito.it prof. Luc CLAESEN IMEC / Kath. Univ. Leuven Kapeldreef 75 B-3001 Leuven Belgium Tel: + 32 16 281.203 Fax: + 32 16 229.515 E-mail: claesen@imec.be prof. Edmund M. CLARKE Dept. of Computer Science Carnegie-Mellon University Schenley Park Pittsburgh PA 15213 USA Tel: + 1 412 268 2628 Fax: + 1 412 268 5016 E-mail: Edmund_Clarke@G.GP.CS.CMU.EDU prof. Rocco DE NICOLA Universita' di Roma "La Sapienza" Dip. Matematica Via Salaria 113 I-00184 Rome Italy Tel: + 39 6 884.1957 Fax: + 39 6 884.1964 E-mail: denicola@icnucevm.cnuce.cnr.it dr. Hans EVEKING Institut fuer Datentechnik Technische Hochschule Darmstadt Merckstrasse 25 D-6100 Darmstadt Fed. Rep. Germany Tel: + 49 6151 16.2075 Tel: + 49 6151 16.2076 Fax: + 49 6151 16.4976 E-mail: xbr4d75r@ddathd21.bitnet dr. Matt KAUFMANN Computational Logic, Inc. 1717 W. Sixth St. Suite 290 Austin, TX 78703 USA Tel: + 1 512 322-9951 Fax: + 1 512 322-0656 E-mail: kaufmann@cli.com dr. George J. MILNE Dept. of Computer Science University of Strathclyde 26 Richmond Street Livingstone Tower Glasgow G1 1XQ UK Tel: + 44 41 552 4400 ext 3551 Fax: + 44 41 552 0775 E-mail: milne@computer-science.strathclyde.ac.uk prof. Paolo PRINETTO Politecnico di Torino Dip. di Automatica e Informatica Corso Duca degli Abruzzi 24 I-10129 Turin Italy Tel: + 39 11 564.7007 Fax: + 39 11 564.7099 E-mail: prinetto@polpp.to.cnr.it prof. Fabio SOMENZI University of Colorado at Boulder Dept. of Elec. and Com. Eng. Eng. Center, Campus Box 425 Boulder, CO 80309-0425 USA Tel: + 1 303 492.3466 Fax: + 1 303 492.2758 E-mail: fabio@duke.Colorado.EDU dr. Bernard SOULAS Electricite' de France Direction des Etudes et Recherches Service Materiel Electrique Dept. C.I.M.A. Les Renardieres Boite Postale n. 1 F-77250 Moret sur Loing France Tel: + 33 1 60706343 Fax: + 33 1 60706543 E-mail: soulas@rem63ax.der.edf.fr  Received: by CLI.COM (4.1/1); Thu, 9 Apr 92 02:30:42 CDT Received: by enet-gw.pa.dec.com; id AA13399; Thu, 9 Apr 92 00:33:08 -0700 Message-Id: <9204090733.AA13399@enet-gw.pa.dec.com> Received: from hpsrad.enet; by decwrl.enet; Thu, 9 Apr 92 00:33:08 PDT Date: Thu, 9 Apr 92 00:33:08 PDT From: "HEMENDRA TALESARA, DEC FT SYSTEMS, (508) 467-5541 08-Apr-1992 1836" To: nqthm-users@Pa.dec.com Apparently-To: nqthm-users@cli.com Subject: FWD: CADE-11 ------------------Forwarded item dated 8-APR-1992 18:31:44.12------------------ CADE-11 General Information The Eleventh International Conference on Automated Deduc- tion will be held at the Ramada Renaissance Hotel in Saratoga Springs, NY and will be hosted by the State University of New York at Albany. Forms for conference registration and room reservations, brochures and maps providing information about local hotels/motels and restaurants, a preliminary program listing, and the conference poster are being sent via regular mail. The conference will begin with a welcome reception at the Ramada Renaissance Hotel on Sunday, June 14, 7:00pm - 9:00pm. The tutorials will take place on Monday, June 15. Paper presentations will occur Tues. - Thurs., 6/16-18. During the conference, several workstations will be available for demons- tration of working systems. The conference banquet will be held on Tuesday evening and will feature Ray Smullyan as the speaker. For Wednesday, an excursion dinner is planned on board the Lac du Saint Sacre- ment, which will sail the southern basin of beautiful Lake George. More specific information on travel, accommodations, conference tutorials and events, and system demonstration capa- bilities, is outlined below. TRAVEL INFORMATION Special rates for CADE-11 attendees are being offered by Delta Air Lines, Inc. A 40% reduction on applicable coach fares can be obtained if tickets are purchased at least 7 days prior to departure. These tickets are sold on a limited seat basis, but are fully refundable. Except for Canadian origina- tions, a 5% discount is offered on promotional fares (e.g., super-saver fares). To obtain these discounts, you or your travel agent should call 1-800-221-1212, and refer to file reference G32069. Saratoga Springs is 25 miles north of the Albany airport just off Interstate I87. For those planning to rent a car, the drive is very easy, about 25 min. (We suggest driving at or below 65 mph; I87 is heavily patroled by NYS Police.) Average taxi fare from the airport to Saratoga is about $30. However, attendees may call Central Taxi (346-2344 or 346-1231), identify themselves as CADE-11 participants, and obtain a single person rate of around $25. If several atten- dees are requesting transportation at the same time, the cost per person will decrease; depending on demand, vans or busses will be dispatched to provide service, and the cost will be April 5, 1992 - 2 - lower still. Similar arrangements will be employed for those returning to the airport from Saratoga after the conference. Other options include bus (Trailways) connections from downtown Albany, and train (Amtrak) connections via the Albany-Rensselaer Station and via Penn Station in NY City, to Saratoga. ACCOMMODATIONS Room blocks are being held by the Ramada, Holiday Inn, and Rip Van Dam motels. Rates start at $75, $58, and $40, for these motels, respectively. All three are on Broadway, Saratoga's main road. The Ramada is next to the City Center; the Holiday Inn is at Broadway and Circular; the Rip Van Dam is near Broadway and Washington St. The latter two motels are about 12 and 7 minutes walking distance from the Ramada, respectively. The brochures (and map) we are sending will give you the approximate location of these motels and information on many others. Room reservation forms should be mailed directly to the motel at which the reservation is requested. All three motels require one night's deposit. Personal checks in U.S. dollars or credit card numbers may be supplied; Holiday Inn reserva- tions may also be made by calling 1-800-HOLIDAY and giving the three-letter code "CAD." Note that reservation deadlines vary somewhat among the motels; see the enclosed forms for details. CONFERENCE EVENTS The registration fee is $250 before May 15, and $275 afterwards. Students may register for $100. The conference banquet will be held at the Hall of Springs on Tuesday night, June 16. Ray Smullyan will be the banquet speaker; his talk is entitled ``Puzzles and Paradoxes.'' The banquet is free for conference attendees and costs $25 for additional guests. On Wednesday night an excursion dinner cruise is planned. We have chartered Lake George's largest (capacity of up to 1000 passengers) and newest cruise ship, the Lac du Saint Sacrement. Lake George is one of America's most famous lakes. It is from one to four miles wide, about 32 miles long, and is virtually surrounded by small mountains. Even today, its waters are clear enough that objects can be observed at a depth of 20 feet on sunny days. The excursion is $25 for those registered at the conference, $50 for additional guests. Busses will be provided for transport to and from both the banquet and the excursion. SYSTEM DEMONSTRATIONS We will have a room dedicated to software demos; SUN Microsystems, Inc. is lending five workstations for our use (SPARC-2, IPX, and IPC). The installed operating system will be SUN OS 4.1 (or greater). The machines will be stand-alone April 5, 1992 - 3 - with local disk, @quarter@-inch tape cassette, and at least 16M of RAM. If you would like to use these facilities to demonstrate a working system, please contact the Local Arrangements Chair at the conference address via regular or e-mail. Sorry - demo systems must be brought on tape; we will not be receiving software over the net. Those exhibiting systems built on LISP, Prolog, or another language are advised to bring and install what they need, when in doubt. CONFERENCE TUTORIALS Five tutorials will be held on Monday, June 15; the fee is $40. for each tutorial attended (maximum of three). April 5, 1992 - 4 - CADE - 11 Preliminary Program Sunday, June 14 Reception: 7:00pm (Renaissance Ramada) Monday, June 15 Tutorial 1 Peter Andrews & Frank Pfenning 9:00am - 11:30am TUTORIAL ON TYPE THEORY This tutorial will provide a basic introduction to type theory, with emphasis on formulations employing typed @lambda@- calculi. Both classical and constructive type theories, which provide foundations for mathematics and computer science, will be covered. Tutorial 2 John Slaney & Ewing Lusk 9:00am - 11:30am Finding Models: Techniques and Applications This tutorial is in three parts. In the first part we describe some backtracking search methods for generating models of first order theories. Secondly, we describe the use of back- tracking search as a style of reasoning suitable for some kinds of problem solving. Finally, we discuss model finding as part of an automated deduction system. Tutorial 3 Edmund Clarke 1:00pm - 3:30pm Symbolic Model Checking - @10 sup 130@ States and Beyond In this tutorial we will describe the theoretical basis for Symbolic Model Checking and discuss how it has been used to veri- fy some realistic examples. If facilities are available we will also demonstrate the use of the verifier. Tutorial 4 Helene Kirchner and Michael Rusinowitch Term Rewriting Techniques This tutorial is an attempt to give a progressive and homo- geneous presentation of applications of term rewriting to automated theorem proving. Theorem proving methods are presented using a common formalism of inference rules to emphasize the April 5, 1992 - 5 - connections and common features among the different theorem prov- ing systems. Tutorial 5 Hubert Comon and Claude Kirchner 4:00pm - 6:30pm Constraints on Trees This tutorial presents several constraint systems, i.e. for- mulae together with a semantic domain and a constraint solving technique; we consider only interpretations in term algebras T(F,X) or T(F,X)/(=E). These kinds of constraints are particu- larly useful in automated deduction with constraints and in logic programming with constraints, in particular for reducing the com- plexity of computations and expressing strategies. April 5, 1992 - 6 - Tuesday, June 16 Session I 9:30am - 10:30am Larry Wos Keynote Adress Award Presentation Break 10:30am - 11:00am Session II 11:00am - 12:30pm Kurt Ammon Automatic Proofs in Mathematical Logic and Analysis Shang-Ching Chou and Xiao-Shan Gao Proving Geometry Statements of Constructive Type L.M. Hines The Central Variable Strategy of Str+ve Lunch 12:30pm - 1:30pm Session III A 1:30pm - 3:30pm Franz Baader and Klaus U. Schulz Unification in the Union of Disjoint Equational Theories: Com- bining Decision Procedures Tobias Nipkow and Zhenyu Qian Reduction and Unification in Lambda Calculi with Subtypes Daniel J. Dougherty and Patricia Johann A Combinatory Logic Approach to Higher-Order E-Unification " " " Wolfgang Bibel, Steffen Holldobler and Jorg Wurtz Cycle Unification Session III B 1:30pm - 3:30pm Katherine A. Yelick and Stephen J. Garland A Parallel Completion Procedure for Term Rewriting Systems David McAllester Grammar Rewriting Adam Cichon and Pierre Lescanne Polynomial Interpretations and the Complexity of Algorithms Leonidas Fegaras, Tim Sheard and David Stemple Uniform Traversal Combinators: Definition, Use and Properties Session IV 4:00pm - 5:30pm , Tomas E. Uribe Sorted Unification Using Set Constraints Alan M. Frisch and Anthony G. Cohn An Abstract View of Sorted Unification Alexandre Boudet Unification in Order-Sorted Algebras with Overloading April 5, 1992 - 7 - Session V Banquet Address: Raymond Smullyan, ``Puzzles and Paradoxes'' Conference Banquet 6:45pm - 9:00pm, Hall of Springs Wednesday, June 17 Session VI 9:00am - 10:30am William McCune and Larry Wos Experiments in Automated Deduction with Condensed Detachment Owen L. Astrachan and Mark E. Stickel Caching and Lemmaizing in Model Elimination Theorem Provers Vincent J. Digricoli and Eugene Kochendorfer LIM+ Challenge Problems by RUE Hyper-Resolution Break 10:30am - 11:00am Session VII 11:00am - 12:30pm Peter Jackson Computing Prime Implicates Incrementally Geoff Sutcliffe Linear-Input Subset Analysis Belaid Benhamou and Lakhdar Sais Theoretical Study of Symmetries in Propositional Calculus and Applications Lunch 12:30pm - 1:30pm Session VIII A 1:30pm - 3:30pm David Basin and Toby Walsh Difference Matching Jane Hesketh, Alan Bundy and Alan Smaill Using Middle-Out Reasoning to Control the Synthesis of Tail- Recursive Programs Toby Walsh, Alex Nunes and Alan Bundy The Use of Proof Plans to Sum Series Martin Protzen Disproving Conjectures Session VIII B 1:30pm - 3:30pm Mathias Bauer An Interval-based Temporal Logic in a Multivalued Setting Michael Fisher A Normal Form for First-Order Temporal Formulae , Ricardo Caferra and Stephane Demri Semantic Entailment in Non Classical Logics Based on Proofs Found in Classical Logic Katsumi Inoue, Miyuki Koshimura and Ryuzo Hasegawa Embedding Negation as Failure into a Model Generation Theorem Prover Break 3:30pm - 4:00pm April 5, 1992 - 8 - Session IX 4:00pm - 5:30pm Robert S. Boyer and Yuan Yu Automated Correctness Proofs of Machine Code Programs for a Commercial Microprocessor Hantao Zhang and Xin Hua Proving the Chinese Remainder Theorem by the Cover Set Induc- tion Peter Madden Automatic Program Optimization Through Proof Transformation Excursion Dinner Cruise on Lake George on the Lac du Saint Sacrement 6:30pm - 10:30pm Thursday, June 18 Session X 9:00am - 10:00am Invited Talk: Grigori Mints, ``Proof Search Theory and Practice in the (former) USSR'' Break 10:30am - 11:00am Session XI 10:30am - 12:30pm Leo Bachmair, Harald Ganzinger, Christopher Lynch and Wayne Snyder Basic Paramodulation and Superposition Robert Nieuwenhuis and Albert Rubio Theorem Proving with Ordering Constrained Clauses Zohar Manna and Richard Waldinger The Special-Relation Rules are Incomplete " Bernhard Beckert and Reiner Hahnle An Improved Method for Adding Equality to Free Variable Seman- tic Tableaux Lunch 12:30pm - 1:30pm Session XII A 1:30pm - 3:30pm N. Shankar Proof Search in the Intuitionistic Sequent Calculus Frank Pfenning and Ekkehard Rohwedder Implementing the Meta-Theory of Deductive Systems Wilfred Z. Chen Tactic-based Theorem Proving and Knowledge-based Forward Chaining: An Experiment with Nuprl and Ontic William M. Farmer, Joshua D. Guttman and F. Javier Thayer Little Theories April 5, 1992 - 9 - Session XII B 1:30pm - 3:30pm Jim Christian Some Termination Criteria for Narrowing and E-narrowing Nachum Dershowitz, Subrata Mitra and G. Sivakumar Decidable Matching for Convergent Systems Delia Kesner Free Sequentiality in Orthogonal Order-Sorted Rewriting Sys- tems with Constructors R.C. Sekar and I.V. Ramakrishnan Programming with Equations: A Framework for Lazy Parallel Evaluation Break 3:30pm - 4:00pm Session XIII 4:00pm - 5:30pm Anthony G. Cohn A Many Sorted Logic with Possibly Empty Sorts Andrei Voronkov Theorem Proving in Non-Standard Logics Based on the Inverse Method Konstantine Vershinin and Igor Romanenko One More Logic with Uncertainty and Resolution Principle for It System Abstracts Li Dafa A Natural Deduction Automated Theorem Proving System Tobias Nipkow and Lawrence Paulson Isabelle-91 Geoff Sutcliffe The Semantically Guided Linear Deduction System Kurt Ammon The SHUNYATA System Shang-Ching Chou A Geometry Theorem Prover for Macintoshes April 5, 1992 - 10 - Xin Hua and Hantao Zhang FRI: Failure-Resistant Induction in RRL Hantao Zhang Herky: High Performance Rewriting in RRL William M. Farmer, Joshua D. Guttman and F. Javier Thayer IMPS: System Description Geoffrey D. Alexander and David A. Plaisted Proving Equality Theorems with Hyper-Linking Jawahar Chirimar, Carl A. Gunter and Myra VanInwegen Xpnet: A Graphical Interface to Proof Nets with an Efficient Proof Checker Dave Barker-Plummer, Sidney C. Bailin and Andrew S. Merrill &: Automated Natural Deduction , Tomas E. Uribe, Alan M. Frisch and Michael K.chell An Overview of FRAPPS 2.0: A Framework for Resolution-Based Automated Proof Procedure Systems Dave Barker-Plummer, Alex Rothenberg The GAZER Theorem Prover Ewing Lusk, William McCune and John Slaney ROO: A Parallel Theorem Prover T.C. Wang and Allen Goldberg RVF: An Automated Formal Verification System Johann M.Ph. Schumann KPROP - An AND-parallel Theorem Prover for Propositional Logic Implemented in KL1 K. Blackburn A Report on ICL HOL S. Owre, J.M. Rushby and N. Shankar PVS: A Prototype Verification System Wolfgang Reif The KIV System: Systematic Construction of Verified Software Bernhard Beckert, Reiner Hahnle, Stefan Gerberding and Werner Kernig A The Tableau-Based Theorem Prover T P for Multiple-Valued Logics 3 Edmund Clarke and Xudong Zhao Analytica - A Theorem Prover in Mathematica Klaus Schneider, Ramayya Kumar and Thomas Kropf The FAUST-Prover Dan Craigen, Sentot Kromodimoeljo, Irwin Meisels, Bill Pase and Mark Saaltink Eves System Description Ryuzo Hasegawa, Miyuki Koshimura and Hiroshi Fa MGTP: A Parallel Theorem Prover Based on Lazy Model Generation April 5, 1992 - 11 - Problem Sets Ewing Lusk and Larry Wos Benchmark Problems in which Equality Plays the Major Role D.A. Randell, A.G. Cohn and Z. Cui Computing Transitivity Tables: A Challenge for Automated Theorem Provers % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by enet-gw.pa.dec.com; id AA27641; Wed, 8 Apr 92 15:27:19 -0700 % Received: by inet-gw-1.pa.dec.com; id AA04273; Tue, 7 Apr 92 22:55:41 -0700 % Received: from iris.cs.ucdavis.edu by toadflax.cs.ucdavis.edu (4.1/UCD.CS.1.1)id AA20136; Tue, 7 Apr 92 22:26:04 PDT % Received: by iris.cs.ucdavis.edu (5.57/UCD.CS.1.1)id AA14409; Tue, 7 Apr 92 22:25:49 -0700 % Received: from herbrand.albany.edu by cssun.albany.edu (5.65/SMI-3.2)id ; Wed, 8 Apr 92 01:25:18 -0400 % Received: by herbrand.albany.edu (5.65/ALBANY_CS-1.1)id AA11179; Wed, 8 Apr 92 01:24:46 -0400 % Date: Wed, 8 Apr 92 01:24:46 -0400 % From: nvm@cs.albany.edu (Neil Murray) % Message-Id: <9204080524.AA11179@herbrand.albany.edu> % To: info-hol@cs.ucdavis.edu % Subject: CADE-11 Received: by CLI.COM (4.1/1); Thu, 9 Apr 92 14:42:59 CDT Received: by enet-gw.pa.dec.com; id AA20772; Thu, 9 Apr 92 12:45:33 -0700 Message-Id: <9204091945.AA20772@enet-gw.pa.dec.com> Received: from hpsrad.enet; by decwrl.enet; Thu, 9 Apr 92 12:45:34 PDT Date: Thu, 9 Apr 92 12:45:34 PDT From: "HEMENDRA TALESARA, DEC FT SYSTEMS, (508)467-5541 09-Apr-1992 1549" To: nqthm-users@Pa.dec.com Cc: talesara@hpsrad.enet.dec.com Apparently-To: nqthm-users@cli.com Subject: FWD: [cdk@dit.upm.es (Carlos Delgado Kloos): IFIP 92] ------------------Forwarded item dated 9-APR-1992 15:45:58.35------------------ Dear colleague, please find below an announcement of the World Computer Congress IFIP 92 to be held in Madrid 7-11 September 1992. Please note that the deadline for submitting posters has been extended until 30 April 1992. The technical program with the selected papers (171 from almost 500 submissions) will be published soon. Yours sincerely, Carlos Delgado Kloos IFIP 92 PC vicechair - -------------------------------------------------------------------- Some highlights that might be of interest to you: Tutorial * Randy Bryant (Carnegie Mellon Univ. Pittsburgh, USA): Automated Approaches to Formal Hardware Analysis and Verification Keynote Speaker * Jozef Cornu (Alcatel NV, Executive Vice-president of Technical Operations) Invited Speaker: * Alain Martin (Caltech, Pasadena, Ca., USA): Tomorrow's Digital Hardware will be Asynchronous and Verified Panels: * The CAD Tool for the Future Gerald Musgrave (Brunel Univ./AHL, London, UK), Raymond Boute (Univ. of Nijmegen, The Netherlands), Randy Bryant (Carnegie Mellon Univ. Pittsburgh, USA), Mike Fourman (Univ. of Edinburgh/AHL, UK), Franz Rammig (Univ. Paderborn/CADLAB, Paderborn, Germany) * Concurrent Engineering Egon Hoerbst (Siemens, Munich, Germany), Siegfried Jahn (Siemens, Munich, Germany), Michael Wozny (Politechn. Institute, Rensselaer Design & Research Center, Troy, N.Y., USA), B. Chown (Mentor Graphics, UK), D. Siewiorek (Carnegie-Mellon Univ., Pittsburgh, PA, USA), M. Broy (Techn. Univ. Munich, Munich, Germany) and many, many other very interesting events (see below). - -------------------------------------------------------------------- Final Call for Papers and Preliminary Programme __________________________________________________________ ! ! ! ! ! 12th World Computer Congress ! ! ! ! ! ! IFIP Congress 92 ! ! ! ! ! ! FROM RESEARCH TO PRACTICE ! ! ! !________________________________________________________ ! Madrid, Spain September 7-11, 1992 IFIP International Federation for Information Processing FESI Federacion Espa~nola de Sociedades de Informatica Overview of the Congress This IFIP Congress is composed of topical and interrelated conferences each organized by a separate subcommittee of the International Program Committee. * Five parallel streams - Software Development and Maintenance - Algorithms and Efficient Computation - From Architectures to Chips - Informatics and Education - The Vulnerability of the Information Society * Two subconferences - Expanding the Power of the Personal Computer - Enhancing the Intelligence in Information Systems The Congress will also include: * One day symposia * Tutorials * A specialized exhibition The IFIP Congress 92 offers researchers and practitioners an opportunity to present their ideas and experiences to an international audience by means papers or posters. Papers will be published by Elsevier in the Congress proceedings. Poster abstracts will be mimeographed for all Congress participants. _______________________________________________________________________________ International Program and Organizing Committees International Program Committee: Chair: Wilfried Brauer (Technical University, Munich, Germany) Vice Chair: Carlos Delgado Kloos (Technical University, Madrid, Spain) Past Chair: Herve Gallaire (GSI, Paris, France) Organizing Committee: Chair: Rosa Alonso (Alcatel Standard Electrica, Madrid, Spain) Vice Chair: Jaume Argila (Asociacion de Tecnicos de Informatica, Spain) Vice Chair: Jose Ignacio Boixo (Asociacion de Licenciados en Informatica, Spain) Vice Chair: Miguel Angel Eced (Asociacion Espa~nola de Informatica y Automatica, Spain) _______________________________________________________________________________ How to Submit a Paper Six (6) copies of the full paper should be sent to the appropriate subcommittee chair so as to arrive by January 10, 1992. The paper has to be written in English. Papers should be no longer than 4500 words or less if tables, diagrams, or pictures are included. Include full title, name and affiliation of author(s) as well as postal and electronic mail addresses, and telephone and fax numbers. A 150 word abstract must also be part of the paper. All papers will be reviewed by at least three referees. Relevance, originality, and clarity will be considered. All authors must state that their paper has not been submitted elsewhere. Acceptance of the paper implies a commitment on the part of the author(s) to present it at the Congress. _______________________________________________________________________________ How to Submit a Poster Three (3) copies of a one page abstract for a 10 minute presentation should be sent to the appropriate subcommittee chairman so as to arrive by April 30, 1992. The poster proposal will be judged for relevance and clarity. Acceptance/rejection will be notified by May 15, 1992. The final version of the abstract has to be sent to the organizing committee for inclusion into the poster brochure so as to arrive by June 20, 1992. _______________________________________________________________________________ Key Dates January 10, 1992: Deadline for submission of full papers March 9, 1992: Notification of acceptance/rejection of papers April 30, 1992: Deadline for submission of poster abstracts April 24, 1992: Camera ready copy of revised papers received by Program Committee May 15, 1992: Notification of acceptance/rejection of posters June 20, 1992: Camera readycopy of poster abstracts received by Organizing Committee September 7-11, 1992: World Computer Congress, Madrid _______________________________________________________________________________ Keynote Speakers * Pamela McCorduck: Art, Complexity, and Artificial Intelligence (Famous writer: "Machines who Think", "The Fifth Generation", "The Universal Machine", "The Rise of the Expert Company", "Aaron's Code: Art,Artificial Intelligence, and the Work of Harold Cohen", etc., Princeton, N.J., USA): * Philip Kahn (Chairman, C.E.O., and President of Borland International, Scotts Valley, CA, USA): Software Craftsmanship in the 90's * Jozef Cornu (Alcatel NV, Executive Vice-president of Technical Operations) * Michel Carpentier (Director General of DG XIII of the Commission of the European Communities) * Josep Maria Vil'a (Director of Resources of the Olympic Games 1992) _______________________________________________________________________________ Tutorials * Randy Bryant (Carnegie Mellon Univ. Pittsburgh, USA): Automated Approaches to Formal Hardware Analysis and Verification * B. Levrat (UNiv. of Geneva, Switzerland), S. Franklin (Univ. of California, Irvine, CA, USA): Supporting an Integrated Heterogeneous Environment * L. Hoffman (The George Washington Univ, Washington, DC, USA): Computers, Privacy, and Freedom * H.L. Highland (New York, USA): Detection and elimination of MAlicious Software (Viri, Trojans, etc.) * T.W. Olle (T.W. Olle Associates, UK), A.A. Verrijn Stuart (Leiden Univ., The Netherlands): Information System Methodologies. A Framework for Understanding * J.P Laurent (Univ. of Savoie, France): Validation, Verification and Testing of Knowledge-Based Systems _______________________________________________________________________________ _______________________________________________________________________________ Stream: Software Development and Maintenance The technology supporting the development and maintenance of software is steadily improving along a broad front. Since it is evident that no single method or technique will increase our ability to create and extend software systems by an order of magnitude, there is considerable merit in trying to integrate various ideas and apply them jointly to both the software development process and the software product. _______________________________________________________________________________ * programming environments and tools (design, implementation, and application) * formal methods * program and system reusability * software development methodologies, practice, and experience * programming language design and usage * technology transfer _______________________________________________________________________________ Invited Speakers: * D. Turner: On Declarative Languages * J.R. Abrial: on Formal Methods * A. Snyder: On Developing Large Software Systems * S. Reiss: On Programming Environments Panels: * Is object-oriented programming useful? * Are formal methods really useful? * The future of programming environments and tools _______________________________________________________________________________ Programme Committee: Chair: A. N. Habermann Carnegie Mellon University, Pittsburgh, USA P. Botella Technical University of Catalunya, Barcelona, Spain L. M. Koroleff Moscow State University, Moscow, USSR R. Kurki-Suonio Technological University of Tampere, Tampere, Finland A. Yonezawa University of Tokyo, Tokyo, Japan _______________________________________________________________________________ The posters for this stream should be submitted to: Professor A. Nico Habermann School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213-3890 USA Fax: (+1-412)681-5793 E-mail: anh@cs.cmu.edu _______________________________________________________________________________ _______________________________________________________________________________ Stream: Algorithms and Efficient Computation Algorithms capture all computational techniques and mechanisms used in computer science. The search for efficient algorithms is motivated by the need for competitive computer applications in all branches of information processing and computing. This stream aims at presenting a broad view of the current achievements and developments in algorithms research,with attention to both the theoretical and the applied aspects of this field. Papers are solicited on all topics of interest in the area of the Design, Analysis and Application of Efficient Algorithms. Both original research contributions and papers of a more expository nature (e.g. describing the state-of-the-art in a particular area of algorithm-oriented research) are welcomed. Topics of interest include e.g. _______________________________________________________________________________ * data structures and graph algorithms * on-line algorithms * computational geometry, computer graphics and robotics * combinatorial optimization * parallel algorithms and computation * distributed computing * novel computational models (including e.g. neural networks) * computational learning * complexity theory and cryptography * symbolic computation * continuous algorithms and their complexity and all related fields dealing with algorithm design and computational complexity. _______________________________________________________________________________ Invited Speakers: * F.T. Leighton (MIT, Cambridge, MA, USA): Novel Approaches to Message Routing in Large-Scale Parallel Machines * S. Micali (MIT, Cambridge, MA, USA): Advances in Cryptography * J.D. Boissonnat (INRIA Sophia-Antipolis, Valbonne, France): New Directions in Robot Motion Planning * R.M. Karp (Univ. of California, Berkeley, CA, USA): On-line Algorithms versus Off-line Algorithms: How Much is It Worth to Know the Future? * K. Mehlhorn (Max-Planck Institut fuer Informatik, Saarbruecken, Germany): Algorithm Design and Software Libraries ______________________________________________________________________________ Programme Committee: Chair: J. van Leeuwen University of Utrecht, Utrecht, The Netherlands J. Diaz Technical University of Catalunya, Barcelona, Spain S. Even The Technion, Haifa, Israel R. M. Karp University of California at Berkeley, Berkeley, USA _______________________________________________________________________________ The posters for this stream should be submitted to: Professor Jan van Leeuwen Department of Computer Science University of Utrecht P.O. Box 80.089 Padualaan 14 NL-3584 CH Utrecht The Netherlands Fax: (+31-30) 513791 E-mail: jan@cs.ruu.nl _______________________________________________________________________________ _______________________________________________________________________________ Stream: From Architectures to Chips The technology development has provided a tremendous growth in chip-complexity and circuit speed. However, the solution of very large computational problems, requires parallel processing in addition to high circuit speeds. This stream will cover all aspects of computer technology ranging from architectures for parallel and concurrent computing to the design and implementation of Application Specific Integrated Circuits (ASIC's). Particular attention will be put on the correct operation of hardware,including issues of fault tolerance as well as formal methods for assuring functional correctness. The stream will deal with theoretical as well as practical aspects, applications, and trends. Specific areas of interest are: _______________________________________________________________________________ * Parallel and distributed computing * Supercomputers * Hardware/software dependability (fault tolerance, availability, reliability, safety, and security) * Formal aspects of hardware design (formally based foundations, languages, tools, and methods for hardware design with practical application) * VLSI design, design tools, CHDLs, frameworks * Workstation concepts and graphics * Neural networks * Performability (performance + reliability) modeling and evaluation _______________________________________________________________________________ Invited Speakers: * Hajime Ishikawa (Fujitsu, Atsugi, Japan): Progress Trends and Perspective of VLSI Technology * Jean-Claude Laprie (LAAS-CNRS, Toulouse, France): Fundamental Concepts and Taxonomy of System Dependability * Alain Martin (Caltech, Pasadena, Ca., USA): Tomorrow's Digital Hardware will be Asynchronous and Verified * David May (Inmos, Bristol, UK): General Purpose Parallel Computers * John Meyer (Univ. of Michigan, Ann Arbor, Michigan, USA): The Role of Modeling and Evaluation in the Design Process * Michele Morganti (Italtel, Settimo Milanese, Italy): Dependability Issues in Telecommunications Panels: * Parallel and Distributed Computing Arndt Bode or Thomas Bemmerl (Technical University, Munich, Germany), Michel Cosnard (Ecole Normale Sup.de Lyon, Lyon, France), David May (Inmos, Bristol, UK), Gerry Reijns (University of Technology, Delft, Netherlands), etc. * The CAD Tool for the Future Gerald Musgrave (Brunel Univ./AHL, London, UK), Raymond Boute (Univ. of Nijmegen, The Netherlands), Randy Bryant (Carnegie Mellon Univ. Pittsburgh, USA), Mike Fourman (Univ. of Edinburgh/AHL, UK), Franz Rammig (Univ. Paderborn/CADLAB, Paderborn, Germany) * Dependability Issues in Distributed and Realtime Systems Kane H. Kim (Univ. of California, Irvine, Ca., USA), Hermann Kopetz (Techn. Univ. of Vienna, Austria), Gerald LeLann (INRIA, Le Chesnay, France), Luca Simoncini (IEI del CNR, Pisa, Italy), T. Basil Smith (IBM, Yorktown Heights, NY, USA) * Concurrent Engineering Egon Hoerbst (Siemens, Munich, Germany), Siegfried Jahn (Siemens, Munich, Germany), Michael Wozny (Politechn. Institute, Rensselaer Design & Research Center, Troy, N.Y., USA), B. Chown (Mentor Graphics, UK), D. Siewiorek (Carnegie-Mellon Univ., Pittsburgh, PA, USA), M. Broy (Techn. Univ. Munich, Munich, Germany) _______________________________________________________________________________ Programme Committee: Chair: G.Reijns Delft University of Technology, Delft, The Netherlands C. Delgado Kloos Technical University, Madrid, Spain E. Hoerbst Siemens A.G., Munich, Germany Y. Tohma Tokyo Institute of Technology, Tokyo, Japan _______________________________________________________________________________ The posters for this stream should be submitted to: Professor Gerard L. Reijns Delft University of Technology Mekelweg 4 NL-2628 CD Delft The Netherlands Fax: (+31-15) 784898 E-mail: gjduve@et.tudelft.nl _______________________________________________________________________________ _______________________________________________________________________________ Stream: Informatics and Education Over the past three decades computers have made enormous inroads into all levels of education. From a start with teaching about computers we are now facing a reality where teaching with computers is becoming the common situation ineducation. The Informaticsand Education Stream of the 12th IFIPCongress offers researchers and practitioners an opportunity to present their ideas and experiences to an international audience. The stream will cover all aspects of the theme "Informatics and Education": Computing in universities will be dealt with as well as computing in elementary education.Research issues on information technology will be discussed as well as how research outcomes can be applied in practice. Equity issues in computing will be treated, the gender aspect as well as the cultural and socioeconomic aspects will be brought to discussion. The technology to be used in education will also be a topic, e.g. the pedagogical use of networks in distance education. Papers and panel discussions on these aspects and more will be allocated to four ministreams payingsp ecial attention to: _______________________________________________________________________________ * The changing role of university computing centers * Computer equity * Applying research to support learners * Teleteaching _______________________________________________________________________________ Invited Speakers: * Magda Bruin (Foundation of Women and Informatics, The Netherlands): Information Technology and Equity in Education, * Geoff Cumming (La Trobe University, Australia): Using Information Technology to Enhance the Effectiveness of Liberal Education * Stephen Franklin (Univ. of California, Irvine, Ca., USA): The Academic Computing Center as a Strategic University Resource * Robert Lewis (Lancaster Univ., UK): Research into Practice Panels: * Informatics Education in Developing Countries Evgueni Khvilon (UNESCO, Paris, France), Victorio Bajar (Inst. Tecnol. Aut'onomo, Mexico, Mexico), A. Balasubrahmanian (Indira Gandhi National Open Univ., Delhi, India), Geoff Fairall (Computer Society of Zimbabwe, Harare, Zimbabwe), Carlos Pereira de Lucena (Brazil) * Computers in Education: Research and Development in Latin-America Gustavo Rossi (Univ. de La Plata, Bueno Aires, Argentina), Hilmer Castillo (Univ. Sim'on Bolivar, Caracas, Venezuela), Marco Murray-Lasso (Academia de Investigaci'on Cient'ifica, Mexico, Mexico), Manuel Prieto (Univ. de la Habana, La Habana, Cuba), Lucilla Santarosa (Univ. Federale do Rio Grande do Sul, Porto Alegre, Brazil) * Teleteaching G. Davies (Open Univ., Milton Keynes, UK), L. Rosell'o (CEC, Brussels, Belgium), G. Paquette (Tele Univ. de Montreal, Montreal, Canada) * Informatics and Development J. Pino (Univ. of Chile, Santiago, Chile), S. Bathanagar (Univ. Ahmedabad, India), M. Korpela (Univ. Kuopio, Finland), M. Odedra (PC World, London, UK), S. Lanfranco (Univ. York, Canada), A.J. Rodr'iguez (Univ. Nairobi, Kenya) _______________________________________________________________________________ Programme Committee: Chair: P.Bollerslev Ministry of Education, Copenhagen, Denmark R. Aiken Temple University, Philadelphia, USA A. Balasubrahmanian Indira Gandhi National Open University, Delhi, India I. Stanchev Research Center for Education in Informatics, Sofia, Bulgaria A. Vaquero Complutense University, Madrid, Spain _______________________________________________________________________________ The posters for this stream should be submitted to: Director Peter Bollerslev Center for Applied Informatics in Teacher Education Ministry of Education Frederiksholms Kanal 26 DK-1220 Copenhagen K Denmark Fax: (+45-33) 925302 _______________________________________________________________________________ _______________________________________________________________________________ Stream: The Vulnerability of the Information Society: Social, Legal, and Security Aspects With worldwide use of Information Technology (IT) new opportunities arise but, likewise, new risks emerge through growing dependence on the same technology. New concerns have arisen and older ones have been enhanced. Such concerns include both human and civil rights, privacy, and freedom of the individual, quality and reliability of the technology,etc. This stream will attempt to assess the degree of vulnerability to IT that has developed particularly since the first OECD discussions in 1982 (OECD Conference, Siguenza/Spain, 1982). Specific areas of interest which may be addressed in submitted papers include: _______________________________________________________________________________ * Opportunities and risks in the adoption of Information Technology. * Legal aspects * Reliability and security in personal computers and local area networks * Impact of the vulnerability of information technology in the workplace and on the general public * Identification and authentication of users and systems * The Electronic Cottage: Delivering information and communication technologies to the home. * Computer ethics and professional responsibility * Development of Information Technology at the International Level, esp. in Latin America _______________________________________________________________________________ Invited Speakers: * G.B.F. Niblett (Abingdon, UK): Legal Aspects of the Information Society * Herbert Kubicek (Univ. of Bremen, Germany): Network(er)s at Risk. The Fairy Tale of Invulnerability of Computer-Supported Work * Lance Hoffman (The George Washington Univ., Washington, USA): Reducing Society's Vulnerability as Computers and Networks Proliferate * Harold W. Highland (USA): Perspectives in IT Security and Safety Panels: * Informatics and Development Subash Bathanagar (Ahmedabad, India), M. Korpela (Finland), Jose A. Pino (Univ. of Chile, Santiago, Chile), Mayuri Odedra (Kenya), S. Lanfranco (Canada), A.J. Rodriguez (Univ. Nairobi, Kenya) * Towards an IFIP Frame Code of Ethics Bl. Sendov (Bulgarian Academy of Sciences, Sofia, Bulgaria), J. Cameron (Sidney, Australia), K. Duncan (Health Information Systems, Los Altos, USA), J. Holvast (Stichting Waakzaamheit Persooonregistratie, Amsterdam, The Netherlands), D.C. Martin (The George Washington Univ., Washington DC, USA), A. Morris (Cape Town, South Africa), H. Sackman (California State Univ., Los Angeles, USA), R. Sizer (Farnborough, UK), G. Verroust (Paris, France), J.A.N. Lee (Virginia Tech., Blacksburg, USA) * Less Vulnerability in Electronic Cottages? F. van Rijn (Vrije Univ. Amsterdam, The Netherlands), T. Cronberg (Denmark), L. Haddon (UK), T. Natarajan (India), G. Noltes (The Netherlands), L. van Noorden (CEC, Brussels, Belgium), R. Silverstone (UK), R. Sloane (UK) * Vulnerability of IT and Gender Issues E. McCarthy (Univ. of Dublin, Ireland), A. Clement (Univ. of Toronto, Canada), B. Elkjaer (Univ. of Copenhagen, Denmark), S. Friis (Univ. of Lund, Sweden), K. Tijdens(Univ. of Amsterdam, The Netherlands), I. Josefson (Univ. of Stockholm, Sweden), I. Wagner (Technical Univ. Vienna, Austria) * Enhanced Security - Diminished Vulnerability? W. Caelli (Queensland Univ. of Technology, Brisbane, Australia), H.J. Highland (New York, USA), R. Moeller (Sears & Roebuck, Chicago, USA), K. Brunnstein (Univ. Hamburg, Hamburg, Germany) _______________________________________________________________________________ Programme Committee: Chair: K.Brunnstein University of Hamburg, Hamburg, Germany W. Caelli Queenland University of Technology, Brisbane, Australia R. Moeller Sears & Roebuck, Chicago, USA J. Pino University of Chile, Santiago de Chile, Chile F. Saez-Vacas Technical University, Madrid, Spain _______________________________________________________________________________ The posters for this stream should be submitted to: Professor Klaus Brunnstein Faculty for Informatics Universitat Hamburg Vogt-Koelln-Str.30 W-2000 Hamburg 54 Germany Fax: (+49-40)4123-6122 E-mail: brunnstein@rz.informatik.uni-hamburg.dbp.de _______________________________________________________________________________ _______________________________________________________________________________ Subconference: Expanding the Power of the Personal Computer Personal computers are now most widely used. Also, these small computing machines, when combined in local and wide area networks, will create systems whose size and complexity will rival those of today's most advanced systems. Many new algorithmic and man-machine interaction models are first conceptualized in programs for the personal computer. The thin boundary between theory and practice in this realm serves as a stimulus for advancingthe limits of what can be accomplished using computers. This technology has already begun to have a profound impact on non-computer professionals as well as the computer science/artificial intelligence community. Specific areas of interest include: _______________________________________________________________________________ * man-machine interfaces (pen-based input devices, ...) * end-user programming (visual programming, declarative programming, ...) * cooperative work groupinteraction (work-flow automation, ...) * LAN and WAN networking concepts for PCs * productivity environments for paperless office * multilingual multi-character set support * integration of multimedia * innovative database technologies for PCs * computer aided engineering _______________________________________________________________________________ Invited Speakers: * Esther Dyson (Edventure Holdings, New York, USA): New Technologies and Technology Transfer for the PC Industry * P. Singh (Microsoft, Redmond, USA): Pen-based Computing * Dave Liddle (Patriot Partners, Mountain View, Ca., USA): Object Oriented Operating Systems Concepts * Stan Rosenschein (Teleos Research, Palo Alto, Ca., USA): Distributed Intelligent Agents * Rob Shostak (Borland International, Scotts Valley, Ca., USA): New Trends in Database Technology * P. Maier (Sony Europa, Cologne, Germany): Global System Integration with Multimedia * Rolf Wildhack (Stollmann GmbH, Hamburg, Germany): ISDN for Multimedia Workstations Panel: * "The future of the Personal Computer" with the invited speakers _______________________________________________________________________________ Programme Committee: Chair: F. H. Vogt University of Hamburg, Hamburg, Germany I. Agamirzian Leningrad Institute for Informatics, Leningrad, USSR C. P. Lucena Catholic University, Rio de Janeiro, Brazil R. Puigjaner University of the Balearic Islands, Palma de Mallorca, Spain B. Robinet IBM France, Paris, France R. Schwartz Borland European TechnologyCenter, Paris, France _______________________________________________________________________________ The posters for this subconference should be submitted to: Professor Friedrich Vogt Universitaet Hamburg Bodenstedtstr. 16 W-2000 Hamburg 50 Germany Fax: (+49-40)4123-6530 E-mail: vogt@rz.informatik.uni-hamburg.dbp.de _______________________________________________________________________________ _______________________________________________________________________________ Subconference: Enhancing the Intelligence in Information Systems In a complex world,human knowledge and skill in making decisions and performing difficult tasks are scarce resources. Key organization objectives are to preserve existing knowledge and to encourage human learning andskill development. The problem is made more difficult because decisions in some systems must be made more quickly than is possible for humans. The solution is to incorporate human learning and human knowledge and skill into operational and decision making applications of information technology. Such knowledge-based and learning systems can be called intelligent information systems because they develop human intelligence and provide system responses similar toan intelligent, knowledgeable human. There are many examples of successful intelligent systems, but significant questions persist.The subconference will cover both knowledge-based systems and systems that promote development of intelligence or learning in organizations. _______________________________________________________________________________ * Design criteria for incorporating intelligence and learning in systems * Acquisition of knowledge and its validation, verification, and testing * The application of knowledge-based systems to the analysis, design, and maintenance of information systems * Experiences in implementation - problems and their solutions * Experiences demonstrating the effects of culture and stage of development in intelligent systems * Frontiers in research on enhancing intelligence in information systems _______________________________________________________________________________ The subconference will focus on four major issues: * The role of intelligent systems and learning systems in transforming societies and organizations in the next decade. The emphasis is on real plans rather than futuristic speculation. * Alternative ways for acquiring or developing knowledge to incorporate in knowledge-based systems and the validation, verification, and testing of the systems. * Current and planned applications of the powerful technology of knowledge-based systems and learning systems to the analysis, design, development, and maintenance of information systems. * Learning from experiences with intelligence in information systems. _______________________________________________________________________________ The subconference will feature both invited sp eakers and contributed papers. The subconference is positioned to provide thoughtful insight for managers and other non-technical persons as well as innovative ideas for system analysts and designers. _______________________________________________________________________________ Invited Speakers: * M.S. Scott Morton (MIT, Cambridge, MA, USA): What Must the Learning Organization Learn: Some Perspectives from MIT's Management in the 90's Program * J. Mylopoulos (Univ. of Toronto, Toronto, Canada): Knowledge-Based Systems for Information Systems Professionals * E. Hollnagel (Computer Resources International, Birkerod, Denmark): The Formalization of Knowledge-Based Systems Validation and Verification: Promises and Pitfalls * R.E. Markland (Univ. of South Carolina, USA): Knowledge-Based Systems in Manipulating Operations Panel: * Terminology for Validation J.P Laurent (Univ. de Savoie, France), A.D. Preece (Concordia Univ., Montreal, Canada), E. Hollnagel (Resources International, Denmark), P. Meseguer (CEAB, Blanes, Spain) _______________________________________________________________________________ Programme Committee: Chair: G.Davis University of Minnesota, Minneapolis, USA R. Benjamin Rochester, New York, USA J.P. Laurent Universite de Savoie, Chamb ery, France M. Lundeberg Stockholm School of Economics, Stockholm, Sweden J. Motiwalla National University, Singapore, Singapore A. Olive Technical University of Catalunya, Barcelona, Spain _______________________________________________________________________________ The posters for this subconference should be submitted to: Professor Gordon Davis University of Minnesota Dept. of Information and Decision Sciences 271 19th Ave South Minneapolis, Minnesota 55455 USA Fax: (+1-612)626-1316 E-mail: gdavis@umnsom.bitnet _______________________________________________________________________________ _______________________________________________________________________________ Symposium: Informatics for Environmental Protection Environmental protection is notonly a high ranking social and political goal but also a great scientific and technological challenge. Effective environmental protection and research are largely dependent on accurate information on environmental state and dynamics. Computers have been an integral part of contemporary environmental protection information management and environmental research for some time. However, computer work in the environmental field has been mostly pragmatic without a sound scientific basis. Applied informatics can play a major role in developing a conceptual basefor environmental information processing on solid scientific grounds. The purpose of this symposium is to present and discuss state-of-the-art applications of informatics in the environmental field. It mainly deals with environmental data bases and information systems, with visualization techniquesfor environmental data, with monitoring and image processing techniques, with geographical information systems, with environmental modelling software and with knowledgebased systems for environmental protection. _______________________________________________________________________________ Invited Speakers: * R. Becker, M. Strobel (IBM Scientific Center, Heidelberg, Germany), D. Kupper (Research Institute for Applied Knowledge Processing at the University of Ulm, Ulm, Germany): A Cooperative, Natural Language Environmental Information System * C.M. Beise (School of Business, West Georgia College, Carrollton, Georgia, USA): Application of Fourth Generation Prototyping Tools for a Municipal Industrial Water Quality Monitoring System * I. Crain (Dep. of Surveying Engineering, Univ. of Calgary, Calgary, Canada): Technology for global and regional environmental Decision-Making * K. Fedra (Advanced Computer Applications, International Institute for Applied Systems Analysis, Laxenburg,Austria): Interactive Environmental Software: Integration of GIS and Expert Systems * M. Haggith, L. Stewart-Zerba, P. Douglas (Griffith University, Nathan, Australia): Brisbane's Intelligent Relational Database on Zosterops: Making Ecological Data Digestible * J. Furst (Univ. for Soil Culture, Vienna, Austria): Integration of GIS into Decision Support Systems forSubsoil Water Management * A. Jaeschke (Dep. of Environmental Informatics, Nuclear Research Center, Karlsruhe, Germany): Expert System Technology for Environmental Protection with Special Emphasis on the XUMA System for Contaminated Site Evaluation * B. Page (Dep. of Informatics, University of Hamburg, Hamburg, Germany): Environmental Protection as a Challenge to Applied Informatics * W. Pillmann (Federal Health Institute, Vienna, Austria): Image Processing for Environmental Protection _______________________________________________________________________________ Symposium chairman: B. Page (Dep. of Informatics,University of Hamburg, Hamburg, Germany) _______________________________________________________________________________ _______________________________________________________________________________ Symposium: Cooperative Research Programmes This symposium will compare and contrast the various ways of conducting cooperative research programmes, it will look at the outstanding achievements of each programme, and will discuss the opportunities for international and especially intercontinental cooperation in cooperative research in Information Technologies. _______________________________________________________________________________ Invited Speakers: * Dan Andree (IT Delegationen, IT4 Programme, Sweden) * Jean-Marie Cadiou (Commission of the European Communities, DGXIII, ESPRIT, Brussels,Belgium) * J O'Callaghan (CSIRO, Division of Information Technology, Australia) * Vincent Thomson (NRC-CNRC, Systems Technology,Canada) * etc. Panel: * "Strengths and Weaknesses of teh Cooperative Approach to R&D" with the Invited Speakers _______________________________________________________________________________ Symposium chairman: B. Oakley (Logica Cambridge Ltd., London, UK) _______________________________________________________________________________ _______________________________________________________________________________ Symposium: Encouraging Academic/Practitioner Collaboration It is often argued that IFIP should take a more pro-active role in fostering academic-industry research collaboration. Increased collaboration potentially accelerates technology transfer from research to practice. Panelists will discuss how to bring about this collaboration. The panelists will share their considerable and diverse experience of successful academic-industry research collaboration schemes in various parts of the world. _______________________________________________________________________________ Introductory Speaker: B. Glasson (Curtin Univ., Perth, Australia): Academic-Industry Research Collaboration: Towards a Pro-active Role for IFIP Panel: * Academic-Industry Research Collaboration: Some Success Stories B. Glasson (Curtin Univ., Perth, Australia), M. Alexander (Expertise Australia Pty Ltd, Sydney, Australia), R. MacKinnon (IBM Scientific Centre, Cambridge, USA), B. Oakley (Logica Cambridge Ltd, London, UK), A.-W. Scheer (Univ. des Saarlandes, Saarbr\"ucken, Germany) _______________________________________________________________________________ Symposium organizer: B. Glasson (Australia) _______________________________________________________________________________ _______________________________________________________________________________ Symposium: Continuous Algorithms and Complexity _______________________________________________________________________________ Many problems in natural science, engineering, social science and business have continuous models. IFIP working group WG 14.1 is devoted to the algorithms and computational complexity for solving continuous models. In this meeting of WG 14.1 a series of 15 lectures is presented that address many different aspects of the intrinsic difficulty of solving such problems. Powerful new algorithms are of particular importance. Examples of the problems that are being studied include: ordinary and partial differential equations, continuous optimization, multivariate integration and approximation, and systems of polynomial equations. _______________________________________________________________________________ Invited Speakers: * H. Wozniakowski (Columbia Univ, New York, USA and Univ. of Warsaw, Warsaw, Poland): Tractability of Multivariate Problems M. Shub: (IBM T.J. Watson Research Center, Yorktown Heights, NY, USA): Complexity of Homotopy Methods for Systems of Equations * R. Tempo: (Politecnico di Torino, Torino, Italy): Singular Values and Interpolatory Algorithms for Robust Parametric Estimation * P. Mathe (Institut f\"ur Angewandte Analyse und Stochastik, Berlin, Germany): Random Approximation of Finite Sums. * Bl. Sendov (Bulgarian Academy of Sciences, Sofia, Bulgaria): Mathematics in Informatics through Complexity * J.F. Traub (Columbia Univ., New York, NY, USA): New Research Directions of Information-based Complexity * R.A. DeVore (Univ. of South Carolina, Columbia, SC, USA): Algorithms for Wavelet Compression * E. Novak (Univ. Erlangen-Nuernberg, Erlangen, Germany): The Complexity of Zero Finding for Univariate Functions * A. Iserles (Univ. of Cambridge, Cambridge, UK): On Global Bounds of Numerical Error for ODEs * S. Heinrich (Univ. of Kaiserslautern, Kaiserslautern, Germany): Complexity of Integral Equations and Relations to n-Widths * B.Z. Kacewicz (Univ. of Warsaw, Warsaw, Poland): Approximation of Linear Problems from Inaccurate Information * G.W. Wasilkowski (Univ. of Kentucky, Lexington, Kentucky, USA): On Probabilistic Complexity with Piece-wise Smooth Inputs} * A.G. Werschulz (Fordham Univ. College and Columbia Univ., New York, NY, USA): Complexity of Elliptic Problems: New Results * F. Cucker (Techn. Univ. of Catalonia, Barcelona, Spain): Complexity Classes in the Theory of the Reals * V. Temlyakov (Steklov Mathematical Institute, Moscow, Russia): On Optimal Approximate Recovery of Functions} _______________________________________________________________________________ Symposium organizers: Chair: J.F. Traub (Columbia Univ., New York, NY, USA) S. Heinrich (Univ. of Kaiserslautern, Kaiserslautern, Germany) C. Nett (Georgia Institute of Technology, Atlanta, Georgia, USA) M. Shub (IBM T.J. Watson Research Center, Yorktown Heights, NY, USA) V. Temlyakov (Steklov Mathematical Institute, Moscow, Russia) G.W. Wasilkowski (Univ. of Kentucky, Lexington, Kentucky, USA) H. Wozniakowski (Columbia Univ., New York, NY, USA and Univ. of Warsaw, Warsaw, Poland) _______________________________________________________________________________ _______________________________________________________________________________ Conference Venue With four million inhabitants, Madrid is the political, economic, and geographical center of Spain. Its privileged communication links make it a bridge between Europe, America, and Africa, as well asthe appropriate base to explore the country itself in all its variety. At 655 m. above sea level,its climate is dry and mild (average 7-20 C)with only 17 rainy days in autumn. Centuries of history have filled Madrid with innumerable places of cultural interest,ranging from one of the best painting museums in the world (El Prado) to dozens of monuments and hundreds of charming corners in the old town. In few other cities will you find such a lively and friendly atmosphere. Recreational choices include opera and flamenco dancing, theater and bull fights, nouvelle cuisine restaurants, and literally thousands of small taverns (tascas), or just strolling around the streets where midnight is still an early hour. 1992 marks a very special year in Spain. Along with the 5th centennial celebrations of the encounter of civilizations in America, Seville will be the site of the World Fair EXPO'92, Barcelona will be the city of the Olympic Games, and Madrid itself will host a myriad of events as the Cultural Capital of Europe. Spain is living proof of the chance that we still have to combine high technology with a leisure-oriented way of living: a perfect environment for a World Computer Congress. IFIP Congress 92 will be held at the School of Medicine at the Complutense University of Madrid. This location combines fully equipped conference facilities for the various parallel sessions, with informal campus atmosphere and easy means of transportation, either by bus, underground, or simply walking to one of Madrid's most lively downtown districts. The 12th World Computer Congress is hosted in Madrid by FESI (Federacion Espa~nola de Sociedades de Informatica), the Spanish member organization of IFIP. FESI is a federation of professional associations, foundations concerned with information technology, computer science schools, and national research institutions. For additional information correspond with: Grupo GEYSECO IFIP Congress 92 Capitan Haya, 60 - 2 E--28020 Madrid/Spain Fax: (+34-1) 5713804 Telex: 44676 E-mail: ifip92@dit.upm.es ------- End of Forwarded Message % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by enet-gw.pa.dec.com; id AA20306; Thu, 9 Apr 92 12:41:14 -0700 % Received: by inet-gw-1.pa.dec.com; id AA11812; Thu, 9 Apr 92 12:40:55 -0700 % Received: by ted.cs.uidaho.edu (16.6/1.34)id AA26145; Thu, 9 Apr 92 11:10:06 -0700 % Sender: info-hol-request@ted.cs.uidaho.edu % Errors-To: info-hol-request@ted.cs.uidaho.edu % Received: from panther.cs.uidaho.edu by ted.cs.uidaho.edu (16.6/1.34)id AA26141; Thu, 9 Apr 92 11:09:39 -0700 % Received: from localhost by panther.cs.uidaho.edu with SMTP id AA27479 (5.65c/IDA-1.4.4 for info-hol@cs.uidaho.edu); Thu, 9 Apr 1992 11:13:35 -0700 % Message-Id: <199204091813.AA27479@panther.cs.uidaho.edu> % To: info-hol@ted.cs.uidaho.edu % Subject: [cdk@dit.upm.es (Carlos Delgado Kloos): IFIP 92] % Date: Thu, 09 Apr 92 11:13:34 -0700 % From: "Phil Windley" % X-Mts: smtp Received: by CLI.COM (4.1/1); Thu, 9 Apr 92 17:23:01 CDT Received: by enet-gw.pa.dec.com; id AA04397; Thu, 9 Apr 92 15:25:41 -0700 Message-Id: <9204092225.AA04397@enet-gw.pa.dec.com> Received: from hpsrad.enet; by decwrl.enet; Thu, 9 Apr 92 15:25:42 PDT Date: Thu, 9 Apr 92 15:25:42 PDT From: "HEMENDRA TALESARA, DEC FT SYSTEMS, (508) 467-5541 09-Apr-1992 1829" To: nqthm-users@Pa.dec.com Apparently-To: nqthm-users@cli.com Subject: FWD: Summer position in Formal Verification ------------------Forwarded item dated 9-APR-1992 18:27:34.24------------------ From: DECWRL::"Paul.Loewenstein@Eng.Sun.COM" "Paul Loewenstein" To: info-hol@ted.cs.uidaho.edu CC: Subj: Summer position in Formal Verification SUMMER POSITION IN FORMAL VERIFICATION We are looking for a Summer Intern, a three month position in Mt. View, CA, to work on the formal verification of digital hardware designs. The details of the project will depend on the skills of the successful candidate. We are especially interested in combining the abstraction power of theorem proving with the automation of what are usually lower-level verification tools. We anticipate that a successful candidate would be a graduate student pursuing research in formal verification. Candidates are required to provide proof of their right to work in the USA. Sun provides a very competitive compensation package and the opportunity to work in a leading edge environment for the leading supplier of client/server computers. Sun Microsystems Computer Corporation, a subsidiary of Sun Microsystems, Inc., is the world's leading supplier of client-server computing solutions, which feature networked workstations and servers that store, process and distribute information. Used for many demanding commercial and technical applications, SMCC's products command the largest share of the computer industry's fastest-growing market segment: workstations and servers. Sun Microsystems, founded in 1982 and headquartered in Mountain View, Calif., is a multibillion dollar corporation doing business worldwide. Please send resumes to (e-mail preferred, FAX OK but not private): Paul Loewenstein, Staff Engineer Sun Microsystems Mailstop 19-04 2550 Garcia Avenue Mountain View CA 94043 USA. Tel: 415 336 2447 FAX: 415 962 0392 paul.loewenstein@Eng.Sun.COM % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by enet-gw.pa.dec.com; id AA04239; Thu, 9 Apr 92 15:23:11 -0700 % Received: by inet-gw-1.pa.dec.com; id AA20392; Thu, 9 Apr 92 15:23:06 -0700 % Received: by ted.cs.uidaho.edu (16.6/1.34)id AA27740; Thu, 9 Apr 92 14:53:48 -0700 % Sender: info-hol-request@ted.cs.uidaho.edu % Errors-To: info-hol-request@ted.cs.uidaho.edu % Received: from Sun.COM by ted.cs.uidaho.edu (16.6/1.34)id AA27736; Thu, 9 Apr 92 14:53:40 -0700 % Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)id AA08554; Thu, 9 Apr 92 14:52:50 PDT % Received: from lara.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)id AA25006; Thu, 9 Apr 92 14:52:54 PDT % Received: by lara.Eng.Sun.COM (4.1/SMI-4.1)id AA02586; Thu, 9 Apr 92 14:53:02 PDT % Date: Thu, 9 Apr 92 14:53:02 PDT % From: Paul.Loewenstein@Eng.Sun.COM (Paul Loewenstein) % Message-Id: <9204092153.AA02586@lara.Eng.Sun.COM> % To: info-hol@ted.cs.uidaho.edu % Subject: Summer position in Formal Verification Received: by CLI.COM (4.1/1); Fri, 10 Apr 92 17:24:12 CDT Date: Fri, 10 Apr 92 17:26:17 CDT From: Matt Kaufmann Message-Id: <9204102226.AA07475@thunder.CLI.COM> Received: by thunder.CLI.COM (4.1/CLI-1.2) id AA07475; Fri, 10 Apr 92 17:26:17 CDT To: info-hol@ted.cs.uidaho.edu, nqthm-users@cli.com Cc: archer@cs.ucdavis.edu, gfink@cs.ucdavis.edu, kaufmann@cli.com Subject: connecting HOL with the Boyer-Moore Theorem Prover Is there much serious interest out there in connecting the Boyer-Moore Theorem Prover with HOL? What I have in mind (and what I believe is similar to what Myla Archer and some others at UC Davis have been looking into) is some kind of connection that allows you to ship off certain HOL goals to the Boyer-Moore Theorem Prover, which is a ``first-order'' prover that has induction and natural number linear arithmetic. (An extension has some weak support for first-order quantification and an interactive goal-directed assistant much like HOL's.) Without saying more right now (such as who might get involved in the implementation, just how the mechanism might work, or how to address soundness), I'd like to pose the following request/challenge: Provide explicit examples of HOL theorems (possibly in the context of a theory) for which the Boyer-Moore theorem prover might provide useful assistance. I'd be very interested in seeing such examples. You could send them by email to me, Matt Kaufmann, at kaufmann@cli.com . Thanks. Received: by CLI.COM (4.1/1); Mon, 13 Apr 92 08:49:27 CDT Received: by enet-gw.pa.dec.com; id AA28771; Mon, 13 Apr 92 06:52:20 -0700 Message-Id: <9204131352.AA28771@enet-gw.pa.dec.com> Received: from hpsrad.enet; by decwrl.enet; Mon, 13 Apr 92 06:52:20 PDT Date: Mon, 13 Apr 92 06:52:20 PDT From: "HEMENDRA TALESARA, VSS FT SYSTEMS, 297-5541 13-Apr-1992 0925" To: nqthm-users@Pa.dec.com Apparently-To: nqthm-users@cli.com Subject: FWD: CADE-11 -----------------Forwarded item dated 12-APR-1992 14:24:12.60----------------- From: DECWRL::"nvm@cs.albany.edu" "Neil Murray" To: info-hol@cs.ucdavis.edu CC: Subj: CADE-11 PLEASE NOTE THE FOLLOWING CORRECTIONS TO THE PREVIOUS CADE-11 NOTICE: * If you choose to pay the conference registration fee by credit card, you will be billed for an additional amount of $8 for regular registrations and $3 for students to cover the credit charges. (Late registrations, banquet or excursion guest tickets, and tutorial registrations will NOT increase these credit fees.) * Tutorials 4 and 5 are reversed: T4 will be Constraints on Trees and will be held at 1:00pm. T5 will be Term Rewriting Techniques and will be held at 4:00pm. * The title of Larry Wos' Keynote address is ``The Impossibility of the Automation of Logical Reasoning.'' *** ALSO Below are facsimiles of the conference registration form and the motel reservation forms. You may use these to create and mail hardcopy, but we are NOT set up to receive registrations via email. (Registration/information packets went out via regular mail on Friday, 4/10.) ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| CADE 11 REGISTRATION FORM Name __________________________________________________________________ Last First MI Address _______________________________________________________________ Institution or Company Office Street _______________________________________________________________ City State/Province Postal Code Country _______________________________________________________________ Expected Arrival (time/date) Expected Departure (time/date) Early (by 5/15) $250. ___ Registration Late (after 5/15) $275. ___ $_____________ Fees Student $100. ___ Banquet Guest Tickets ___@ $25. each $_____________ Excursion Dinner Cruise $25. ___ $_____________ Excursion Guest Tickets ___@ $50. each $_____________ Check here if you require vegetarian ___ or kosher ___ meals. Tutorials T1 ___ T3 ___ One of One of T5 ___ ___@ $40. each $_____________ T2 ___ T4 ___ TOTAL $_____________ ___ I have enclosed a check or bank draft in US dollars. ___ I am paying by credit card. ___ VISA ___ MasterCard or EuroCard (An additional $8. will be charged for credit card payments - $3 for student registrations.) Card # _____________________________ Expiration Date _____________ Signature ________________________________ ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| RAMADA RENAISSANCE HOTEL 534 Broadway at City Center Saratoga Springs, NY 12866 (518) 584-4000 C A D E - 11 C O N F E R E N C E Sunday, June 14 - Thursday, June 18, 1982 ROOM RATES: $75.00 - Single occupancy, per night $85.00 - Double occupancy, per night RATES ARE SUBJECT TO 11% TAX, UNLESS TAX-EXEMPT FORM IS PROVIDED RATES INCLUDE ROOM ONLY RESERVATIONS MUST BE MADE ON OR BEFORE FRIDAY, MAY 22, 1992 RESERVATIONS REQUIRE ONE NIGHT'S DEPOSIT IN U.S. DOLLARS OR A MAJOR CREDIT CARD NUMBER RESERVATION INFORMATION 1. Reservations close 21 days prior to your function. If space is available after the closing date, reservations will be gladly accepted. 2. All reservations require a one night's deposit per room, refundable with 72 hours notice of changes or cancellations. Deposits may be made through a personal check in U.S. Dollars or by supplying a major credit card number (from one of those listed in item 6 below). 3. Groups on the Modified and American Plans will have gratuities added to their rates, covering Bellman, Maid, and Banquet/Dining Personnel. 4. Check-in time is 3:00 PM. If you arrive earlier and your room is ready, you will be roomed. 5. Check-out time is 12:00 Noon. 6. Credit information: We honor MasterCard, VISA, American Express, Diners Club, and Discover cards. We do accept personal checks in U.S. Dollars for depo- sits. 7. Employees of N.Y. State or of the U.S. Government may send Tax Exemption Certificates with authorized signa- tures to the Ramada Renaissance Hotel with the reserva- tion. Cut on dotted line and mail with deposit ---------------------------------------------------------------- ROOM RESERVATION REQUEST FORM Mail this form directly to the Ramada Renaissance Hotel ARRIVAL DEPARTURE DATE DATE #ROOMS TYPE & DESCRIPTION _______ _________ ______ Single, One person in room, $75 _______ _________ ______ 2 Double Beds, Two persons in room, $85 _______ _________ ______ King Bed, Two persons, $85 (if available) _______ _________ ______ Triple, Three persons in room _______ _________ ______ L-Shaped Suite Name _________________________________________________________________ Address ______________________________________________________________ City _______________ St./Prov. _________ Code ______ Country _________ Telephone # ____________________ Signature ___________________________ Credit Card (circle): MC VISA AE DC Dis Exp. Date _______ # ___________________________ Check here if you wish to receive confirmation of your reservation: ___ I have supplied a major credit card number or enclosed a check or Money Order for one night's deposit for each room. I understand that this deposit is refundable with receipt of changes or cancellations within 72 hours of of my scheduled arrival date. Mail this request early as reservations close 21 days prior to your arrival. ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| Holiday Inn Broadway at Circular Street RESERVATION INFORMATION & FORM 1. Reservations close May 29, 1992. If space is available after the closing date, reservations will be gladly accepted. 2. All reservations require a one night's deposit per room, refundable with two week's notice of changes or cancellations. Deposits may be made through a personal check in U.S. Dollars or by supplying a major credit card number. Reservations can also be made by calling 1-800-HOLIDAY and giving the 3-letter code "CAD" 3. Room rates increase $10 for each extra person. Children under 19 stay free with parents. 4. Credit information: We honor MasterCard, VISA, American Express, Diners Club, and Carte Blanche. Cut on dotted line and mail with deposit ------------------------------------------------------------------ ROOM RESERVATION REQUEST FORM Mail directly to the Holiday Inn Motel, Broadway at Circular St., Saratoga Springs, NY 12866. ARRIVAL DEPARTURE DATE DATE #ROOMS TYPE & DESCRIPTION _______ _________ ______ Single (1 person/room), $58 _______ _________ ______ Double (2 person/room), $68 Name ________________________________________________________________ Address _____________________________________________________________ City ________________ St./Prov. _____ Code ________ Country _________ Telephone # ____________ Signature __________________________________ Credit Card (circle): MC VISA AE DC CB Exp. Date _________ # _____________________________ I have supplied a major credit card number or enclosed a check or Money Order for one night's deposit for each room. I understand that this deposit is refundable with receipt of changes or cancellations within two weeks of my scheduled arrival date. Mail this request early as reservations close May 29, 1992. ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| Rip Van Dam Hotel-Motel 353 Broadway RESERVATION INFORMATION & FORM 1. Reservations close May 15, 1992. If space is available after the closing date, reservations will be gladly accepted. 2. All reservations require a one night's deposit per room, refundable with one week's notice in writing of changes or cancellations. Deposits may be made through a personal check in U.S. Dollars or by supplying a major credit card number (from one of those listed in item 6 below). 3. Check-in time is 1:00 PM. If you arrive earlier and your room is ready, you will be roomed. 4. Room rates increase $5 for each person beyond two. Reservations for one night only will be honored with an increase of $5 in the rate. 5. Check-out time is 11:00 AM. 6. Credit information: We honor MasterCard, VISA, American Express, Diners Club, and Carte Blanche. We do accept personal checks in U.S. Dollars for deposits; final payments must be cash, travelers' checks, or credit card. Cut on dotted line and mail with deposit ------------------------------------------------------------------- ROOM RESERVATION REQUEST FORM Mail directly to the Rip Van Dam Hotel-Motel, P.O. Box 1021, Saratoga Springs, NY 12866. ARRIVAL DEPARTURE DATE DATE #ROOMS TYPE & DESCRIPTION _______ _________ ______ One Double Bed, One or two persons, $40 _______ _________ ______ Two Double Beds, One or two persons, $50 Name ________________________________________________________________ Address _____________________________________________________________ City ________________ St./Prov. _____ Code ________ Country _________ Telephone # ____________ Signature __________________________________ Credit Card (circle): MC VISA AE DC CB Exp. Date _________ # _____________________________ You will receive confirmation of your reservation. I have supplied a major credit card number or enclosed a check or Money Order for one night's deposit for each room. I understand that this deposit is refundable with receipt in writing of changes or cancellations within 7 days of my scheduled arrival date. Mail this request early as reservations close May 15, 1992. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by enet-gw.pa.dec.com; id AA24449; Sun, 12 Apr 92 11:20:15 -0700 % Received: by inet-gw-1.pa.dec.com; id AA09175; Sun, 12 Apr 92 11:20:13 -0700 % Received: from iris.cs.ucdavis.edu by toadflax.cs.ucdavis.edu (4.1/UCD.CS.1.1)id AA05506; Sun, 12 Apr 92 11:03:37 PDT % Received: by iris.cs.ucdavis.edu (5.57/UCD.CS.1.1)id AA13571; Sun, 12 Apr 92 11:03:30 -0700 % Received: from herbrand.albany.edu by cssun.albany.edu (5.65/SMI-3.2)id ; Sun, 12 Apr 92 14:02:44 -0400 % Received: by herbrand.albany.edu (5.65/ALBANY_CS-1.1)id AA14885; Sun, 12 Apr 92 14:02:37 -0400 % Date: Sun, 12 Apr 92 14:02:37 -0400 % From: nvm@cs.albany.edu (Neil Murray) % Message-Id: <9204121802.AA14885@herbrand.albany.edu> % To: info-hol@cs.ucdavis.edu % Subject: CADE-11 Received: by CLI.COM (4.1/1); Wed, 22 Apr 92 18:40:00 CDT Received: from uno.vis.citri.EDU.AU by mulga.cs.mu.OZ.AU with SMTP (5.64+1.3.1+0.50); id AA06033 Thu, 23 Apr 1992 09:43:20 +1000 (from molly@uno.vis.citri.EDU.AU) Received: by uno.vis.citri.EDU.AU (5.52) id AA09958; Thu, 23 Apr 92 09:43:19 EST Date: Thu, 23 Apr 92 09:43:19 EST From: molly@uno.vis.citri.EDU.AU (Mark Ollila) Message-Id: <9204222343.9958@uno.vis.citri.edu.au> To: nqthm-users@cli.com Subject: Can you subscribe me to the list. I am doing some work in geometry theorem proving and am looking for software that already exists in the area. Such software that implements Wu's method etc. I believe ShangChing Chou implemented a comprehensive program for automated geometry proving. I want to know where it is available, be it ftp or bbs. Thanks in advance. Mark. molly@vis.citri.edu.au Received: by CLI.COM (4.1/1); Tue, 12 May 92 12:59:43 CDT Received: by crl.dec.com; id AA24971; Tue, 12 May 92 14:00:39 -0400 Received: by easynet.crl.dec.com; id AA10553; Tue, 12 May 92 13:58:42 -0400 Message-Id: <9205121758.AA10553@easynet.crl.dec.com> Received: from tecrus.enet; by crl.enet; Tue, 12 May 92 13:58:46 EDT Date: Tue, 12 May 92 13:58:46 EDT From: 12-May-1992 1403 To: info-hol@ted.cs.uidaho.edu, wg102@m.pa.dec.com, nqthm-users@cli.com Apparently-To: nqthm-users@cli.com, wg102@m.pa.dec.com, info-hol@ted.cs.uidaho.edu Subject: Formal verification at Digital In the next two months, we would like to hire someone to join a new team, doing formal verification of computer designs. We'll be looking for someone with experience using a theorem prover for formal verification, probably with a Master's degree, preferably familiar with computer design or VLSI logic design, and (necessarily) able to work here. (An applicant must tell us he or she is a US citizen, permanent resident, temporary permanent resident, asylee, or refugee, or we won't be able to respond.) If you know people looking for that kind of work, we'd love to hear about them. I've sent this message to the info-hol, nqthm, and wg102 mailing lists. Please feel free to pass the word on to other possible sources, too. Thanks, Tim Leonard Semiconductor Engineering Group Digital Equipment Corporation Hudson, Massachusetts Internet: Leonard@ricks.enet.dec.com telephone: (508) 568-5809 FAX: (508) 568-4681 Received: by CLI.COM (4.1/1); Thu, 4 Jun 92 12:01:43 CDT Received: from margaux.inria.fr by concorde.inria.fr, Thu, 4 Jun 92 18:55:45 +0200 Received: by margaux.inria.fr, Thu, 4 Jun 92 18:54:58 +0200 Date: Thu, 4 Jun 92 18:54:58 +0200 From: Gerard Huet Message-Id: <9206041654.AA28487@margaux.inria.fr> To: distribution:@inria.fr; (see end of body) Subject: Coq Release Info First of all, all my apologies if you receive multiple versions of this message because you are in the intersection of several mailing lists. This is an announcement for the release of an improved version of Coq, our Proof Assistant for the Calculus of Inductive Constructions. Coq is freely available by ftp as follows: ftp nuri.inria.fr or ftp 128.93.1.26 with Name anonymous and Password your email address. Then do binary cd INRIA/coq get README get coq.tar.Z quit Now uncompress coq.tar.Z, untar coq, and follow the README instructions. Coq runs in CAML V3.1, also available on the same machine in directory INRIA/caml/V3.1. Versions are currently available for the following machines: Sun3, Sun4, Decstation, SONY68k, SONYR3000, Apollo, and Macintosh/AUX. Coq has also an experimental version on top of caml-light, a smaller and more portable implementation of ML. We shall appreciate all comments, suggestions, bug reports. Send such mail to: coq@margaux.inria.fr The Coq users community is growing, and many users have similar difficulties. We are now collecting addresses of actual users, in order to circulate information of general interest, and prepare distribution of users libraries. If you want to be put on this users e-mailing list, send me a reply to this effect, with a short description of your area of interest. Gerard Huet %%% overflow headers %%% To: Harald.Ganzinger@mpi-sb.mpg.de, Juergen.Stuber@mpi-sb.mpg.de, Michael.Rusinowitch@loria.fr, Yves.Bertot@sophia.inria.fr, alban@fwi.uva.nl, amadio@loria.crin.fr, araragi@cslab.kecl.ntt.jp, atoenne@cs.uni-sb.de, basin@mpi-sb.mpg.de, besancon@lix.polytechnique.fr, card@masi.ibp.fr, cardelli@src.dec.com, casteran@labri.greco-prog.fr, cubric@opus.cs.mcgill.ca, dam@ai.mit.edu, dduggan@waterloo.edu, debec@ensta.ensta.fr, dkm@dcs.glasgow.ac.uk, er@cl.cam.ac.uk, erik@win.tue.nl, etxdasy@brazil.ericsson.se, felty@research.att.com, fp@cs.cmu.edu, fujiken@dumbo.ai.kyutech.ac.jp, gramlich@uklirb.informatik.uni-kl.de, gstav@theseas.ntua.gr, hayashi@whale.ryukoku.ac.jp, hutter@cs.uni-sb.de, hzhang@herky.cs.uiowa.edu, james@cray.com.usa, janin@IRO.UMontreal.CA, jf@id.dth.dk, jfg@cwi.nl, jt@malabar.mitre.org, jve@lifia.imag.fr, karst@phil.ruu.nl, koletsos@theseas.ntua.gr, liang@saul.cis.upenn.edu, refelcs.inria.fr@inria.fr, madden@aisb.edinburgh.ac.uk, marchand@polytechnique.fr, martin@inferenzsysteme.informatik.th-darmstadt.de, matsuda@tansei.cc.u-tokyo.ac.jp, melennec@stna7.stna.dgac.fr, mf@lri.fr, michal@eik.ii.uib.no, michou@grtc.cnrs-mrs.fr, mizuhito@ntt-20.ntt.jp, monin@LANNION.CNET.fr, nachum@cs.uiuc.edu, nickau@hrz.uni-siegen.dbp.de, nqthm-users@cli.com, parigot@logique.jussieu.fr, pavlovic@triples.matn.mcgill.ca, proof-sci@cs.chalmers.se, rccarel@urc.tue.nl, rda730f@monu6.cc.monash.edu.au, rewriting-list@loria.crin.fr, ruess@informatik.uni-ulm.de, rwh@cs.cmu.edu, saintlou@otl.scu.edu, sin@kurims.kyoto-u.ac.jp, sterba@anl.anl.fr, theorem-provers@mc.lcs.mit.edu, thomas@lannion.cnet.fr, tsuiki@sfc.keio.ac.jp, types@theory.lcs.mit.edu, vandi@vortex.ufrgs.anrs.br, volle@nsl.fr, waldinger@ai.sri.com, walsh@aisb.edinburgh.ac.uk, wb1@cec1.wustl.edu, yozo@titisha.is.titech.ac.jp, zanon@menfin.cert.fr %%% end overflow headers %%% Received: by CLI.COM (4.1/1); Wed, 24 Jun 92 09:52:35 CDT Date: Wed, 24 Jun 92 09:52:35 CDT From: Robert S. Boyer Message-Id: <9206241452.AA08051@CLI.COM> To: nqthm-users@cli.com Subject: [Frank_Pfenning@ALONZO.TIP.CS.CMU.EDU: Information on Elf ] Reply-To: boyer@cli.com I was most intrigued by a report, at an induction workshop before the recent CADE, of the success of Frank Pfennig's group in getting students quickly to check proofs of interesting theorems, so I'm forwarding this omnibus set of pointers on to others. From: Frank Pfenning Subject: Information on Elf Date: Fri, 19 Jun 92 11:25:06 -0400 Dear Colleagues, during the CADE workshop on induction, some of you signed up to receive some information and papers about Elf. Unfortunately the sign-up sheet has been lost, so I am including the information below. If you prefer I can send hardcopies of any of the papers---please just let me know. Best Regards, - Frank ---------------------------------------------------------------------- Frank Pfenning Telephone: +1 412 268-6343 School of Computer Science FAX: +1 412 681-5739 Carnegie Mellon University InterNet: fp@cs.cmu.edu Pittsburgh, PA 15213-3890, U.S.A. ---------------------------------------------------------------------- This is the README file for Elf, a logic programming language based on the LF Logical Framework. This implementation is a prototype interpreter---little attention was paid to efficiency. A few helpful hints on how to use the system can be found in the file NOTES. Besides the implementation, .dvi files with the papers which have been written about Elf to-date are also available via anonymous ftp. Note, however, that these do not constitute "documentation". This release also comes with a number of different examples from logic and computer science. One paper, describing an implementation of Mini-ML, can be considered as a tutorial on Elf---a compressed .dvi file of this paper is available for anonymous ftp in elf-papers/natsem91.dvi.Z (see below for further instructions). The installation of Elf requires Standard ML of New Jersey. Versions 0.72 and greater are more likely to work than older versions. Currently, SMLofNJ can be retrieved via anonymous ftp from princeton.edu (net address 128.112.128.1), directory pub/ml. For up-to-date information on Standard ML of New Jersey, contact David MacQueen . It is available for a large number of machine architectures. There is a mailing list with announcements about Elf. Please send mail to elf-request@cs.cmu.edu to join the list. For further information contact Frank Pfenning School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213-3890 U.S.A. Email: fp@cs.cmu.edu Phone: +1 412 268-6343 ====================================================================== Retrieving Elf, Version 0.2, Sat Feb 15 12:47:08 1992 (alonzo.tip.cs.cmu.edu has internet address 128.2.209.194) % ftp alonzo.tip.cs.cmu.edu Name: anonymous Password: user@node ftp> cd /afs/cs/user/fp/public ftp> type binary ftp> get elf.tar.Z ftp> bye % uncompress elf.tar.Z % tar -xvf elf.tar % rm elf.tar This will create a directory elf/ with the sources for the implementation and examples in various subdirectories. See the file elf/elf/INSTALL for further installation instructions. To retrieve the tutorial connect as above and ftp> cd elf-papers ftp> get natsem91.dvi.Z ftp> bye % uncompress natsem91.dvi.Z will create the file natsem91.dvi which can be previewed or printed. Other papers archived in this directory are described below. ====================================================================== lics92.dvi --- a technical summary, to appear in LICS'92, describing an approach to compiler verification using LF [Hannan92]. cade92.dvi --- a paper to appear in CADE-11, describing our approach to the verification of meta-theorems in Elf by means of examples [Pfenning92]. lfproc92.dvi --- describes the design of a module system for Elf [Harper91b]. This design has not yet been implemented. natsem91.dvi --- technical report [Michaylov91] This describes a major example (an implementation of Mini-ML) in detail. It gives an example-oriented, pragmatic tutorial on Elf. lfproc91.dvi --- close to final draft of [Pfenning91a]. This is the canoncial reference for Elf programming language at the moment. lics91.dvi --- describes the unification algorithm used in Elf in the more general setting of the Calculus of Constructions [Pfenning91b]. jacm.dvi --- the revised and expanded version of the original LF paper from LICS'87 to appear in JACM [Harper91a]. This is the canonical reference on the LF Logical Framework. pta90.dvi --- a technical report describing systems of polymorphic type assignment in LF [Harper90]. lics89.dvi --- extended abstract from LICS'89 [Pfenning89]. First paper on Elf, somewhat obsolete. biblio.dvi --- bibliography with work on the LF Logic Framework and Elf. @inproceedings ( HANNAN92, key = "Hannan92" , author = "John Hannan and Frank Pfenning" , title = "Compiler Verification in {LF}" , booktitle= "Seventh Annual {IEEE} Symposium on Logic in Computer Science" , address = "Santa Cruz, California" , publisher= "IEEE Computer Society Press" , month = "June" , year = "1992" , note = "To appear. Preliminary version available as {POP} Report 91--003, School of Computer Science, Carnegie Mellon University" ) @article ( HARPER91A, key = "Harper91a" , author = "Robert Harper and Furio Honsell and Gordon Plotkin" , title = "A Framework for Defining Logics" , journal = "Journal of the ACM" , year = "To appear" , note = "A preliminary version appeared in {\em Symposium on Logic in Computer Science}, pages~194--204, June 1987" ) @unpublished (HARPER91B, key = "Harper91b" , author = "Robert Harper and Frank Pfenning" , title = "Modularity in the {LF} Logical Framework" , month = "November" , year = "1991" , note = "Submitted" , annote = "Talk given at the Second Workshop on Logical Frameworks, Edinburgh, Scotland, May 1991" ) @techreport ( HARPER90, key = "Harper90" , author = "Robert Harper" , title = "Systems of Polymorphic Type Assignment in LF" , institution= "Carnegie Mellon University" , address = "Pittsburgh, Pennsylvania" , number = "CMU-CS-90-144" , month = "June" , year = "1990" ) @inproceedings ( MICHAYLOV91, key = "Michaylov91" , author = "Spiro Michaylov and Frank Pfenning" , title = "Natural Semantics and Some of its Meta-Theory in {Elf}" , booktitle= "Extensions of Logic Programming" , editor = "Lars Halln\um{a}s" , publisher= "Springer-Verlag LNCS" , year = "1992" , note = "To appear. A preliminary version is available as Technical Report MPI--I--91--211, Max-Planck-Institute for Computer Science, Saarbr\um{u}cken, Germany, August 1991" ) @inproceedings ( PFENNING89, key = "Pfenning89" , author = "Frank Pfenning" , title = "{Elf}: A Language for Logic Definition and Verified Meta-Programming" , booktitle= "Fourth Annual Symposium on Logic in Computer Science" , publisher= "IEEE Computer Society Press" , month = "June" , year = "1989" , pages = "313--322" ) @inproceedings ( PFENNING91a, key = "Pfenning91a" , author = "Frank Pfenning" , title = "Logic Programming in the {LF} Logical Framework" , booktitle= "Logical Frameworks" , editor = "G\'{e}rard Huet and Gordon D. Plotkin" , publisher= "Cambridge University Press" , year = "1991" ) @inproceedings ( PFENNING91B, key = "Pfenning91b" , author = "Frank Pfenning" , title = "Unification and Anti-Unification in the {Calculus} of {Constructions}" , booktitle= "Sixth Annual {IEEE} Symposium on Logic in Computer Science" , publisher= "IEEE Computer Society Press" , month = "July" , year = "1991" , pages = "74--85" ) @unpublished ( PFENNING92, key = "Pfenning92" , author = "Frank Pfenning and Ekkehard Rohwedder" , title = "Implementing the Meta-Theory of Deductive Systems" , month = "June" , year = "1992" , note = "To appear. Preliminary version available as {POP} Report 91--002, School of Computer Science, Carnegie Mellon University" ) Received: by CLI.COM (4.1/1); Thu, 25 Jun 92 08:47:35 CDT Date: Thu, 25 Jun 92 08:47:35 CDT From: Robert S. Boyer Message-Id: <9206251347.AA14697@CLI.COM> To: nqthm-users@cli.com Subject: State of things Reply-To: boyer@cli.com Below is a technical report that Matt Kaufmann has recently produced. The report contains information about Nqthm and Pc-Nqthm use. A postscript version of this report may be obtained by anonymous ftp as the file /pub/nqthm/report-075-fm91-survey.ps from host cli.com. Response to FM91 Survey of Formal Methods: Nqthm and Pc-Nqthm Matt Kaufmann (with many contributors) Technical Report 75 March, 1992 Computational Logic Inc. 1717 W. 6th St. Suite 290 Austin, Texas 78703 This work was supported in part at Computational Logic, Inc., by the Defense Advanced Research Projects Agency, ARPA Order 7406. The views and conclusions contained in this document are those of the author(s) and should not be interpreted as representing the official policies, either expressed or implied, of Computational Logic, Inc., the Defense Advanced Research Projects Agency or the U.S. Government. Introduction This report contains contributions to the requested survey for FM91, ``A survey of formal methods tools and techniques'' and ``A survey of applications.'' Two tools are covered: (1) Nqthm, the Boyer-Moore Theorem Prover; and (2) Pc-Nqthm, an interactive enhancement of Nqthm. Some of the words are taken from corresponding responses for FM89, but changes have been made. The parts (other than this introduction) are as follows. In the text below, these are all separated by headers of the form =====
===== 1. Response for tool: Nqthm 2. Response for tool: Pc-Nqthm 3. Applications using Nqthm or Pc-Nqthm: Part I 4. Applications using Nqthm or Pc-Nqthm: Part II The report concludes with references. Perhaps some explanation of my treatment of Applications is in order. There have been many applications of Nqthm and of Pc-Nqthm, a number of them significant. Therefore, in order to convey this breadth in a reasonable amount of space, I've chosen in (3) to list essentially all of the applications that are on-line at Computational Logic, Inc. (the home of Nqthm and Pc-Nqthm), but with only a brief explanation of each. (4) is the treatment of a few of these and other applications using the requested format, so that depth can be obtained in addition to the breadth afforded by the more comprehensive listing in (3). Acknowledgements. Many people contributed to this effort. In particular, the final section consists entirely of contributions made by the creators of the particular applications, with only trivial editing by this author. J Moore supplied the annotated list of Nqthm applications in Section 3. Without Boyer and Moore's theorem prover, none of this would be possible. And without the supportive environment at Computational Logic, Inc., none of this would be as easy. ===== Section 1. Response for tool: Nqthm ===== Name: The Boyer-Moore Theorem Prover (Nqthm) Participants: Robert S. Boyer and J Strother Moore Contact name and address: J Strother Moore Computational Logic Inc. 1717 W. 6th St., Suite 290 Austin, TX 78703 phone: (512) 322-9951 email: moore@cli.com fax: (512) 322-0656 Level of effort: 21 years X 2 persons Description: This is an automatic/interactive theorem prover for a first order logic resembling Pure Lisp. The logic is based on recursive function definition and inductively defined data types. The theorem prover consists of about 1 megabyte of Common Lisp and contains many heuristics for controlling rule-based rewriting and induction. Accomplishments: Proofs of Goedel's Incompleteness theorem, Wilson's Theorem, Gauss' law of quadratic reciprocity, unsolvability of the halting problem, correctness of the Boyer-Moore fast string searching algorithm, invertibility of the RSA encryption algorithm, Piton assembler, Micro-Gypsy compiler, FM8502 microprocessor, FM9001 microprocessor, KIT operating system, Bitonic sort, several programs in Unity, asynchronous communications, biphase mark protocol, 8-bit parallel io Byzantine agreement processor, a formalization of the Motorola MC68020, a variety of MC68020 machine code programs, a mutual exclusion algorithm, and many other problems. Published articles and reports. A Computational Logic, Boyer & Moore, Academic Press, 1979. A Computational Logic Handbook, Boyer & Moore, Academic Press, 1988. -- and, various articles on particular applications Start date: 1971 Completion date: 1992 Future developments: A new theorem prover based on applicative Common Lisp with significantly greater control over hints, theories and libraries, an expanded set of built-in data types, random-access arrays, and many other improvements. A prototype currently exists. Strengths/weaknesses/suitability: Sound, extensible, interactive via incorporation of user-suggested but mechanically proved rules. Complicated; requires experience. Seems particularly suited for proofs about computer systems, but has been used successfully on a wide variety of applications. External users: Hundreds of copies have been distributed over the net. Mainly university research groups. Some industry interest. Much government interest. Applications: See ``Accomplishments'' above as well as the ``applications'' portion of the survey. Availability: To get a copy follow these instructions: 1. ftp to Internet host cli.com. (cli.com currently has Internet number 192.31.85.1) 2. log in as ftp, password guest 3. get the file /pub/nqthm/README 4. read the file README and follow the directions it gives. Inquiries concerning tapes may be sent to: Computational Logic, Inc., Suite 290, 1717 W. 6th St., Austin, Texas 78703. Additional remarks: See also the corresponding response for Pc-Nqthm. This development of Nqthm has been an ongoing effort for 21 years. It has received support from a wide variety of sponsors including Science Research Council of Great Britain (now Science and Engineering Research Council), Xerox, SRI International, National Science Foundation, Office of Naval Research, NASA, Air Force Office of Scientific Research, Digital Equipment Corporation, the University of Texas at Austin, the Venture Research Unit of British Petroleum, Ltd., IBM, Defense Advanced Projects Research Agency, National Computer Security Center, the Space and Naval Warfare Systems Command, and Computational Logic, Inc. Our primary support now comes from Defense Advanced Research Projects Agency, DARPA Order 7406. The views and conclusions contained in this document are those of the author(s) and should not be interpreted as representing the official policies, either expressed or implied, of Computational Logic, Inc., the Defense Advanced Research Projects Agency or the U.S. Government. ===== Section 2. Response for tool: Pc-Nqthm ===== Name: Pc-Nqthm (An interactive ``Proof-checker'' enhancement of the Boyer-Moore Theorem Prover Participants: Matt Kaufmann Contact name and address: Matt Kaufmann Computational Logic Inc. 1717 W. Sixth St., Suite 290 Austin, TX 78703 phone: (512) 322-9951 email: kaufmann@cli.com fax: (512) 322-0656 Level of effort: Perhaps (very roughly) 2 man-years, spread over 5 years. Description: This ``proof-checker'' is loaded on top of the Boyer-Moore Theorem Prover; see the corresponding response for Nqthm. The user can give commands at a low level (such as deleting a hypothesis, diving to a subterm of the current term, expanding a function call, or applying a rewrite rule) or at a high level (such as invoking the Boyer-Moore Theorem Prover). Commands also exist for displaying useful information (such as printing the current hypotheses and conclusion, displaying the currently applicable rewrite rules, or showing the current abbreviations) and for controlling the progress of the proof (such as undoing a specified number of commands, changing goals, or disabling certain rewrite rules). A notion of ``macro commands'' lets the user create compound commands, roughly in the spirit of the tactics and tacticals of LCF and its descendents. An on-line help facility is provided, and a user's manual exists. As with a variety of proof-checking systems, this system is goal-directed: a proof is completed when the main goal and all subgoals have been proved. Upon completion of an interactive proof, the lemma with its proof may be stored as a Boyer-Moore ``event'' that can be added to the user's current library of definitions and lemmas. This event can later be replayed in ``batch mode''. Partial proofs can also be stored. Accomplishments: This system has been used to check theorems stating the correctness of a transitive closure program, a Towers of Hanoi program, a ground resolution prover, a compiler, irrationality of the square root of 2, an algorithm of Gries for finding the largest "true square" submatrix of a boolean matrix, the exponent two version of Ramsey's Theorem, the Shroeder- Bernstein theorem, Koenig's tree lemma, and others. It has also been used to check the correctness of several Unity programs and has been used for hardware verification. Published articles and reports. The first one below is a detailed user's manual, including soundness arguments. The second extends this by describing an extension of the system which admits free variables, an important addition for doing full first-order reasoning. The third is a reference for that full first-order reasoning capability. Matt Kaufmann, A User's Manual for an Interactive Enhancement to the Boyer-Moore Theorem Prover. Technical Report 19, Computational Logic, Inc., May, 1988. Matt Kaufmann, Addition of Free Variables to an Interactive Enhancement of the Boyer-Moore Theorem Prover. Technical Report 42, Computational Logic, Inc., May, 1989. Matt Kaufmann, An Extension of the Boyer-Moore Theorem Prover to Support First-Order Quantification. To appear in J. of Automated Reasoning" A preliminary (and expanded) version appears as Technical Report 43, Computational Logic, Inc., May, 1989. -- and, various articles on particular applications. Start date: Late 1986 Completion date: 1992 Future developments: Boyer and Moore are creating a new theorem prover based on applicative Common Lisp; see the ``Future developments'' response for Nqthm. There currently exists a similar interactive enhancement for that system, and we intend to continue development of that capability. Strengths/weaknesses/suitability: Strengths include: - Combination of capability for high degree of user control with the power of the Boyer-Moore prover - On-line help facility and users manuals - Extensibility by way of ``macro commands'' (patterned after the tactics and tacticals of LCF, HOL, Nuprl etc.) - Full integration into Boyer-Moore system - Careful attention to soundness issues Weaknesses include: - Ease of low-level interaction often tempts users to construct ugly proofs without many reusable lemmas that are hard to modify. - First-order quantification is handled via Skolemiza- tion, rather than directly (as in the Never prover). External users: Dozens of copies have been distributed over the net. Mainly university research groups. Some industry interest. Much government interest. Applications: See ``Accomplishments'' above as well as the ``applications'' portion of the survey. Availability: To get a copy, first obtain the Boyer-Moore Theorem Prover (Nqthm), as described in the corresponding response for Nqthm. Then follow these instructions: 1. ftp to Internet host cli.com. (cli.com currently has Internet number 192.31.85.1) 2. log in as ftp, password guest 3. get the file /pub/proof-checker/README-pc 4. read the file README-pc and follow the directions it gives. Inquiries concerning tapes may be sent to: Computational Logic, Inc., Suite 290, 1717 W. 6th St., Austin, Texas 78703. Additional remarks: See also the corresponding response for Nqthm. This work was supported by the Defense Advanced Research Projects Agency (currently DARPA Order 7406), the Office of Naval Research, the National Computer Security Center, and IBM. The views and conclusions contained in this document are those of the author and should not be interpreted as representing the official policies, either expressed or implied, of Computational Logic, Inc., the Defense Advanced Research Projects Agency or the U.S. Government. ===== Section 3. Applications survey, Nqthm and Pc-Nqthm: Part I ===== Below is a list all of the prover input files that we have on-line at Computational Logic, Inc. Many of these example files are freely distributed by their authors. In Part II we present detailed summaries of a few of the larger applications, in the format requested. J Moore has supplied the information below in the case of Nqthm, and Matt Kaufmann has done so for Pc-Nqthm. In each case, we give a very rough indication of level of effort by stating the number of bytes for the input file. For each entry we give a partial file name, followed by the number of bytes for that file. That file length is followed in parentheses by the author(s) and possibly a citation, followed by a very brief description of the work. When no citation is given, no published description of the work is available and the interested reader should look at the events file itself. Many of the files have explanatory comments. The files are listed in alphabetical order for Nqthm, and again for Pc-Nqthm. NOTE!!! The sizes and complexity of these applications vary wildly. The brief descriptions and file lengths should give a little indication of the relative sizes of the efforts. References appear at the end of the paper. -------------------- Nqthm applications -------------------- I have been told that there are about 16,000 theorems (PROVE-LEMMA forms) in the Nqthm event files discussed below. basic/alternating (14237 bytes) (Boyer) a formalization and correctness proof of a card trick having to do with the outcome of shuffling a deck of cards that has been previously arranged into alternating colors basic/async18 (150871 bytes) (Moore, [1]) a model of asynchronous communica- tion and a proof of the reliability of the biphase mark communications protocol basic/binomial (4015 bytes) (Boyer and Moore, [2]) the binomial theorem expressed with FOR and a proof thereof basic/controller (9184 bytes) (Boyer, Moore, and Green, [3]) a model of the problem of controlling a vehicle's course and a proof that under certain conditions a particular program keeps the vehicle within a certain corridor of the desired course and, under more ideal conditions, homes to the course basic/fibsums (13243 bytes) (Cowles) proofs of several interesting theorems about the sums of Fibonacci numbers basic/fortran (10687 bytes) (Boyer and Moore, [4]) supporting definitions for a Fortran verification condition generator basic/fs-examples (9243 bytes) (Boyer, Goldschlag, Kaufmann, and Moore, [5]) illustrations of the use of constrained functions and functional instantiation basic/gauss (55601 bytes) (Russinoff, [6]) the original Nqthm proof of Gauss' law of quadratic reciprocity basic/new-gauss (37455 bytes) (Russinoff, [6]) an improved proof of Gauss' law of quadratic reciprocity (after all, Gauss proved it eight times!) basic/parser (Boyer and Moore, an appendix of [7]) a formalization of the syntax and abbreviation conventions of the Nqthm extended logic, expressed as a function from lists of ASCII character codes to the quotations of formal terms basic/peter (8376 bytes) (Boyer) a sequence of lemmas describing the relationship between Ackermann's original func- tion and R. Peter's version of it basic/pr (7863 bytes) (Boyer) a proof of the existence of nonprimitive recursive functions basic/proveall (86983 bytes) (Boyer and Moore, Appendix A of [8]) elementary list processing, number theory through Euclid's theorem and prime factorization, soundness and completeness of a tautology checker, correctness of the CANCEL metafunction, correctness of a simple assembly language program, correctness of a simple optimizing expression compiler basic/quant (59573 bytes) (Boyer and Moore, [2]) illustrations of the use of V&C$ and FOR, including a study of several partial functions and functions, such as the ``91 function'' that recurse on the value of their own recursive calls basic/rsa (17481 bytes) (Boyer and Moore, [9]) proof of the invertibility of the Rivest/Shamir/Adleman public key encryp- tion algorithm basic/small-machine (25494 bytes) (Moore) a simple operational semantics and its use to prove program properties directly and via the so-called ``functional'' and ``inductive assertion'' methods basic/tic-tac-toe (77473 bytes) (Moore) a formalization of what it means for a program to play non-losing tic-tac-toe, the proof that a certain algorithm does so, and the successive refinement of the algorithm into the functional expression of an iterative number- crunching program basic/tmi (17429 bytes) (Boyer and Moore, [10]) proof of the Turing completeness of Pure Lisp basic/unsolv (13796 bytes) (Boyer and Moore, [11]) proof of the unsol- vability of the halting problem for Pure Lisp basic/wilson (17576 bytes) (Russinoff, [12]) proof of Wilson's theorem basic/ztak (7065 bytes) (Moore, [13]) proof of the termination of Takeuchi's function bevier/kit (3258803 bytes) (Bevier, [14] the formalization, implementation and proof that a simple separation kernel (implementing multi-processing on a uniprocessor) provides process scheduling, error handling, message passing, and interfaces to asynchronous devices bronstein/* (360053 bytes) (Bronstein, [15, 16, 17] hardware verification using string-functional semantics) provides the set of events described in Alex Bronstein's dissertation. cowles/intro-eg (4902 bytes) (Cowles) a brief introduction to Nqthm intended for mathematicians and a proof of a theorem about factorial cowles/shell (9703 bytes) (Cowles) alternative ways to decompose sequences and a study of Nqthm's shell principle fm9001-piton/big-add (31064 bytes) (Moore, [18]) a proof of the correctness of a Piton program for adding arbitrarily long numbers 32 in base 2 fm9001-piton/fm9001 (2175131 bytes) (Brock and Hunt, [19]) formalizations of a netlist description language, the machine code for the 32-bit FM9001 microprocessor, the design of an implementation of the processor, and a proof of the correspondence of the design and the machine code specification fm9001-piton/piton (1709400 bytes) (Moore, [18]) the definition of the Piton assembly language, its implementation on the FM9001 via a compiler, assembler and linker, and a proof of the correctness of the FM9001 implementation fortran-vcg/fortran (10686 bytes) (Boyer and Moore, [4]) the same file as basic/fortran, above, which is duplicated on this subdirectory for technical reasons fortran-vcg/fsrch (59138 bytes) (Boyer and Moore, [4]) proofs of the verification conditions for a Fortran implementation of the Boyer-Moore fast string searching algorithm fortran-vcg/isqrt (12526 bytes) (Boyer and Moore, [20]) proofs of the verifica- tion conditions for a Fortran implementation of the integer version of Newton's square root algorithm fortran-vcg/mjrty (62019 bytes) (Boyer and Moore, [21]) proofs of the verifica- tion conditions for a Fortran implementation of a linear-time majority vote algorithm hunt/fm8501 (301605 bytes) (Hunt, [22]) formalizations of the machine code for the 16-bit FM8501 microprocessor, a register transfer model of a microcoded implementation of the machine, and a proof of their correspondence kaufmann/expr-compiler (4365 bytes) (Kaufmann, see Young [23]) the proof of correctness of a simple expression compiler, designed as an exercise for beginners kaufmann/foldr (10895 bytes) (Kaufmann) an illustration of a method of proving permutation-independence of list processing functions kaufmann/generalize-all (106112 bytes) (Kaufmann, [24]) the correctness of a generaliza- tion algorithm that operates in the presence of free variables kaufmann/koenig (15825 bytes) (Kaufmann, [25]) a proof of Koenig's tree lemma kaufmann/locking (6177 bytes) (Kaufmann, [26]) a model of a simple data base against which read and write transactions can occur kaufmann/mergesort-demo (4833 bytes) (Kaufmann) the correctness of a merge sort function kaufmann/note-100 (10071 bytes) (Kaufmann, [27]) the proof of Ramsey's theorem for exponent 2, finite case, described in a style intended to assist those wishing to improve their effectiveness with Nqthm kaufmann/partial (9925 bytes) (Kaufmann) an approach to handling partial functions with Nqthm kaufmann/permutationp-subbagp (2018 bytes) (Kaufmann) a formalization of the notion of permutation via bags kaufmann/ramsey (17010 bytes) (Kaufmann, [25]) a proof of Ramsey's theorem for the infinite case kaufmann/rotate (1900 bytes) (Kaufmann, [28]) a proof about rotations of lists, intended as an introduction to Nqthm kaufmann/rpn (3028 bytes) (Kaufmann and Jamsek) an exercise in reverse Polish notation evaluation kunen/ack (3520 bytes) (Kunen) an illustrative definition of Ackermann's function kunen/new-prime (39987 bytes) (Kunen) an alternative proof of the fundamental theorem of arithmetic that -- unlike the one presented in [8] -- does not use concepts not involved in the statement of the theorem numbers/bags (4888 bytes) (Bevier) a library of useful definitions and lemmas about bags numbers/extras (377 bytes) (Wilding) a trivial extension of the integers library used in fib2 below numbers/fib2 (15871 bytes) (Wilding, [29]) a proof of Matijasevich's lemma about Fibonacci numbers numbers/integers (236757 bytes) (Bevier, Kaufmann, and Wilding, [30]) a library of useful definitions and lemmas about the integers numbers/naturals (100476 bytes) (Bevier, Kaufmann, and Wilding, [31]) a library of useful definitions and lemmas about the natural numbers numbers/nim (51396 bytes) (Wilding) a formalization of the game of Nim and a proof that a certain algorithm implements a winning strategy shankar/church-rosser (61967 bytes) (Shankar, [32]) a proof of the Church-Rosser theorem for lambda-calculus shankar/goedel (1054073 bytes) (Shankar, [33]) a proof of Goedel's incom- pleteness theorem for Shoenfield's first order logic extended with Cohen's axioms for hereditarily finite set theory, Z2 shankar/tautology (68347 bytes) (Shankar, [34]) a proof that every tautology has a proof in Shoenfield's propositional logic talcott/mutex-atomic (127131 bytes) (Nagayama and Talcott, [35]) a proof of the local correctness of a mutual exclusion algorithm under a certain ``atomicity assumption'' talcott/mutex-molecular (169218 bytes) (Nagayama and Talcott, [35]) a proof of the local correctness of a mutual exclusion algorithm without the ``atomicity assumption'' mentioned above yu/bsearch (17548 bytes) (Yu, [36]) the correctness proof for the MC68020 machine code produced by the Gnu C compiler for a binary search program written in C yu/gcd (13392 bytes) (Yu, [36]) the correctness proof for the MC68020 machine code produced by the Gnu C compiler for Euclid's greatest common divisor algorithm written in C yu/group (31947 bytes) (Yu, [37]) proofs of two theorems in finite group theory, the first is about kernels of homomorphisms and the second is the Lagrange theorem yu/isqrt-ada (14118 bytes) (Yu) the correctness proof for the MC68020 machine code produced by the Verdix Ada compiler from an Ada program for computing integer square roots via Newton's method written in C yu/mc20-0 (26383 bytes) (Yu, [36]) some utilities involved in the formal specification of the MC68020 yu/mc20-1 (165631 bytes) (Yu, [38]) the formal specification of about 80% of the user available instructions for the Motorola MC68020 microprocessor yu/mc20-2 (166450 bytes) (Yu, [36]) a library of useful definitions and lemmas about the formalization of the MC68020 yu/mjrty (33507 bytes) (Yu) the correctness proof for the MC68020 machine code produced by the Gnu C compiler for a linear time majority vote algorithm written in C yu/qsort (65665 bytes) (Yu) the correctness proof for the MC68020 machine code produced by the Gnu C compiler for Hoare's in situ quick sort program written in C yu/log2 (9212 bytes) (Yu) the correctness proof for the MC68020 machine code produced by the Gnu C compiler for a C program for computing integer logarithms (base 2) e.g., repeated division by 2 yu/cstring, yu/mem*.events, yu/str*.events (251139 bytes) (Yu) verifications of MC68020 machine code of 15 of the 19 C String Library functions from the Berkeley Unix C String Library -------------------- Pc-Nqthm applications -------------------- Disclaimer: Many of the events in "basic/" are inelegant, as they were worked out in the early phases of the development of Pc-Nqthm. They are not to be viewed as models of good usage! Some of these use the DEFN-SK quantifier enhancement [25], which may or may not be included in a final release of Pc-Nqthm but will remain available in any case. basic/arith.events (10632 bytes) some supporting arithmetic events for other event files in this directory basic/hanoi.events (15461 bytes) (Kaufmann) proof of correctness of a Towers of Hanoi program basic/pigeon-hole.events (2369 bytes) (Kaufmann) proof of a version of the pigeon-hole principle basic/ramsey1.events (12633 bytes) (Kaufmann) Our original proof of correctness of Ramsey's Theorem for exponent 2 basic/ramsey2.events (1792 bytes) (Kaufmann) proof that a certain binomial coefficient serves as a bound on the Ramsey number basic/square.events (5798 bytes) (Kaufmann) ugly proof of an ugly formalization of the irrationality of the square root of 2 basic/subset.events (5025 bytes) (Kaufmann) some supporting events about lists and their use as an implementation of sets basic/symmetric-difference.events (3221 bytes) (Kaufmann) commutativity and associativity of symmetric difference as a set operation basic/transitive-closure.events (17530 bytes) (Kaufmann) proof of correctness of a transitive closure algorithm basic/tsquare.events (40440 bytes) (Kaufmann) proof of correctness of a ``true square'' algorithm of Gries defn-sk/csb.events (18698 bytes) (Kaufmann, [25]) proof of a formalization of the Schroeder-Bernstein theorem of set theory defn-sk/finite-state-machine-example.events (8062 bytes) (Kaufmann) a little finite state machine example defn-sk/koenig.events (13469 bytes) (Kaufmann, [25]) a formalization of Koenig's Tree Lemma, which says that any finitely branching tree which is infinite has an infinite branch defn-sk/ramsey.events (13514 bytes) (Kaufmann, [25]) proof of a formalization of the infinite Ramsey Theorem for exponent 2 dmg/bags.events (4480 bytes) (Bevier, [31]) some supporting events about bags dmg/dining.events (86876 bytes) (Goldschlag [39]) the verification of a dining philosopher's program, under the assumptions of deadlock freedom and strong fairness, using a mechanized implementation of Unity on the Boyer-Moore prover dmg/fifo.events (148159 bytes) (Goldschlag [40]) the verification of both the safety and liveness properties of an n-node delay insensitive fifo circuit, using a mechanized implementation of Unity on the Boyer-Moore prover dmg/interpreter.events (59999 bytes) (Goldschlag [41]) a mechanized implementation of Unity on the Boyer-Moore prover dmg/me.events (36101 bytes) (Goldschlag) verification of an n-processor program satisfying both mutual exclusion and absence of starvation, using a mechanized implementation of Unity on the Boyer-Moore prover dmg/min.events (261122 bytes) (Goldschlag) the correctness of a distributed algorithm that computes the minimum node value in a tree, using a mechanized implementation of Unity on the Boyer-Moore prover dmg/naturals.events (77298 bytes) (Bevier, Wilding [31]) some supporting events about natural numbers generalize/*.events (92003 bytes) (Kaufmann, [24]) the correctness of a generaliza- tion algorithm that operates in the presence of free variables; same as kaufmann/generalize-all from the Nqthm suite, except that the quantifier (DEFN-SK, [25]) events have been replaced by DCL and ADD-AXIOM events in that version mg/*.events (1961835 bytes) (Young, [42]) a mechanically-verified code- generator for micro-Gypsy, which is a Pascal-like language middle-gypsy/*.events (2048662 bytes) (Good, Siebert, Young, [43]) a mathematical definition of a subset of the Gypsy 2.05 language, including a preliminary rationals library created by Matt Wilding(This rationals library contains Pc-Nqthm ``Instructions'' hints. If not for that, it seems quite possible that all of this would replay in Nqthm, with the DEFN-SK enhancement loaded.) wilding/ground-resolution.events (80997 bytes) (Wilding) a proof of the completeness of ground resolution using Bledsoe's excess literal technique ===== Section 4. Applications survey, Nqthm and Pc-Nqthm: Part II ===== Here we present detailed summaries of a few of the larger applications, in the format requested. These have been supplied by participants in the respective applications, with at most minor editing by Matt Kaufmann. These are listed alphabetically by the first last name in ``participants'' (got that?). -------------------------------------------------- Name of application project: CLI Verified Stack Participants: Bill Bevier, Warren Hunt, J Moore, Bill Young Contact name and address: Dr. Bill Young Computational Logic, Inc. 1717 W. 6th St., Suite 290 Austin, TX 78703 (512) 322-9951 email: young@CLI.COM Level of effort: 4 people, around 2 years Brief description: The CLI ``verified stack'' is a collection of system components, each built upon the previous one, each subsequently providing more abstraction, and each being formally specified and mechanically verified using the Boyer-Moore theorem prover `Nqthm' (and in the case of Bill Young's work, the interactive enhancement `Pc-Nqthm' of Nqthm). The system we have constructed contains a microprocessor with machine code, an assembly language, and a simple high-level programming language, together with the compiler, assembler and linker necessary to connect them. The stack properly consists of four abstract machines: 1. Gates--a register-transfer model of a microcoded machine. 2. FM8502--a machine code interpreter. More recently, this has been replaced by FM9001, which is a hardwired, 32-bit machine. 3. Piton--a high-level assembly language. 4. Micro-Gypsy--a simple high-level language which is a subset of the Gypsy 2.05 programming and specification language. Relating each pair of adjacent machines is an implementation, represented as a function in the Boyer-Moore logic, that maps a higher-level state into a lower-level state. The implementation function is known as a ``compiler'' for the step from Micro-Gypsy to Piton, but as a ``link-assembler'' for the step from Piton to FM8502. In addition, we have specified and proved correct the implementation a small operating system kernel (KIT) written for a uniprocessor von Neumann machine. KIT is proved to implement a fixed number of conceptually distributed communicating processes on this shared computer. In addition to implementing processes, Kit provides the following verified services: process scheduling, error handling, message passing, and an interface to asynchronous devices. KIT is not currently integrated into our stack. We believe that this is the first hierarchically verified system of such complexity. It is possible using these components to compose and verify a high level program, and generate a core image for a microprocessor which provably preserves the semantics. We believe that future progress in this direction will lead to a higher degree of reliability than any existing approach. We found many errors during the development of these systems. The discovery of these errors was a direct result of the use of a theorem prover: failed proofs would point us to the errors in our definitions. Thus, we have relearned a lesson that we already knew: although it is expensive, mechanical verification can assist in the discovery of errors and thus contribute significantly to the development of high-reliability systems. Published articles and reports: Journal of Automated Reasoning, Vol. 5, No. 4 (November, 1989) contains 5 papers describing the stack and the individual components. -------------------------------------------------- Name of application project: PREVAIL Participants: D.Borrione, L.Pierre, A.Salem, C.Le Faou, S.Coupet Contact name and address: D.Borrione or L.Pierre IMAG/ARTEMIS, BP 53X 38041 Grenoble Cedex, FRANCE email : borrione@imag.fr or lolo@imag.fr Level of effort : 2 person-years Brief description : - Outline the nature of the application, the tools/techniques employed: PREVAIL is a prototype environment for the formal proof of digital devices. It takes as input VHDL circuit descriptions, and automatically verifies their correctness. Several proof tools are included in this system, and NQTHM is one of them. - What role did the formal methods play in the development process? We have defined the functional semantics of a subset of VHDL. Then, inspired by the works of W.Hunt as reported in his PhD thesis, we have written a translator which automatically produces the function definitions and the theorems to be proven, under the input format for NQTHM. - What were the benefits? We use this prover in order to perform some kinds of proofs that are impossible with other tools, such as boolean tautology checkers. The main advantages are the possibility of reasoning on parameterized devices, and its ability to deal simultaneously with bit-vectors and integers. - What were the drawbacks? The major drawback, from our point of view, is the difficulty to identify whether a proof failed because the device is erroneous or because the theorem is not written in the right way. In addition, it is almost impossible to return a meaningful diagnosis to the user when there is a fault. - What lessons can be drawn, recommendations made? In view of the previous remark, it would be useful to have a summarized history of the proof (with the essential points) as an alternative to the complete one. Published articles and reports : L.PIERRE : The Formal Proof of Sequential Circuits described in CASCADE using the Boyer-Moore Theorem Prover.'' Proc. IFIP WG 10.2 Int. Workshop Nov. 1989. In ``Formal VLSI Correctness Verification,'' L.Claesen Ed., North Holland, 1990, ISBN 0444 88689 3. L.PIERRE : ``One Aspect of Mechanizing Formal Proof of Hardware : the Generalization of Partial Specifications.'' Proc. ACM International Workshop on Formal Methods in VLSI Design. Miami (Florida). 9-11 January 1991. L.PIERRE : ``From a HDL Description to Formal Proof Systems : Principles and Mechanization.'' Proc. 10th International Symposium on Computer Hardware Description Languages and their Applications. Marseille (France). 22-24 April 1991. S.COUPET, L.PIERRE : ``Recursive Models for Synchronous Sequential Devices.'' Research report IMAG/ARTEMIS 855-I, Grenoble. July 1991. C.LE FAOU, L.PIERRE, A.SALEM : ``A user-oriented presentation of PREVAIL : a proof environment for VHDL descriptions.'' Technical report IMAG/ARTEMIS RT71, Grenoble. September 1991. D.BORRIONE, L.PIERRE, A.SALEM : ``PREVAIL : a proof environment for VHDL descriptions.'' Proc. Advanced Research Workshop on Correct Hardware Design Methodologies, Torino, Italy, June 12-14, 1991. D.BORRIONE, L.PIERRE, A.SALEM : ``Formal Verification of VHDL Descriptions in the PREVAIL Environment.'' To appear in a Special Issue of IEEE Design&Test on VHDL, 1992. -------------------------------------------------- Name of application project: Compiler for NQTHM Logic Participants: Arthur Flatau Contact name and address: Arthur Flatau Computational Logic Inc. 1717 W. 6th St., Suite 290 Austin, TX 78703 (512) 322-9951 email flatau@cli.com Level of effort: approx 3 man-years Brief description: A compiler from the NQTHM logic to the Piton assembly level language is being built. The compiler will include a reference count garbage collector. The compiler is written and formally specified in the NQTHM logic. Currently a prototype and its proof of correctness has been completed and work is underway to add the garbage collector. Published articles and reports: Arthur Flatau, ``A Compiler for NQTHM: A Progress Report.'' Technical Report 74, Computational Logic, Inc., February 1992. -------------------------------------------------- Name of application project: Mechanically Verifying Concurrent Programs Participants: David Goldschlag Contact name and address: David Goldschlag National Security Agency Attn: R232 Fort George G. Meade, Maryland 20755-6000 Voice: (410) 859-4494 Fax: (410) 850-7166 email: goldschlag@tycho.ncsc.mil Level of effort: Four person years over four years Brief description: This project embeds Chandy and Misra's Unity logic on Kaufmann's proof checker extension of the Boyer-Moore prover, and demonstrates this theory by the mechanical verification of four simple, yet parameterized, concurrent programs: - a dining philosopher's program proved under the assumptions of strong fairness and absence of deadlock; - an n-node delay insensitive fifo circuit; - an n-processor program satisfying both mutual exclusion and absence of starvation; and - a distributed algorithm that computes the minimum node value in a tree. Various first order safety and liveness properties are proved. These mechanized proofs are expensive, however. This mechanized proof system is novel, since it is sound by construction. Unity's proof rules are proved as theorems about an arbitrary fair computation, rather than presented as axioms characterizing a logic. This methodology of building a proof system on top of an operational semantics is a reasonable and useful technique for developing sound proof systems. Published articles and reports D.M. Goldschlag, A Mechanical Formalization of Several Fairness Notions, in VDM `91: Formal Software Development Methods, S. Prehn and W.J. Toetenel (Editors), Springer-Verlag Lecture Notes in Computer Science 551, Springer-Verlag, Berlin, 1991. D.M. Goldschlag, Mechanically Verifying Safety and Liveness Properties of Delay Insensitive Circuits, Computer Aided Verification 1991, Aalborg, Denmark, July 1991. D.M. Goldschlag, Verifying Safety and Liveness Properties of a Delay Insensitive FIFO Circuit on the Boyer-Moore Prover, 1991 International Workshop on Formal Methods in VLSI Design, Miami, January, 1991. D.M. Goldschlag, Mechanically Verifying Concurrent Programs with the Boyer-Moore Prover, IEEE Transactions on Software Engineering, September 1990. D.M. Goldschlag, Proving Proof Rules: A Proof System for Concurrent Programs, Fifth Annual Conference on Computer Assurance, Compass 1990, Maryland, June 1990. D.M. Goldschlag, Mechanizing Unity, in Programming Concepts and Methods, M. Broy and C.B. Jones (editors), North-Holland, Amsterdam, 1990. J.M. Crawford and D.M. Goldschlag, Mechanical Verification, The Twenty-Sixth Annual Lake Arrowhead Workshop: How Will We Specify Concurrent Systems in the Year 2000?, Lake Arrowhead, California, September, 1987. -------------------------------------------------- Name of application project: Generalization in the Presence of Free Variables: A Mechanically-Checked Proof for One Algorithm Participants: Matt Kaufmann Contact name and address: Matt Kaufmann Computational Logic Inc. 1717 W. 6th St., Suite 290 Austin, TX 78703 (512) 322-9951 email kaufmann@cli.com Level of Effort: Roughly 2 man-months Brief Description: Some of the following is adapted from the paper referenced below. The motivation for this work began with a concern generated by a soundness bug in the Pc-Nqthm command GENERALIZE. This bug could be viewed as resulting from a delicate interaction between the first-order inference rule of universal instantiaion and ``free'' (instantiatable, Skolem) variables. At any rate, the bug was easily corrected and the correctness of the resulting GENERALIZE command was checked quite informally on paper (though that wasn't quite as easy). However, the rude shock of having made a soundness mistake in the previous version of Pc-Nqthm led to the following goal: formalize the new version of the GENERALIZE command in the Boyer-Moore logic, and mechanically check a proof of correctness of this formalization. This work consists of a mechanically-checked proof of correctness for a generalization algorithm. Although the theorem itself is probably new (at least, we are unaware of any existing statement of it), the interest here lies not particularly in the theorem per se but, rather, lies in the demonstration of the use of an automated reasoning assistant to check the reliability of detailed proofs and software. What is new about the current effort is the use of the Boyer-Moore prover (slightly extended) to check a non-trivial logic proof related to the correctness of an actual implementation, though it must be conceded that the actual Pc-Nqthm code is not a direct translation of the definitions from this proof, but is only conceptually related to them. The paper referenced below is written with the intention of providing a good introduction to this style of mechanically- assisted reasoning. Published articles and reports: Matt Kaufmann, ``Generalization in the Presence of Free Variables: A Mechanically-Checked Proof for One Algorithm.'' J. of Automated Reasoning 7, March, 1991. -------------------------------------------------- Name of application project: A Formal Model of Asynchronous Communication and Its Use in Mechanically Verifying a Biphase Mark Protocol Participants: J Strother Moore Contact name and address: J Strother Moore Computational Logic Inc. 1717 W. 6th St., Suite 290 Austin, TX 78703 (512) 322-9951 email moore@cli.com Level of Effort: 3 man-months Brief Description: In this paper we present a formal model of asynchronous communication as a function in the Boyer-Moore logic. The function transforms the signal stream generated by one processor into the signal stream consumed by an independently clocked processor. This transformation ``blurs'' edges and ``dilates'' time due to differences in the phases and rates of the two clocks and the communications delay. The model can be used quantitatively to derive concrete performance bounds on asynchronous communications at ISO protocol level 1 (physical level). We develop part of the reusable formal theory that permits the convenient application of the model. We use the theory to show that a biphase mark protocol can be used to send messages of arbitrary length between two asynchronous processors. We study two versions of the protocol, a conventional one which uses cells of size 32 cycles and an unconventional one which uses cells of size 18. Our proof of the former protocol requires the ratio of the clock rates of the two processors to be within 3% of unity. The unconventional biphase mark protocol permits the ratio to vary by 5%. At nominal clock rates of 20MHz, the unconventional protocol allows transmissions at a burst rate of slightly over 1MHz. These claims are formally stated in terms of our model of asynchrony; the proofs of the claims have been mechanically checked with the Boyer-Moore theorem prover, NQTHM. We conjecture that the protocol can be proved to work under our model for smaller cell sizes and more divergent clock rates but the proofs would be harder. Known inadequacies of our model include that (a) distortion due to the presence of an edge is limited to the time span of the cycle during which the edge was written, (b) both clocks are assumed to be linear functions of time (i.e., the rate of a given clock is unwavering) and (c) reading ``on an edge'' produces a nondeterministically defined value rather than an indeterminate value. We discuss these problems. Published articles and reports: J Strother Moore, ``A Formal Model of Asynchronous Communication and Its Use in Mechanically Verifying a Biphase Mark Protocol.'' Technical Report 68, Computational Logic, Inc., August, 1991. -------------------------------------------------- Name of application project: Checking correctness of mutex algorithm Participants: Misao Nagayama and Carolyn Talcott Contact name and address: Carolyn Talcott Computer Science Department Stanford University Stanford CA 94305 clt@sail.stanford.edu Level of effort: One graduate student part time for approximately one year. Brief description: This was an exercise in checking an informal proof. It was carried out by a logic student who had no previous experience with computers, or provers, as a means of learning about using computers. We began with an informal proof of a Mutex Algorithm, given by Manna and Pnueli, based on their formalism for reasoning about concurrent programs. Minor modifications in data structures modelling program state were made to facilitate representation in the Nqthm logic. The Nqthm events followed closely the informal proof analysis. Some work was required to fill in details in some cases, and to find the right hints and lemmas. Published articles and reports: Nagayama, Misao and Talcott, Carolyn, ``An NQTHM Mechanization of `An Exercise in the Verification of Multi-Process Programs'.'' Technical Report STAN-CS-91-1370, Computer Science Department, Stanford University, 1991. -------------------------------------------------- Name of application project: Verification of Cathedral hardware module library. Participants: D. Verkest and J. Vandenbergh Contact names and address: D. Verkest or L. Claesen, IMEC (VSDM), Kapeldreef 75, B-3001 Leuven, Belgium; email verkest%imec.imec.be@imec.be Level of effort: 3 to 4 man years Brief description: The project is concerned with the formal verification with Nqthm of the functional correctness of parameterized hardware module libraries for use in high level silicon compilers. The libraries contain more than 25 modules of varying complexity ranging from simple functional building blocks which implement logical functions to a complex and highly optimized Booth multiplier module. The library contains both combinational and sequential blocks. A library of bit vector functions has been developed together with a set of lemmas expressing useful properties of these functions. Abstraction functions and representation functions allow for switching between the bit vector domain and the domain of natural numbers and integers. The behavioral specification of the modules is modeled as a function in the logic using these bit vector functions. The behavior of the basic cells (leaf cells) is also modeled by functions in the logic (using the built-in logical connectives of the logic). The parameterized structure of the modules is described hierarchically in terms of the leaf cells. A proof of correctness is then constructed using Nqthm. Since all of the modules are parameterized in the word length of their input signals, the correctness proofs make use of Nqthm's induction capabilities. During the development of the proofs the interactive proof checker (Pc-Nqthm) and Nqthm's interactive break facilities (BREAK-LEMMA) are used to investigate the cause of proof failures. Once the formal proof of a module is completed the possibility exists to automatically generate parameterized descriptions of its structure in a traditional hardware description language. These descriptions can be used by standard cell packages to generate (guaranteed correct) layout. In addition it is possible to perform net list comparison between instances of the module generated from the formal descriptions in the Boyer-Moore logic and the actual full-custom layout of the modules. The library of bit vectors is also used to describe the semantics of operators in various hardware description languages in use at IMEC and it has been used to describe and verify the implementation of a division algorithm on an arithmetic logic unit with respect to the division on integers [2]. Some of the lemmas in this proof are realized with the interactive proof checker (Pc-Nqthm). The main benefit of this project lies in a large increase in quality of the module library developed. The theorem prover approach forced us to meticulously check the consistency between implementation, specification and documentation of all aspects of the modules at all levels of hierarchy and abstraction. Many inconsistencies, including errors in functionality of the modules, were (and are still being) discovered using this approach. In addition the bit vector function library developed in the project can be used to check consistency between operators defined in the various hardware description languages at different levels of abstraction. Although the use of a theorem prover requires a large effort from a skilled user, we believe this effort is justified for the specific application domain of module libraries (or more in general any hardware/software library) because the effort can be written off over all the instances of the various modules which are generated. Published articles and reports: [1] D.Verkest, L.Claesen, H.De Man, ``On the use of the Boyer-Moore theorem prover for correctness proofs of parameterized hardware modules,'' in Formal VLSI Specification and Synthesis, Ed. L.Claesen, Elsevier Science Publishers (North Holland), 1990, pp.99-116 [2] D.Verkest, L.Claesen, H.De Man, ``A proof of the non restoring division algorithm and its implementation on the Cathedral-II ALU,'' Proc. of the workshop on Designing Correct Circuits, DCC-92, Lyngby, Denmark, 6-8 January 1992. -------------------------------------------------- Name of application project: A Proven-Correct Compiler Front-End Participants: Debora Weber-Wulff Contact name and address: Debora Weber-Wulff, Institut fuer Informatik der FU Berlin, Nestorstr. 8-9, D-W-1000 Berlin 31 Level of effort: 2 1/2 years invested, probably 2 more years needed Brief description: The goal of this dissertation project is to prove an implementation for compiler front-ends correct with respect to a set of specifications using a mechanical verification system, the Boyer-Moore prover. The front-end consists of a scanner, a skeleton parser, a transformer from concrete to abstract syntax, and a parser table generator. The front-ends are for compilers that were developed for the ProCoS (ESPRIT BRA 3104: Provably Correct Systems) project. The fully verified front-ends will in the LISP subset employed by the rest of the compiler effort. The rest of the compiler, which compiles a representation for abstract syntax into Transputer code, has been proven correct by hand proofs. One major benefit of using the prover is that one is made to very carefully examine what one is doing. Even the slightest presupposition that is not explicitly stated will make a proof fail or fail to terminate. The major drawback is the incredible learning curve associated with using the prover outside of Austin. It takes an enormous amout of time before one begins to feel comfortable proving even trivialities. Larger proof attempts without the support of persons experienced in using the prover are extremely difficult. It has been observed that one spends most of one's time patiently coaxing this stubborn prover into assenting to the obvious. In order for the prover to be more usable outside of Austin, there needs to be more of a body of little examples that illuminate perhaps one point about the use of the prover and more libraries available, so that one can build on "proven knowledge" and not have to begin every proof literally at GROUND-ZERO. Published articles and reports: ``Trip Report : Visit to Computational Logic, Inc., Austin, Texas'' ProCoS Report. Kiel, February 1990. ``Proof Movie : Proving the Add-Assign Compiler with the Boyer-Moore Prover''. ProCoS Report. Kiel, July 1990. A thoroughly revised version is to appear in Formal Aspects of Computing. ``The `Automated Proving and Term Rewriting' Praktikum''. Zusammen mit Karl-Heinz Buth. ProCoS Report. Kiel, February 1991. ``Pass Collapsing : An Optimization Method for Compiler Proofs''. ProCoS Report. Kiel, September 1991. ``Proven Correct Front-end Specification''. In: ESPRIT BRA 3104 ProCoS: Provably Correct Systems Final Report. Volume 3. Dines Bjorner (Ed.). In preparation. -------------------------------------------------- 1. J S. Moore, ``A Formal Model of Asynchronous Communication and Its Use in Mechanically Verifying a Biphase Mark Protocol'', Tech. report CLI Technical Report 68, Computational Logic, Inc., 1717 W. Sixth Street, Suite 290, Austin, TX 78703, August 1991. 2. R. S. Boyer and J S. Moore, ``The Addition of Bounded Quantification and Partial Functions to A Computational Logic and Its Theorem Prover'', Tech. report ICSCA-CMP-52, Institute for Computer Science, University of Texas at Austin, January 1988, To appear in the Journal of Automated Reasoning, 1988 3. R. S. Boyer, M. W. Green and J S. Moore, ``The Use of a Formal Simulator to Verify a Simple Real Time Control Program'', Technical Report ICSCA-CMP-29, University of Texas at Austin, 1982. 4. R. S. Boyer and J S. Moore, ``A Verification Condition Generator for FORTRAN'', in The Correctness Problem in Computer Science, R. S. Boyer and J S. Moore, eds., Academic Press, London, 1981. 5. R.S. Boyer, D. Goldschlag, M. Kaufmann, J S. Moore, ``Functional Instantiation in First Order Logic'', in Artificial Intelligence and Mathematical Theory of Computation: Papers in Honor of John McCarthy, V. Lifschitz, ed., Academic Press, 1991, pp. 7-26. 6. D.M. Russinoff, ``A Mechanical Proof of Quadratic Reciprocity'', Journal of Automated Reasoning, Vol. 8, No. 1, 1992, pp. ???. 7. R. S. Boyer and J S. Moore, A Computational Logic Handbook, Academic Press, Boston, 1988. 8. R. S. Boyer and J S. Moore, A Computational Logic, Academic Press, New York, 1979. 9. R. S. Boyer and J S. Moore, ``Proof Checking the RSA Public Key Encryption Algorithm'', American Mathematical Monthly, Vol. 91, No. 3, 1984, pp. 181-189. 10. R. S. Boyer and J S. Moore, ``A Mechanical Proof of the Turing Completeness of Pure Lisp'', in Automated Theorem Proving: After 25 Years, W.W. Bledsoe and D.W. Loveland, eds., American Mathematical Society, Providence, R.I., 1984, pp. 133-167. 11. R. S. Boyer and J S. Moore, ``A Mechanical Proof of the Unsolvability of the Halting Problem'', JACM, Vol. 31, No. 3, 1984, pp. 441-458. 12. D.M. Russinoff, ``A Mechanical Proof of Wilson's Theorem'', Masters Thesis, Department of Computer Sciences, University of Texas at Austin, 1983. 13. J S. Moore, ``A Mechanical Proof of the Termination of Takeuchi's Function'', Information Processing Letters, Vol. 9, No. 4, 1979, pp. 176-181. 14. W. Bevier, A Verified Operating System Kernel, PhD dissertation, University of Texas at Austin, 1987. 15. A. Bronstein, MLP: String-functional semantics and Boyer-Moore mechanization for the formal verification of synchronous circuits, PhD dissertation, Stanford Univer- sity, 1989. 16. A. Bronstein and C. Talcott, ``String-Functional Semantics for Formal Verification of Synchronous Circuits, Report No. STAN-CS-88-1210'', Tech. report, Computer Science Depart- ment, Stanford University, 1988. 17. A. Bronstein and C. Talcott, ``Formal Verification of Synchronous Circuits based on String-Functional Semantics: The 7 Paillet Circuits in Boyer-Moore'', C-Cube 1989 Workshop on Automatic Verification Methods for Finite State Systems. LNCS 407, 1989, pp. 317-333. 18. J S. Moore, ``Piton: A Verified Assembly-Level Language'', Tech. report CLI-22, Computational Logic, Inc., Austin, Tx, June 1988. 19. W.A. Hunt, Jr. and B. Brock , ``A Formal HDL and its use in the FM9001 Verification'', Proceedings of the Royal Society, 1992, to appear April 1992 20. R. S. Boyer and J S. Moore, ``The Mechanical Verification of a FORTRAN Square Root Program'', CSL Report, SRI International, 1981. 21. R. S. Boyer and J S. Moore, ``MJRTY - A Fast Majority Vote Algorithm'', Technical Report ICSCA-CMP-32, Institute for Computing Science and Computer Applications, University of Texas at Austin, 1982. 22. W.A. Hunt, Jr., FM8501: A Verified Microprocessor, PhD dissertation, University of Texas at Austin, 1985. 23. W.D. Young, ``A Simple Expression Compiler: A Programming and Proof Example for an Nqthm Course'', Tech. report Internal Note 210, Computational Logic, Inc., 1717 W. Sixth Street, Suite 290, Austin, TX 78703, November 1990. 24. M. Kaufmann, ``Generalization in the Presence of Free Variables: A Mechanically-Checked Proof for One Algorithm'', Journal of Automated Reasoning, Vol. 7, No. 1, March 1991. 25. M. Kaufmann, ``An Extension of the Boyer-Moore Theorem Prover to Support First-Order Quantification'', Tech. report CLI Technical Report 43, Computational Logic, Inc., 1717 W. Sixth Street, Suite 290, Austin, TX 78703, May 1989, To appear in J. of Automated Reasoning 26. M. Kaufmann, ``A Simple Example for Nqthm: Modeling Locking'', Tech. report Internal Note 216, Computational Logic, Inc., 1717 W. Sixth Street, Suite 290, Austin, TX 78703, February 1991. 27. M. Kaufmann, ``An Example in Nqthm: Ramsey's Theorem'', Tech. report Internal Note 100, Computational Logic, Inc., 1717 W. Sixth Street, Suite 290, Austin, TX 78703, May 1991. 28. M. Kaufmann, ``An Instructive Example for Beginning Users of the Boyer-Moore Theorem Prover'', Tech. report Internal Note 185, Computational Logic, Inc., 1717 W. Sixth Street, Suite 290, Austin, TX 78703, April 1990. 29. M. Wilding, ``Proving Matijasevich's Lemma with a Default Arithmetic Strategy'', Journal of Automated Reasoning, Vol. 7, No. 3, 1991, pp. 439-446. 30. M. Kaufmann, ``An Integer Library for Nqthm'', Tech. report Internal Note 182, Computational Logic, Inc., 1717 W. Sixth Street, Suite 290, Austin, TX 78703, March 1990. 31. W.R. Bevier, ``A Library for Hardware Verification'', Tech. report Internal Note 57, Computational Logic, Inc., 1717 W. Sixth Street, Suite 290, Austin, TX 78703, August 1988. 32. N. Shankar, ``A Mechanical Proof of the Church-Rosser Theorem'', Tech. report ICSCA-CMP-45, Institute for Computing Science, University of Texas at Austin, 1985. 33. N. Shankar, Proof Checking Metamathematics, PhD disser- tation, University of Texas at Austin, 1986. 34. N. Shankar, ``Towards Mechanical Metamathematics'', Journal of Automated Reasoning, Vol. 1, No. 4, 1985, pp. 407-434. 35. M. Nagayama and C. Talcott, ``An NQTHM Mechanization of ``An Exercise in the Verification of Multi-Process Programs'''', Tech. report STAN-CS-91-1370, Computer Science Department, Stanford University, 1991. 36. R.S. Boyer and Y. Yu, ``Automated Correctness Proofs of Machine Code Programs for a Commercial Microprocessor'', Tech. report TR-91-33, Computer Sciences Department, University of Texas, Austin, November 1991. 37. Y. Yu, ``Computer Proofs in Group Theory'', Journal of Automated Reasoning, Vol. 6, No. 3, 1990. 38. R.S. Boyer and Y. Yu, ``A Formal Specification of Some User Mode Instructions for the Motorola 68020'', Tech. report TR-92-04, Computer Sciences Department, University of Texas, Austin, February 1992. 39. David Goldschlag, ``A Mechanical Formalization of Several Fairness Notions'', in VDM '91: Formal Software Development Methods, S. Prehn and W.J. Toetenel, eds., Springer-Verlag Lecture Notes in Computer Science 551, 1991. 40. David M. Goldschlag, ``Mechanically Verifying Safety and Liveness Properties of Delay Insensitive Circuits'', Computer Aided Verification 1991, July 1991. 41. David M. Goldschlag, ``Mechanizing Unity'', in Programming Concepts and Methods, M. Broy and C. B. Jones, eds., North Holland, Amsterdam, 1990. 42. William D. Young, ``A Mechanically Verified Code Generator'', Journal of Automated Reasoning, Vol. 5, No. 4, December 1989, pp. 493-518, Also published as CLI Technical Report 30 43. Donald I. Good, Ann E. Siebert, William D. Young, ``Middle Gypsy 2.05 Definition'', Technical Report 59, Computational Logic, Inc., May 1990. Received: by CLI.COM (4.1/1); Tue, 7 Jul 92 08:43:11 CDT Received: from fubinf by mail.Germany.EU.net with UUCP (5.65+/UNIDO-2.1.0.b) via EUnet for cli.com id AA10282; Tue, 7 Jul 92 15:44:49 +0200 Received: from sparc5.inf.fu-berlin.de by inf.fu-berlin.de (4.1/SMI-4.1) id AA06185; Tue, 7 Jul 92 15:22:32 +0200 Date: Tue, 7 Jul 92 15:22:31 +0200 From: fubinf!weberwu (Debora Weber-Wulff) Message-Id: <9207071322.AA06185@inf.fu-berlin.de> To: fubinf!nqthm-users Subject: Re: Breaking of DEFN Oh yes, I've had that happen a few times. Matt Kaufmann explained the mechanics to me once, but I'm afraid that I've forgotton just why that is. Anyway, it is not important: only those theorems are considered to be "Boyer-Moore-proven" that start at ground-zero and are built up without any user interaction (such as Ctrl-C) and either without using axioms or only using those which can be proven to be non-contradicting. While I have the soap-box I want to add that even proven correct software can be "incorrect". I had this wonderful little function (BAR) that transformed number representations into numbers. I proved it correct, and even proved some "glue" between this function and a previous function that produces the input for the number transformer, let's call that one FOO. I proved that FOO produces a list of lists of NUMBERPs. I proved that BAR takes a list of lists of NUMBERPs and produces a list of NUMBERPs such that each element of the list was a number corresponding to the representation given in the input list. When I first tested the function composition on (BAR (FOO l)) I fell flat on my face: FOO used NUMBERPs representing the ASCII coding of the digits; BAR expected digits 0-9. Both are NUMBERPs, so the glue proved okay! Of course, it was easy to fix with a function BAZ that converts ASCII to digits and some predicates ASCII-DIGIT-P and DECIMAL-DIGIT-P ..... but still. The moral of the story: don't get lazy with data types just because it is a pain to tell the prover about them ("Yes dear, lists that consist of ASCII-DIGIT-Ps aren't disturbed by the application of APPEND or REVERSE or LENGTH or ...." You know how it is!). ----- Debora Weber-Wulff dww@inf.fu-berlin.de Institut fuer Informatik +49 30 89691 124 Nestorstr. 8-9 (INCLUDE "standard.disclaimer") D-W-1000 Berlin 31 (PRINTN (WITTY-MESSAGE TODAY)) Received: by CLI.COM (4.1/1); Tue, 7 Jul 92 08:42:58 CDT Received: from fubinf by mail.Germany.EU.net with UUCP (5.65+/UNIDO-2.1.0.b) via EUnet for cli.com id AA10246; Tue, 7 Jul 92 15:44:37 +0200 Received: from methan.chemie.fu-berlin.de by inf.fu-berlin.de (4.1/SMI-4.1) id AA05990; Tue, 7 Jul 92 14:56:10 +0200 Received: by methan.chemie.fu-berlin.de (/\@@/\ Smail3.1.25.1 #25.7) id ; Tue, 7 Jul 92 14:58 MES Received: by ki1.chemie.fu-berlin.de (/\@@/\ Smail3.1.25.1 #25.8) id ; Tue, 7 Jul 92 14:53 MEST Received: from tubvm.cs.tu-berlin.de by mail.cs.tu-berlin.de with SMTP id AA12667 (5.65c8/IDA-1.4.4(mail.m4[1.9]) for ); Tue, 7 Jul 1992 14:55:57 +0200 Received: from TUBVM.CS.TU-BERLIN.DE by tubvm.cs.tu-berlin.de (IBM VM SMTP R1.2.2MX) with BSMTP id 2725; Tue, 07 Jul 92 14:55:24 +02 Received: from DEARN by TUBVM.CS.TU-BERLIN.DE (Mailer R2.07B) with BSMTP id 2701; Tue, 07 Jul 92 14:55:23 +0200 Received: from vm.uni-c.dk by DEARN (Mailer R2.08) with BSMTP id 3430; Tue, 07 Jul 92 14:49:17 MET Received: from NEUVM1 by vm.uni-c.dk (Mailer R2.07) with BSMTP id 7704; Tue, 07 Jul 92 14:50:02 DNT Received: from danpost.uni-c.dk by vm.uni-c.dk (IBM VM SMTP V2R1) with TCP; Tue, 07 Jul 92 14:50:02 DNT Received: from id.dth.dk by danpost.uni-c.dk (5.65/1.34) id AA25734; Tue, 7 Jul 92 14:49:40 +0200 Received: from ithil.id.dth.dk (ithil) by iddth.id.dth.dk (5.65c+/1.34) id AA19030; Tue, 7 Jul 1992 16:31:47 +0200 Received: by ithil.id.dth.dk (4.1/SMI-4.1-PB1.0) id AA15595; Tue, 7 Jul 92 14:46:28 MED Date: Tue, 7 Jul 92 14:46:28 MED From: bojsen@id.dth.dk (Per Bojsen) Message-Id: <9207071246.AA15595@ithil.id.dth.dk> To: fubinf!nqthm-users Subject: Breaking of DEFN Reply-To: bojsen@id.dth.dk I just discovered something strange in nqthm: if you break the prover in the middle of a DEFN it will still add the event to the database. I never noticed this behavior before so I thought I would ask here if it's just me or if it really is supposed to work this way. -- Per Bojsen The Design Automation Group Email: bojsen@ithil.id.dth.dk MoDAG Technical University of Denmark pb@id.dth.dk Received: by CLI.COM (4.1/1); Tue, 7 Jul 92 09:15:05 CDT Date: Tue, 7 Jul 92 09:15:05 CDT From: Robert S. Boyer Message-Id: <9207071415.AA19460@CLI.COM> To: bojsen@id.dth.dk Cc: nqthm-users@cli.com Subject: Breaking of DEFN Reply-To: boyer@cli.com The important topic of user aborts is treated in the Nqthm users manual, `A Computational Logic Handbook', Boyer and Moore, Academic Press, 1988, on p. 252, in the very first section of the `Reference Guide', 12.1 `Aborting or Interrupting Commands'. Here are some relevant passages therefrom: Warning: It is technically dangerous to abort any command that changes the data base, including the event commands such as ADD-SHELL, DEFN, and PROVE-LEMMA. Such aborts may leave the data base in an inconsistent state. The only proofs we endorse are those constructed by an uninterrupted sequence of event commands. Having thus officially disavowed the practice, let us now make a few practical remarks about the effect of aborting event commands. ... Whenever we abort a DEFN or ADD-SHELL, we do an UNDO-NAME. ... In any case, we never feel like we have completed a proof project until an uninterrupted run of the events is performed by PROVEALL. Bob Received: by CLI.COM (4.1/1); Tue, 7 Jul 92 10:53:37 CDT Date: Tue, 7 Jul 92 10:53:37 CDT From: Robert S. Boyer Message-Id: <9207071553.AA20174@CLI.COM> To: saleh@ECE.ORST.EDU Cc: nqthm-users@cli.com, bill@ora.on.ca, wfs Subject: [saleh@ECE.ORST.EDU: nqthm] Reply-To: boyer@cli.com I read in a kcl-faq that nqthm has been successfully compiled using the DOS-BETA version of AKCL. Is this correct? Are the binaries available? Bill Schelter, wfs@cli.com, is the person behind the beta release of the MS-DOS version of AKCL that is mentioned in the KCL FAQ (frequently asked questions list), i.e., the file /pub/kcl/kcl.faq available by anonymous ftp from cli.com. I have not personally yet seen AKCL, much less Nqthm, running on a PC, but have heard twice that it does, both times under the emerging GCC-for-MS-DOS, which runs a lot of C programs that were written for BSD. I suggest that you drop a note to Bill to inquire about an executable Nqthm. Bill Pase (bill@ora.on.ca) also has told me that he had Nqthm (and Eves and RRL) running on a PC under KCL and MS-DOS. I have heard surprising performance rumors, something like: a fast 486 running AKCL under MS-DOS is as fast as a Sparc 2 running AKCL (which is damn fast). But I cannot confirm this. Here is the relevant remark in the KCL FAQ. About the current state of the DOS version, Schelter (wfs@cli.com) remarks `There is a beta version of AKCL for DOS on math.utexas.edu:pub/beta2.zip. See the readme.dos in that distribution. Building from the source under DOS is not yet fully automated due to the lack of a standard make and standard shell under DOS. The 615 sources contain most patches required. The beta version has successfully compiled and run maxima, nqthm, and axiom (an 800 + file algebra system from ibm).' Received: by CLI.COM (4.1/1); Fri, 10 Jul 92 11:32:08 CDT Date: Fri, 10 Jul 92 11:35:36 CDT From: Bill Schelter Message-Id: <9207101635.AA09792@funware.CLI.COM> Received: by funware.CLI.COM (4.1/CLI-1.2) id AA09792; Fri, 10 Jul 92 11:35:36 CDT To: boyer@cli.com Cc: saleh@ECE.ORST.EDU, nqthm-users@cli.com, bill@ora.on.ca In-Reply-To: Robert S. Boyer's message of Tue, 7 Jul 92 10:53:37 CDT <9207071553.AA20174@CLI.COM> Subject: [saleh@ECE.ORST.EDU: nqthm] Reply-To: wfs@cli.com beta2.tar is the dos version of akcl. It contains an executable and the relevant gcc compiler and stuff for unpacking. Most of the changes are merged into the akcl 615 but there are still some things which make it not completely automatic to build from source under dos. Hopefully this will be corrected. I have compiled nqthm and run an nqthm proveall with it. rw-r----- 10/100 850827 Apr 17 19:41 1992 akcl608c.zip rw-rw-rw- 10/100 599538 Apr 3 09:39 1992 djgcc106.zip rw-rw-rw- 10/100 27876 Mar 25 23:31 1992 bin/unzip.exe rw-rw-rw- 10/100 2359 Apr 17 19:49 1992 akcl/readme.dos Received: by CLI.COM (4.1/1); Thu, 3 Sep 92 04:03:05 CDT Received: from UKACRL.BITNET by ib.rl.ac.uk (IBM VM SMTP V2R1) with BSMTP id 0019; Thu, 03 Sep 92 10:03:59 BST Received: from RL.IB by UKACRL.BITNET (Mailer R2.07) with BSMTP id 2993; Thu, 03 Sep 92 10:03:57 BST Received: from RL.IB by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 4698; Thu, 03 Sep 92 10:03:57 BST Via: UK.AC.ED.CASTLE; 3 SEP 92 10:03:44 BST From: D MacKenzie Subject: 'Sociology of proof' job To: nqthm-users@cli.com Organisation: Edinburgh University Telephone: 031 650 3980 (secy. on 650 4000) Date: Thu, 3 Sep 92 10:02:37 GMT Message-Id: <9209031002.aa28878@castle.ed.ac.uk> ADVANCE NOTICE OF POSSIBLE RESEARCH POST IN SOCIOLOGY OF MATHEMATICAL PROOF Donald MacKenzie (Department of Sociology, University of Edinburgh) and Alan Bundy (Artificial Intelligence, Edinburgh) expect to advertise over the next few weeks for a postdoctoral Research Fellow. The post will be on their project 'Studies in the Sociology of Proof', which is being funded by the Economic and Social Research Council. 'Sociology of proof' refers to social factors (such as, for example, disciplinary background) underpinning different notions of what kind of mathematical argument constitutes a proof. In particular, we will be examining issues raised by the use of computers in the construction of proofs. Topics to be studied include: - the debate over proofs of correctness of programs - different evaluations of the Appel/Haken proof of the four colour conjecture - possible sources of future controversy about the soundness of the product of automated theorem provers. For an example of the kind of topic we want to address, see D. MacKenzie, 'The Fangs of the VIPER', Nature, vol. 352 (8 August 1991), 467-68. As well as examination of published literature, the research will involve several dozen interviews (primarily with mathematicians and computer scientists) in Britain and the U.S. The post would require: EITHER a relevant scientific background (e.g. in mathematics, computer science, or artificial intelligence; and ideally, but not necessarily, with experience of automated theorem proving) together with: (a) an interest in the social, philosophical and even political issues that surround proof; and (b) a willingness to learn interview skills. OR a social science background (ideally, but not necessarily, in the sociology of scientific knowledge) together with the ability and willingness to come to grips with the technical material involved. It is anticipated that the job will begin on 1 November 1992 for twenty months. The first six months are intended primarily as a training period in which necessary skills can be learnt. It is expected that the appointment will be on the 1A research scale, with placement according to age and experience up to a maximum of point 9 (17,827 pounds per annum - under review). Those wishing to receive full details of the post when they become available should e-mail either D.MacKenzie@edinburgh.ac.uk or bundy@edinburgh.ac.uk. Received: by CLI.COM (4.1/1); Fri, 4 Sep 92 07:14:09 CDT Received: by ki1.chemie.fu-berlin.de (/\@@/\ Smail3.1.26.5 #26.18) id ; Fri, 4 Sep 92 14:00 MEST Received: by inf.fu-berlin.de (/\@@/\ Smail3.1.26.7) from methan.chemie.fu-berlin.de [130.133.2.81] with smtp id ; Fri, 4 Sep 92 13:59 MET DST Received: by methan.chemie.fu-berlin.de (/\@@/\ Smail3.1.25.1 #25.7) id ; Fri, 4 Sep 92 13:39 MES Received: by ki1.chemie.fu-berlin.de (/\@@/\ Smail3.1.26.5 #26.18) id ; Fri, 4 Sep 92 13:35 MEST Received: from iddth.id.dth.dk (id.dth.dk) by danpost.uni-c.dk (5.65c+/1.34) id AA02029; Fri, 4 Sep 1992 13:35:36 +0200 Received: from ithil.id.dth.dk (ithil) by iddth.id.dth.dk (5.65c+/1.34) id AA24366; Fri, 4 Sep 1992 14:10:16 +0200 Received: by ithil.id.dth.dk (4.1/SMI-4.1-PB1.0) id AA04172; Fri, 4 Sep 92 13:30:16 MED Date: Fri, 4 Sep 92 13:30:16 MED From: bojsen@id.dth.dk (Per Bojsen) Message-Id: <9209041130.AA04172@ithil.id.dth.dk> To: nqthm-users@inf.fu-berlin.de Subject: Is ADD-SHELL slow? [Repost] Reply-To: bojsen@id.dth.dk Hello! A couple of days ago I sent a note to the nqthm list but the mailer at inf.fu-bnerlin.de choked on my message. The problems there have since been fixed (I hope), so I'm now reposting my message with some added comments. Here's the original note: -------- Start of message ------------------------------------------------------ Hello! Today I started using shells in nqthm. I have no experience with the ADD-SHELL event, so I have a question: is ADD-SHELL unusually slow compared to the other events? For example, I'm trying to add the following event to history: (add-shell dfg NIL p-dfgp ((dfg-nodes (one-of falsep listp) false) (dfg-io (one-of falsep litatom listp) false) (dfg-tokens (one-of falsep listp) false))) I issued this event about 2 hours ago and nqthm is still thinking! This is on an otherwise unloaded Sun SparcStation 1+. Is something wrong with nqthm? Is this normal? The event history is nearly empty. I've only added the following event: (add-shell token NIL p-tokenp ((token-val (none-of) zero) (token-pure (one-of falsep listp) false))) This event was accepted instantly (time triple [ 0.3 0.0 0.0 ]). Are there any known problems with ADD-SHELL? Thanks in advance for any help! -------- End of original message ----------------------------------------------- After I sent this message I went on to experiment with the shell events to find a possible cause of the slowdown. It turned out that the problem was with FALSEP in the type restrictions. If I changed FALSEP to NUMBERP and FALSE to ZERO the shell was accepted in about 8 seconds or so!! I tried a few other experiments, too, like removing type recognizers from the ONE-OF lists and adding them back again one for one. The following 2 modified dfg ADD-SHELLs were accepted in less than a second: (add-shell dfg NIL p-dfgp ((dfg-nodes (one-of falsep) false) (dfg-io (one-of falsep) false) (dfg-tokens (one-of falsep) false))) ; Adding listp to the first one-of: (add-shell dfg NIL p-dfgp ((dfg-nodes (one-of falsep listp) false) (dfg-io (one-of falsep) false) (dfg-tokens (one-of falsep) false))) I then added listp to the second one-of: (add-shell dfg NIL p-dfgp ((dfg-nodes (one-of falsep listp) false) (dfg-io (one-of falsep listp) false) (dfg-tokens (one-of falsep) false))) and the shell was accepted in about 13 seconds. I added listp to the last one-of list: (add-shell dfg NIL p-dfgp ((dfg-nodes (one-of falsep listp) false) (dfg-io (one-of falsep listp) false) (dfg-tokens (one-of falsep listp) false))) but I didn't wait for this shell to get accepted (I waited a few minutes before breaking). But when I changed FALSEP to NUMBERP and FALSE to ZERO the shells get accepted quickly. Debora Weber-Wulff suggested that ONE-OF is a bad idea in ADD-SHELL: > One bit from my as-yet-unpublished lore collection: one-of is a bad > idea in ADD-SHELL! ADD-SHELL is not an ADT, even if it looks like > it. For each element in a one-of list you double the number of > something. I had one once with 16 one-ofs in one arm and 4 in > another. It took about a half an hour to be accepted, and you > couldn't prove anything about it, it took too long. Bill Bevier > suggested puttint (none-of) everywhere and defining a proper-tokenp, > for example, that checks each element to see if it's okay (i.e. > p-tokenp and (or (falsep (token-pure tok)(listp token-pure tok)). I would like to hear what those in the know have to say about this! :-) Thanks! -- Per Bojsen The Design Automation Group Email: bojsen@ithil.id.dth.dk MoDAG Technical University of Denmark pb@id.dth.dk Received: by CLI.COM (4.1/1); Mon, 7 Sep 92 12:37:50 CDT Date: Mon, 7 Sep 92 12:38:16 CDT From: Matt Kaufmann Message-Id: <9209071738.AA00577@thunder.CLI.COM> Received: by thunder.CLI.COM (4.1/CLI-1.2) id AA00577; Mon, 7 Sep 92 12:38:16 CDT To: bojsen@id.dth.dk Cc: nqthm-users@CLI.COM In-Reply-To: Per Bojsen's message of Fri, 4 Sep 92 13:30:16 MED <9209041130.AA04172@ithil.id.dth.dk> Subject: Is ADD-SHELL slow? [Repost] Regarding your question: >> Today I started using shells in nqthm. I have no experience with the >> ADD-SHELL event, so I have a question: is ADD-SHELL unusually slow >> compared to the other events? For example, I'm trying to add the >> following event to history: >> >> (add-shell dfg NIL p-dfgp ((dfg-nodes (one-of falsep listp) false) >> (dfg-io (one-of falsep litatom listp) false) >> (dfg-tokens (one-of falsep listp) false))) >> >> I issued this event about 2 hours ago and nqthm is still thinking! >> This is on an otherwise unloaded Sun SparcStation 1+. Is something >> wrong with nqthm? Is this normal? Thanks for your message. You have helped me identify a part of the serious problem in ADD-SHELL's performance in the presence of nontrivial type-restrictions. We've identified a simple fix that applies to the example you sent, which could be incorporated into a subsequent release of Nqthm. (I'd be happy to send it to you, though at this point it's completely unofficial.) As a practical matter, however, we will continue to recommend against using type-restrictions other than (NONE-OF) in ADD-SHELL forms, for performance reasons (as you noted by way of Debbie Weber-Wulff, by way of Bill Bevier). I'll elaborate a little, for those who care to read on..... I think there are two reasons why the above ADD-SHELL form was taking so long. The first (and general) reason is one you've already brought up towards the end of your note, by way of Debbie Weber-Wulff, by way of Bill Bevier: Having type restrictions in your ADD-SHELL forms is dangerous. Actually, it can cause some combinatorial explosions in the processing of some rewrite rules added by ADD-SHELL. I think that many experienced Nqthm users either avoid shells, or else use them with no type restrictions, i.e. using (NONE-OF) [no arguments to this form]. You can always write definitions of predicates that describe the ``good'' members of this shell type. In your particular example, though, there was something else going on with the prover. Apparently the combination of non-trivial type restrictions together with using FALSE as a bottom object (though TRUE would be just as bad) causes an unnecessary call to Nqthm's clausifier. If anyone is interested I can send technical details. The Nqthm code is pretty complicated (in order to obtain as much automation as there is), and perhaps we should be surprised that this kind of thing doesn't happen more often. Again, I suggest avoiding the use of ONE-OF, or at least trying to keep the number of types listed after it as small as possible. If you want the gory details about what happened here with FALSE, let me know. If you want an unofficial fix for the problem, I'd be happy to send it. -- Matt Kaufmann Received: by CLI.COM (4.1/1); Mon, 7 Sep 92 13:24:14 CDT Received: by ki1.chemie.fu-berlin.de (/\@@/\ Smail3.1.26.5 #26.18) id ; Mon, 7 Sep 92 20:09 MEST Received: by inf.fu-berlin.de (/\@@/\ Smail3.1.26.7) from methan.chemie.fu-berlin.de [130.133.2.81] with smtp id ; Mon, 7 Sep 92 20:09 MET DST Received: by methan.chemie.fu-berlin.de (/\@@/\ Smail3.1.26.7) from ki1.chemie.fu-berlin.de with uucp id ; Mon, 7 Sep 92 20:09 MES Received: by ki1.chemie.fu-berlin.de (/\@@/\ Smail3.1.26.5 #26.18) id ; Mon, 7 Sep 92 20:08 MEST Received: from iddth.id.dth.dk (id.dth.dk) by danpost.uni-c.dk (5.65c+/1.34) id AA02179; Mon, 7 Sep 1992 20:08:31 +0200 Received: from ithil.id.dth.dk (ithil) by iddth.id.dth.dk (5.65c+/1.34) id AA23313; Mon, 7 Sep 1992 20:07:06 +0200 Received: by ithil.id.dth.dk (4.1/SMI-4.1-PB1.0) id AA08045; Mon, 7 Sep 92 20:02:45 MED Date: Mon, 7 Sep 92 20:02:45 MED From: bojsen@id.dth.dk (Per Bojsen) Message-Id: <9209071802.AA08045@ithil.id.dth.dk> To: kaufmann@CLI.COM Cc: nqthm-users@inf.fu-berlin.de In-Reply-To: Matt Kaufmann's message of Mon, 7 Sep 92 12:38:16 CDT <9209071738.AA00577@thunder.CLI.COM> Subject: Is ADD-SHELL slow? [Repost] Reply-To: bojsen@id.dth.dk > I think there are two reasons why the above ADD-SHELL form was > taking so long. The first (and general) reason is one you've > already brought up towards the end of your note, by way of Debbie > Weber-Wulff, by way of Bill Bevier: Having type restrictions in your > ADD-SHELL forms is dangerous. Actually, it can cause some > combinatorial explosions in the processing of some rewrite rules > added by ADD-SHELL. I think that many experienced Nqthm users > either avoid shells, or else use them with no type restrictions, > i.e. using (NONE-OF) [no arguments to this form]. You can always > write definitions of predicates that describe the ``good'' members > of this shell type. Thanks for your answer! I've now changed my ADD-SHELL forms to use (NONE-OF) exclusively. Since I already needed predicates describing `good' members of the shell types this change turned out to be free. And performance is much better. -- Per Bojsen The Design Automation Group Email: bojsen@ithil.id.dth.dk MoDAG Technical University of Denmark pb@id.dth.dk Received: by CLI.COM (4.1/1); Wed, 16 Sep 92 06:34:21 CDT Received: from UKACRL.BITNET by ib.rl.ac.uk (IBM VM SMTP V2R1) with BSMTP id 0841; Wed, 16 Sep 92 12:34:49 BST Received: from RL.IB by UKACRL.BITNET (Mailer R2.07) with BSMTP id 5848; Wed, 16 Sep 92 12:34:48 BST Received: from RL.IB by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 5277; Wed, 16 Sep 92 12:34:48 BST Via: UK.AC.ED.CASTLE; 16 SEP 92 12:34:33 BST From: D MacKenzie Subject: Post in 'Sociology of Proof' To: nqthm-users@cli.com Organisation: Edinburgh University Telephone: 031 650 3980 (secy. on 650 4000) Date: Wed, 16 Sep 92 12:33:30 GMT Message-Id: <9209161233.aa10578@castle.ed.ac.uk> University of Edinburgh Departments of Sociology and Artificial Intelligence Research Fellow in the Sociology of Mathematical Proof Applications are invited for a post of research fellow, working with Donald MacKenzie (Sociology) and Alan Bundy (Artificial Intelligence) on an ESRC-funded project investigating sources of social variation in what kinds of argument count for whom, under what circumstances, as mathematical proofs. The project will focus on disputes over the acceptability of proofs produced by computers, particularly where such proofs are of the correctness of the design of computer systems critical to human safety. The research will involve examining technical literature and interviewing mathematicians and computer scientists in Britain and the U.S. A PhD (or equivalent research experience) in a relevant area (such as mathematics, computer science, artificial intelligence or sociology of science) is required. The appointment will begin on 1 December 1992 (or as soon after that as possible) for twenty months. Salary will be on the 1A research scale, normally no higher than point 4 (14,359 pounds; under review). Two copies of applications, including a c.v. and the names of two referees, and quoting ref. no. 920266 should be sent to the Personnel Office, University of Edinburgh, 1 Roxburgh Street, Edinburgh EH8 9TB, from whom further particulars can be obtained. (An e-mail copy of further particulars can be obtained from D.MacKenzie@edinburgh.ac.uk) Overseas applicants need send only one copy of their applications, and if necessary can send them by fax (44-31-650 6509). The closing date is 12 October 1992, and interviews are planned for 26 October. Received: by CLI.COM (4.1/1); Tue, 22 Sep 92 13:03:15 CDT Date: Tue, 22 Sep 92 13:03:15 CDT From: Robert S. Boyer Message-Id: <9209221803.AA02171@CLI.COM> To: nqthm-users@cli.com Subject: LICS Reply-To: boyer@cli.com Eight Annual IEEE Symposium on LOGIC IN COMPUTER SCIENCE June 20-23, 1993, Montreal, Quebec (Canada) CALL FOR PAPERS The LICS Symposium aims for wide coverage of theoretical and practical issues in computer science that relate to logic in a broad sense, including algebraic, categorical and topological approaches. Suggested, but not exclusive, topics of interest include: abstract data types, automated deduction, concurrency, constructive mathematics, data base theory, finite-model theory, knowledge representation, lambda and combinatory calculi, logical aspects of computational complexity, logics in artificial intelligence, logic programming, modal and temporal logics, program logic and semantics, rewrite rules, logical aspects of symbolic computing, problem solving environments, software specification, type systems, verification. PROGRAM CHAIR: Moshe Y. Vardi IBM Research Almaden Research Center, K53-802 650 Harry Rd. San Jose, CA 95120-6099, USA vardi@almaden.ibm.com, vardi@almaden.bitnet Phone: (408) 927-1784 Fax: (408) 927-2100 PROGRAM COMMITTEE: M. Abadi (DEC SRC), S. Abramsky (Imperial Coll.), B. Bloom (Cornell), P. Clote (Boston Coll.), P.J. Freyd (Univ. of Pennsylvania), D. Harel (Weizmann Inst.), K.G. Larsen (Aalborg Univ.), P. Lescanne (CRIN and INRIA-Lorraine), D. McAllester (MIT), J. Meseguer (SRI), D. Miller (Univ. of Pennsylvania), Y. Moschovakis (UCLA), N. Shankar (SRI), C. Talcott (Stanford), M.Y. Vardi (IBM Almaden), and P. Wolper (Univ. of Liege). LICS GENERAL CHAIR: Robert Constable Department of Computer Science Cornell University Ithaca, NY 14253 rc@cs.cornell.edu CONFERENCE CO-CHAIRS: Mitsu Okada Prakash Panangaden Department of Computer Science School of Computer Science Concordia University McGill University Montreal Montreal H3G 1M8 Quebec, Canada H3A 2A7 Quebec, Canada okada@concour.cs.concordia.ca prakash@cs.mcgill.ca PAPER SUBMISSION: 10 hard copies of a detailed abstract (not a full paper) and 20 additional copies of the cover page should be RECEIVED by DECEMBER 8, 1992 by the PROGRAM CHAIR (Attn: LICS). Authors without access to reproduction facilities may submit a single copy of their submission. Authors will be notified of acceptance by February 14, 1992. Accepted papers in the specified format for the symposium proceedings will be due April 6, 1993. The cover page of the submission should include the title, authors, a brief synopsis, and the corresponding author's name, address, phone number, fax number, and e-mail address if available. Abstracts must be in English, clearly written, and provide sufficient detail to allow the program committee to assess the merits of the paper. References and comparisons with related work should be included. It is recommended that each submission begin with a succinct statement of the problem, a summary of the main results, and a brief explanation of their significance and relevance to the conference, all suitable for the non-specialist. Technical development of the work, directed to the specialist, should follow. Abstracts of fewer than 1500 words are rarely adequate, but the total abstract, should not be longer than 10 typed pages with roughly 35 lines per page. If the authors believe that more details are essential to substantiate the main claims of the paper, they may include a clearly marked appendix to be read at the discretion of the committee. Late abstracts, or those departing significantly from these guidelines, run a high risk of rejection. The results in the submission must be unpublished and not submitted for publication elsewhere, including proceedings of other symposia or workshops. All authors of accepted papers will be expected to sign copyright release forms, and one author of each accepted paper will be expected to present the paper at the conference. The symposium is sponsored by the IEEE Technical Committee on Mathematical Foundations of Computing in cooperation with the Association for Symbolic Logic and the European Association of Theoretical Computer Science. Cooperation with the ACM is anticipated. ORGANIZING COMMITTEE: M. Abadi, S. Abramsky, S. Artemov, J. Barwise, M. Blum, A. Bundy, S. Buss, E. Clarke, R. Constable (Chair), E. Engeler, J. Gallier, U. Goltz, Y. Gurevich, S. Hayashi, G. Huet, G. Kahn, D. Kapur, C. Kirchner, R. Kosaraju, J. W. Klop, P. Kolaitis, D. Leivant, A. Meyer, G. Mints, J. Mitchell, Y. Moschovakis, A. Pitts, G. Plotkin, S. Ronchi Della Rocca, G. Rozenberg, A. Scedrov, D. Scott, J. Tiuryn, M. Vardi, R. de Vrijer PUBLICITY CHAIR: Daniel Leivant Department of Computer Science Indiana University Bloomington, IN 47405, USA lics@cs.indiana.edu Received: by CLI.COM (4.1/1); Thu, 24 Sep 92 14:33:22 CDT Received: by ki1.chemie.fu-berlin.de (/\==/\ Smail3.1.28.1) from inf.fu-berlin.de (130.133.11.1) with smtp id ; Thu, 24 Sep 92 18:36 MEST Received: by inf.fu-berlin.de (/\@@/\ Smail3.1.26.7) from inf.fu-berlin.de [130.133.11.50] with smtp id ; Thu, 24 Sep 92 18:36 MET DST Received: by inf.fu-berlin.de (/\@@/\ Smail3.1.26.7) id ; Thu, 24 Sep 92 18:38 MET DST Message-Id: Date: Thu, 24 Sep 92 18:38 MET DST From: weberwu@inf.fu-berlin.de (Debora Weber-Wulff) To: nqthm-users@inf.fu-berlin.de Subject: Design choice: BUTLAST or (CDR (REVERSE..)) I'm at one of those "decision points" again, where I'd like to explore both methods of implementing my functions, or rather try one out and if I get stuck "automagically" transforming everything to the other implementation method and see if that can continue, or just choose the "right" way to begin with. The problem: working with right derivations of a word in a language, I often have to fiddle with the right part of the word represented as a list of symbols. It is more natural to me to write (DEFN FOO (WORD) (.... (LAST WORD) .... (FOO (BUTLAST WORD)))). Of course, I could write (DEFN FOO (WORD) (... (CAR (REVERSE WORD)) ... (FOO (CDR (REVERSE WORD))))). Or does it not matter? Do I just need to write the functions like (DEFN LAST (WORD) (IF (NLISTP WORD) WORD (CAR (REVERSE WORD)))) and prove some stuff like (EQUAL (APPEND (BUTLAST WORD) (LAST WORD)) WORD) for NQTHM to be able to prove anything useful about foo? Any experienced users care to comment? Thanks! Debora Weber-Wulff dww@inf.fu-berlin.de Institut fuer Informatik +49 30 89691 124 Nestorstr. 8-9 (INCLUDE "standard.disclaimer") D-W-1000 Berlin 31 (PRINTN (WITTY-MESSAGE TODAY)) Received: by CLI.COM (4.1/1); Sun, 4 Oct 92 20:04:03 CDT Received: by mcs213k.cs.umr.edu (5.61/1.34) id AA21596; Sun, 4 Oct 92 19:46:20 -0500 Date: Sun, 4 Oct 92 19:46:20 -0500 From: martinas@cs.umr.edu (Martina Schollmeyer) Message-Id: <9210050046.AA21596@mcs213k.cs.umr.edu> To: nqthm-users@cli.com Subject: verification of concurrent programs using nqthm Cc: martinas@cs.umr.edu I'm currently working in the area of fault-tolerant algorithms for distributed computing. We would like to prove certain properties about the fault tolerance of our algorithms using a theorem prover. Has anyone done work in the area of mechanically verifying concurrent programs ? Are there sample programs available that I could "play" with ? Thanks for your help, Martina ------------------------------------------------------------------------------- Martina Schollmeyer | "Smile, it makes people wonder what you University of Missouri-Rolla | are thinking... " | martinas@cs.umr.edu | ------------------------------------------------------------------------------- Received: by CLI.COM (4.1/1); Sun, 4 Oct 92 20:41:12 CDT Date: Sun, 4 Oct 92 20:41:12 CDT From: David Goldschlag Message-Id: <9210050141.AA09334@CLI.COM> To: martinas@cs.umr.edu Cc: nqthm-users@cli.com, martinas@cs.umr.edu, russ@cli.com, young@cli.com, bevier@cli.com Subject: verification of concurrent programs using nqthm I have developed an Nqthm based proof system for a logic for concurrent programs similar to Chandy and Misra's Unity logic, and have mechanically verified the correctness of several simple parameterized concurrent programs. I can send you documentation, if you'd like. In addition, David Russinoff (russ@cli.com) has developed an Nqthm based proof system for a subset of Manna and Pnueli's temporal logic. He has verified the correctness of several algorithms, including Ben-Ari's garbage collection algorithm. Both of these systems can be used to reason about asynchronous computations. Bill Young (young@cli.com) and Bill Bevier (bevier@cli.com) have mechanically verified the correctness of Lamport, Pease, and Schostak's solution to the Byzantine General's problem. This is a complex concurrent program, using a synchronous model of computation. David Goldschlag National Security Agency Attn: R232 Fort George G. Meade, Maryland 20755-6000 Voice: (301) 688-0851 e-mail: goldschlag@tycho.ncsc.mil Received: by CLI.COM (4.1/1); Tue, 24 Nov 92 09:24:49 CST Date: Tue, 24 Nov 92 09:25:32 CST From: Robert S. Boyer Message-Id: <9211241525.AA04162@funware.CLI.COM> Received: by funware.CLI.COM (4.1/CLI-1.2) id AA04162; Tue, 24 Nov 92 09:25:32 CST To: nqthm-users@cli.com Subject: [bundy@aisb.edinburgh.ac.uk: Conference Announcement: CADE-12] Reply-To: boyer@cli.com Date: Tue, 24 Nov 92 10:34:07 GMT From: Alan Bundy Subject: Conference Announcement: CADE-12 To: theorem-provers@aisb.edinburgh.ac.uk, wos@aisb.edinburgh.ac.uk, mind@aisb.edinburgh.ac.uk, indus@aisb.edinburgh.ac.uk, aichi@aisb.edinburgh.ac.uk, aicom@aisb.edinburgh.ac.uk, ikbs@aisb.edinburgh.ac.uk, aisb@aisb.edinburgh.ac.uk, arpanet-bboards@aisb.edinburgh.ac.uk, comp-ai@aisb.edinburgh.ac.uk, germany@aisb.edinburgh.ac.uk, internet@aisb.edinburgh.ac.uk, irlist@aisb.edinburgh.ac.uk, japan@aisb.edinburgh.ac.uk, aicom@aisb.edinburgh.ac.uk, aijournal@aisb.edinburgh.ac.uk, aimagazine@aisb.edinburgh.ac.uk, aisb@aisb.edinburgh.ac.uk, cscsi@aisb.edinburgh.ac.uk, sigart@aisb.edinburgh.ac.uk Phone: 44-31-650-2716 Fax: 44-31-650-6516 Please post/circulate CADE-12 The Twelfth International Conference on Automated Deduction Nancy, France June 28 -- July 1, 1994 PRELIMINARY ANNOUNCEMENT The CADE conferences are the major forum for the presentation of new research in all aspects of automated deduction. We are pleased to announce that CADE-12 will be held in Nancy, France from June 28 -- July 1, 1994. CADE-12 will include contributed and invited talks, tutorials, workshops, demonstrations of automated deduction systems and presentations of challenge problem sets. Following CADE-12 the LICS-94 conference will be held in Paris, France from July 4-7, 1994. A sight-seeing trip of France will link the two conferences. Further details of CADE-12 will be available in subsequent mailings. In the meantime enquiries can be directed at: Program Chair: Alan Bundy Department of Artificial Intelligence, University of Edinburgh, 80 South Bridge, Edinburgh, EH1 1HN, Scotland Fax: 44-31-650-6516 Tel: 44-31-650-2716 E-mail: bundy@ed.ac.uk Local Arrangements Chair: Claude Kirchner INRIA Lorraine & CRIN Campus scientifique 615, rue du Jardin Botanique BP101 54602 Villers-les-Nancy CEDEX FRANCE Tel: (33) 83 59 30 11 Secretary: (33) 83 59 30 09 Fax: (33) 83 27 83 19 E-mail: Claude.Kirchner@loria.fr Received: by CLI.COM (4.1/1); Tue, 12 Jan 93 06:12:42 CST Received: from fulmar.cl.cam.ac.uk (user mn (rfc931)) by swan.cl.cam.ac.uk with SMTP (PP-6.4) to cl; Tue, 12 Jan 1993 12:12:13 +0000 To: nqthm-users@cli.com Cc: Monica.Nesi@cl.cam.ac.uk Subject: Boyer-Moore Theorem Prover and Process Algebras Date: Tue, 12 Jan 93 12:12:07 +0000 From: Monica Nesi Message-Id: <"swan.cl.ca.643:12.01.93.12.12.22"@cl.cam.ac.uk> Hi, I am interested in the verification of process algebra specifications using theorem provers. I would be very pleased to know if any work has been done about process algebra verification in the Boyer-Moore theorem prover. The only work I know of is the following: Aujla, S.S. and M. Fletcher, `The Boyer-Moore Theorem Prover and LOTOS', in Formal Description Techniques, Proceedings of FORTE'88, K.J. Turner (ed.), North-Holland, 1989. Does anyone know of any other work? Thank you in advance. Regards, Monica Received: by CLI.COM (4.1/1); Tue, 23 Mar 93 01:58:40 CST Received: by hutch.loria.fr id AA08629 (5.65c+/IDA-1.4.3 for nqthm-users@cli.com); Tue, 23 Mar 93 09:02:07 +0100 From: Najjar Faiza Message-Id: <9303230802.AA08629@hutch.loria.fr> Subject: help for nqthm To: nqthm-users@cli.com Date: Tue, 23 Mar 1993 09:02:06 +0100 (MET) Cc: najjar@hutch.loria.fr (Najjar Faiza) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 836 I'm Najjar faiza a student in Loria Lorraine, I'm beginner in using Boyer-Moore 's prover nqthm, I have a problem about the formulation of some digital circuits to be treated by nqthm system. I have tried to formulate a regular repetitive structure like a counter mod n in naturel language like this: q(i,0) --> init(i) q(i,t+1) --> q(i,t) + c(i,t) c(0,t) --> x(t) c(i+1,t) --> c(i,t). q(i,t) The problem was the doubled-breasted recursion and the initialisation. can you help me: how to formulate some digital circuits in recursive function to be then successfully proved by the prover, and what is the documentation about errors in nqthm. thank you very much with best regards Faiza Received: by CLI.COM (4.1/1); Tue, 23 Mar 93 09:48:41 CST Date: Tue, 23 Mar 93 09:52:39 CST From: Bill Young Message-Id: <9303231552.AA03753@felix.CLI.COM> Received: by felix.CLI.COM (4.1/CLI-1.2) id AA03753; Tue, 23 Mar 93 09:52:39 CST To: Faiza.Najjar@loria.fr Cc: nqthm-users@CLI.COM, young@CLI.COM In-Reply-To: Najjar Faiza's message of Tue, 23 Mar 1993 09:02:06 +0100 (MET) <9303230802.AA08629@hutch.loria.fr> Subject: help for nqthm The problem of defining mutually recursive functions in Nqthm arises frequently. It is often handled by defining a single function that covers both cases and using a flag argument to distinguish which case is being handled. For example, your functions: q(i,0) --> init(i) q(i,t+1) --> q(i,t) + c(i,t) c(0,t) --> x(t) c(i+1,t) --> c(i,t). q(i,t) can be coded as follows (assuming the subsidiary functions init and x have been defined. (defn q-c (flg x y) ;; Defines both q and c, in a mutually ;; recursive fashion. (if (equal flg 'q) (if (zerop y) (init x) (plus (q-c 'q x (sub1 y)) (q-c 'c x (sub1 y)))) (if (zerop x) (x y) (times (q-c 'q (sub1 x) y) (q-c 'c (sub1 x) y))))) ;; Now we define each individually. (defn q (x y) (q-c 'q x y)) (defn c (x y) (q-c 'c x y)) There has been a significant amount of research at CLI and elsewhere regarding the modeling of digital circuits in Nqthm. If you'd like, I'll send you a selected bibliography on this subject. I'm not too sure what you mean by "errors in Nqthm." Do you mean, run-time error handling, bugs in the implementation, or something else? --Bill Young Received: by CLI.COM (4.1/1); Tue, 23 Mar 93 10:14:38 CST Date: Tue, 23 Mar 93 10:18:37 CST From: Bill Young Message-Id: <9303231618.AA03756@felix.CLI.COM> Received: by felix.CLI.COM (4.1/CLI-1.2) id AA03756; Tue, 23 Mar 93 10:18:37 CST To: Faiza.Najjar@loria.fr Cc: nqthm-users@CLI.COM, young@CLI.COM So as not to confuse you, the definition I gave you needs a hint (the lessp at the bottom) to allow the prover to determine that the recursion terminates. [Notice that I also changed to order of the arguments to the times to match your definition.] (defn q-c (flg x y) (if (equal flg 'q) (if (zerop y) (init x) (plus (q-c 'q x (sub1 y)) (q-c 'c x (sub1 y)))) (if (zerop x) (x y) (times (q-c 'c (sub1 x) y) (q-c 'q (sub1 x) y)))) ((lessp (plus x y)))) Given this definition, the function definitions you gave q(i,0) --> init(i) q(i,t+1) --> q(i,t) + c(i,t) c(0,t) --> x(t) c(i+1,t) --> c(i,t). q(i,t) can now be coded as rewrite rules that will follow from the definition. Namely, (prove-lemma q-expander (rewrite) (and (implies (zerop y) (equal (q x y) (init x))) (equal (q x (add1 y)) (plus (q x (fix y)) (c x (fix y)))))) (prove-lemma c-expander (rewrite) (and (implies (zerop x) (equal (c x y) (x y))) (equal (c (add1 x) y) (times (c (fix x) y) (q (fix x) y))))) (disable q) (disable c) [Notice that the (fix x) and (fix y) are needed, because we don't insist that the arguments are numberp's.] Now if we disable c and q, we gain all of the benefits of your definitions in subsequent proofs. --Bill Young Received: by CLI.COM (4.1/1); Tue, 23 Mar 93 11:03:54 CST Date: Tue, 23 Mar 93 11:07:28 CST From: J Strother Moore Message-Id: <9303231707.AA09962@rana.CLI.COM> Received: by rana.CLI.COM (4.1/CLI-1.2) id AA09962; Tue, 23 Mar 93 11:07:28 CST To: Faiza.Najjar@loria.fr Cc: nqthm-users@cli.com, najjar@hutch.loria.fr In-Reply-To: Najjar Faiza's message of Tue, 23 Mar 1993 09:02:06 +0100 (MET) <9303230802.AA08629@hutch.loria.fr> Subject: help for nqthm Hello. The problem of "mutual recursion" in Nqthm is described in A Computational Logic Handbook (chapter 3, on formalization). If you do not have this book you should definitely buy it and read it before proceeding. There you will find that the way mutually recursive definitions are admitted is to transform them into singly recursive functions that employ a "flag" to encode which of the two functions is being defined. I will use your "counter mod n" description to illustrate this below. However, I do not really understand your "counter mod n" description so I cannot offer you an Nqthm expression of it with any confidence. In particular, what does "c(i,t). q(i,t)" mean? Perhaps (times (c i t) (q i t))? Anyway, here is a mutually recursive function, qc. When its first argument is t then it computes your q. When its first argument is f, it computes your c. The termination argument for mutually recursive functions is often subtle because one must give a measure that decreases in every call of any of the functions in the mutually recursive clique. Often the measure expression is a function of the flag indicating which function is calling which. In your case, the admission is simple: the sum of the arguments is always decreasing. A more common case is for the lexicographic combination of the arguments to decrease. That is the measure I use below. (dcl init (i)) (dcl x (j)) (defn qc (flg i j) (if flg ; flg=t means compute (q i j) (if (zerop j) (init i) (plus (qc t i (sub1 j)) ; (q i j-1) (qc f i (sub1 j)))) ; (c i j-1) ; flg=f means compute (c i j) (if (zerop i) (x j) (times (qc f (sub1 i) j) ; (c i-1 j) (qc t (sub1 i) j)))) ; (q i-1 j) ((ord-lessp (cons (add1 i) (fix j))))) Because init and x are undefined, it is impossible to execute this function to play with it. You ask me to help you formulate some digital circuits. I will be happy to answer more specific questions. I also recommend that you look at the work of Hunt. You should perhaps get @article(sys-ver, author="W.R. Bevier and W.A. Hunt and J S. Moore and W.D. Young", title="Special Issue on System Verification", journal="Journal of Automated Reasoning", volume="5", number="4", year="1989", pages="409-530") to see how Hunt describes circuits in the logic. There are many more recent papers. I recommend that if you are serious about using Nqthm to describe circuits you ask hunt@cli.com for the relevant papers. As for the Nqthm error messages, I thought they were too verbose as they stand! I cannot explain them all to you but if you send me one you don't understand, I'll be happy to explain it. I highly recommend that you read the Handbook thoroughly. J Received: by CLI.COM (4.1/1); Mon, 26 Apr 93 10:06:58 CDT Message-Id: <9304261506.AA20675@CLI.COM> Received: from mail-client (cogito.cs.jhu.edu) by blaze.cs.jhu.edu; Mon, 26 Apr 93 11:12:53 EDT Date: Mon, 26 Apr 93 11:12:26 EDT From: bright@blaze.cs.jhu.edu Sender: bright@blaze.cs.jhu.edu To: nqthm-users@cli.com Hello all. I have a question about a general approach for proving properties of programs. I have a program P which has the following property: (implies (permutation list1 list2) (equal (P list1) (P list2))) But it would appear that this is difficult to prove, and that the following approach would be better. (defn swap-p (L1 L2) (if (or (nlistp L1) (nlistp l2)) (equal L1 L2) (if (equal (car L1) (car L2)) (swap-p (cdr L1) (cdr L2)) (and (listp (cdr L1)) (listp (cdr L2)) (equal (car L1) (cadr L2)) (equal (car L2) (cadr L1)) (equal (cddr L1) (cddr L2)) )))) ) (prove-lemma P-invariant-swap-lemma (rewrite) (implies (swap-p L1 L2) (equal (P L1) (P L2)) ) ) What is needed is some type of ``meta lemma'' stating that if a property holds under swaps, it holds under permutations. I'm currently trying to prove it for the specific program P that I'm interested in. It was suggested that one way to prove this would be to define a "bubble sort" type of procedure that transforms L1 into L2, and use that as an induction hint. This is the approach I'm currently taking. However, I'm curious if people have done this before and if so if I could get the event file. Thanks very much, Jon Bright Received: by CLI.COM (4.1/1); Tue, 25 May 93 16:32:51 CDT Received: by crl.dec.com; id AA00990; Tue, 25 May 93 17:32:54 -0400 Received: by easynet.crl.dec.com; id AA28947; Tue, 25 May 93 17:32:35 -0400 Message-Id: <9305252132.AA28947@easynet.crl.dec.com> Received: from ricks.enet; by crl.enet; Tue, 25 May 93 17:32:53 EDT Date: Tue, 25 May 93 17:32:53 EDT From: "Tim Leonard, DTN 225-5809, HLO2-3/C11" To: info-hol@ted.cs.uidaho.edu, nqthm-users@cli.com, theorem-provers@mc.lcs.mit.edu, rewriting-list@hutch.loria.fr, larch-interest@src.dec.com Cc: leonard@ricks.enet.dec.com Apparently-To: larch-interest@src.dec.com, rewriting-list@hutch.loria.fr, theorem-provers@mc.lcs.mit.edu, nqthm-users@cli.com, info-hol@ted.cs.uidaho.edu Subject: Formal verification of Alpha AXP at Digital JOB OPENINGS --- FORMAL VERIFICATION OF ALPHA I'm leader of an advanced-development project to apply formal verification to Digital's Alpha AXP (TM) chips. We currently have job openings in Hudson, Massachusetts, in the Semiconductor Engineering Group. If you'd like a job extending formal verification technology and applying it to verify real-world processors, I'm the person to talk to. I'm interested both in people just finishing college and in people who have been working for some time. Here's what I'm looking for: REQUIREMENTS: o Demonstrated ability to describe (digital) systems and their required behaviors in a formal logic, and to use formal-verification tools to prove that the specified systems meet their specs o Demonstrated ability to learn rapidly, and to apply the learning to become very productive o Current or imminent legal permission to work in the US o Interest in working in Hudson, Massachusetts, starting sometime in the next 6 months ADDITIONAL STRENGTHS THAT COULD BE A BIG HELP: o Understanding of RISC CPU design structures (caches, buses, etc), or logic synthesis, or CPU modeling, or traditional design-verification methods, or interactive theorem proving (with nqthm or HOL, for example) o Experience clarifying a vague task, organizing and scheduling the work, and bringing a complex and long-term project to a successful completion o Experience at project leadership o Experience structuring, writing, and maintaining large specs or proofs o Enthusiasm for extending academic methods to handle industrial constraints WHAT TO DO: If such jobs sound appealing, and you meet the requirements, I'd very much like to talk to you. Please send me a note at: Leonard@ricks.enet.dec.com Remember that you *must* tell me whether you are legally permitted to work in the US. Tim Leonard Semiconductor Engineering Group Digital Equipment Corporation (P.S. That's my professional side. Personally, my feelings are: Digital, a seriously big company, has taken a hard look at where to invest crucial resources, and has decided to make formal verification in industry real. This is GREAT --- now let's do it!) Received: by CLI.COM (4.1/1); Thu, 3 Jun 93 15:10:02 CDT Message-Id: <9306032010.AA00622@CLI.COM> Received: from mail-client (cogito.cs.jhu.edu) by blaze.cs.jhu.edu; Thu, 3 Jun 93 16:09:28 EDT Date: Thu, 3 Jun 93 16:08:24 EDT From: bright@blaze.cs.jhu.edu Sender: bright@blaze.cs.jhu.edu To: nqthm-users-fab@cli.com Hello everyone. First, I don't ever remember getting any mail from this list, so if I'm not on it could somebody add me? But anyway. Recently, using the ``constrain'' and ``functionally-instantiate'' features of nqthm, I wrote an events file which can ease proofs that programs are invariant under permutations. To prove the lemma (implies (perm L1 L2) (equal (someprogram X L1) (someprogram X L2) )) One instead proves that (implies (swap-p L1 L2) (equal (someprogram X L1) (someprogram X L2) )) where swap-p is a function that returns true if L1 can be converted to L2 by swapping two adjacent elements. I'm curious if anyone has ever had the need to prove a program invariant under permutations, and if so how they approached the proof and how much work it took. I would like to determine if the approach I took could actually save somebody work. Thanks very much, Jon Bright Received: by CLI.COM (4.1/1); Tue, 29 Jun 93 10:24:55 CDT Message-Id: <9306291524.AA09914@CLI.COM> Received: from ira.uka.de by iraun1.ira.uka.de with SMTP (PP) id <05377-0@iraun1.ira.uka.de>; Tue, 29 Jun 1993 17:27:14 +0200 Date: Tue, 29 Jun 93 17:28:53 MET DST From: "Thomas Kropf, Univ. Karlsruhe" To: info-hol@ted.cs.uidaho.edu, nqthm-users@cli.com Subject: CFP: Theorem Provers in Circuit Design A Postscript version of the call can be found at the end of this post. +-------------------------------------------------------+ | | | CALL FOR PAPERS | | | | Second International Conference on | | | | THEOREM PROVERS IN CIRCUIT DESIGN: | | Theory, Practice and Experience | | | | Bad Herrenalb (Blackforest), Germany | | 26. - 29. September 1994 | | | | In cooperation with IFIP WG 10.2 | | | +-------------------------------------------------------+ FOCUS AND OBJECTIVES ==================== The use of formal methods in the design of digital systems is steadily gaining popularity. The practicability of such techniques, however, depends on the support of appropriate mechanized verification tools. This conference is a sequel to the one held at Nijmegen in June 1992, and provides a forum for discussing the role of theorem provers in the design of digital systems. The objective is to cover all relevant aspects of work in the field i.e., verification, synthesis and testing, including original research as well as case studies and other practical experiments with new or established theorem proving tools, including tautology and model checkers. The primary focus will be on the ways in which formal methods can be incorporated into hardware design tools and hardware design methodologies, rather than the theory underlying the theorem provers. Topics of interest include the philosophy behind the incorporation of formal techniques in design tools, hardware specification languages, the design and development and evaluation of formally-based tools, and the integration of formally based design and verification with existing tools and methodologies. The intended audience includes workers in the field of hardware verification as well as practising digital designers with little or no prior knowledge in formal methods. SUBMITTING A PAPER ================== Five copies of a complete paper (in English) should be sent to the Conference Chair at the address given below to arrive no later than 25 March 1994. Electronic mail submissions in a postscript format are also acceptable. Papers must not exceed 6000 words in length, with full-page figures counted as 300 words. Each paper should include a 300 word abstract. All papers will be refereed and the final choice will be made by the programme committee on the grounds of relevance, significance, originality, correctness, clarity and the use of given benchmark circuits (see below). The conference proceedings will be published by a major publisher. PROPOSALS FOR TUTORIALS ======================= Proposals are solicited for tutorial presentations on relevant verification tools and provers. The intention is that a tutorial will provide an overview of the basic ideas behind the tool using a completely worked out example, rather than a detailed instruction on how to use it, hence the use of benchmark circuits is also suggested. The tutorials should include an assessment of strengths and weaknesses of the tools and should concentrate on general issues such as security, robustness, the degree of interaction required, the user interface, and the mathematical skill required of the user. Proposals for tutorials should not exceed 6000 words in length and should give a clear indication of the topic and structure of the presentation. The proposals for tutorials will also undergo a review process and it is proposed to have no more than 6 tutorials during the conference. Also welcome are proposals for demonstrations of working systems. Proposals for both tutorials and demonstrations should be sent to the Tutorials Chair to arrive no later than 25 March 1994. The tutorial papers will also be included in the proceedings. BENCHMARK CIRCUITS ================== A set of benchmarks will be provided by anonymous ftp after 3 December 1993 at goethe.ira.uka.de (129.13.18.22). The circuits as well as detailed instructions on how to use them can be found in the directory /pub/tpcd94/benchmarks. All authors submitting a regular paper or a proposal for a tutorial are strongly encouraged to make use of these circuits. PROGRAMME ========= The conference programme will start with a day of tutorials and is followed by three days of presentations by contributing authors. The late afternoon sessions will be reserved for demonstrations. The programme will also include invited lectures by prominent researchers in the field of machine-assisted verification. The names of the invited speakers will be announced in due course. IMPORTANT DATES =============== The important dates are as follows. 3 December 1993: Benchmarks available via anonymous ftp. 25 March 1994: Final deadline for the submission of papers. 3 June 1994: Date for notification of acceptance. 1 July 1994: Final camera-ready copy due. 26-29 September 1994: Conference at Karlsruhe. ORGANIZATION ============ The conference is organized jointly by the Forschungszentrum Informatik (FZI), Karlsruhe and the Institute of Computer Design and Fault Tolerance at the University of Karlsruhe, Germany. The conference organizers are: Conference Chair: Ramayya Kumar, FZI Karlsruhe Programme Chair: Mike Fourman, Edinburgh University Tutorials Chair: Thomas Kropf, University of Karlsruhe Local Arrangements: Hilke Kloss, FZI Karlsruhe PROGRAMME COMMITTEE =================== Dominique Borrione (IMAG, France) Holger Busch (Siemens AG, Germany) Luc Claesen (IMEC, Belgium) Hans Eveking (Univ. of Frankfurt, Germany) Simon Finn (AHL, UK) Mike Gordon (Univ. of Cambridge, UK) Keith Hanna (Univ. of Kent, UK) Warren A. Hunt Jr. (CL Inc. USA) Paul Loewenstein (SUN, USA) Miriam Leeser (Cornell Univ., USA) Tom Melham (Univ. of Cambridge, UK) Tobias Nipkow (TU Muenchen, Germany) David Shepherd (Inmos, UK) Jorgen Staunstrup (Lyngby Univ., Denmark) Victoria Stavridou (University of London, UK) Pasupati Subrahmanyam (ATT Bell Labs, USA) ADRESSES FOR CORRESPONDANCE =========================== The papers and all general correspondence should, in the first instance, be sent to the Conference Chair: Ramayya Kumar TPCD Conference Chair Forschungszentrum Informatik Department - ACID Haid-und-Neu Strasse 10-14 76131 Karlsruhe, Germany Tel: (+49) 721 9654-419 Fax: (+49) 721 9654-459 Email: kumar@fzi.de Proposals for tutorials, demonstrations and everything related to the benchmark circuits should be sent to the Tutorials Chair: Thomas Kropf TPCD Tutorials Chair Universitaet Karlsruhe Inst. f. Rechnerentwurf u. Fehlertoleranz P.O. Box 6980 76128 Karlsruhe, Germany Tel: (+49) 721 608-4220 Fax: (+49) 721 370 455 Email: kropf@ira.uka.de All correspondence should include a return postal address and, if possible, Fax and email address. ___________________________________________________________________________ A (nicer) Postscript version of the Call for papers can be found below (compressed and uuencoded) __________________________ cut here ______________________________________ begin 600 TPCD94_CFP.ps.Z M'YV0)4) F=(B")DW8LJTD.$"AH(2)8;(*1.&SALY.D"0L9,&SAP0-5S0L %B MR!LX>>2D.8.&#H@8.7#8:)$C!@@I85/'C4XW9\;BR0@#1%L;,<#>R"%C M:1&S)MNT*>.&SARQ9 T$8=/E6G8T4JX0'"&'7(,5%?;0"9AI!DU &'1DZ"0 ,(7-&A@&%E^3:E M<6B (>$4#[9Y),U4*D8"%B:!1((7'H))GIT)(G=DL&Y!@14=#0FQQXOU.C> M2PY%-]T+=VI'!HIAP%$&G_A]A%T=Z;GFIU#_@2"HG6'0P.>D@+I@ UTUS3 # M#C7@8*ETF,Y@7Y_L_1E#2#74,(--EQ(*%1E<[A^A 6J+QC11$5; .@6")4*Z$1E1@@A!'_WZNN:&ZW%YUH21=PK7&AR*!R; M&2U0FP8;?!(,@JG86@J"Q:L-QF^!=%"1AZ(@&"N<$2#/.Z>09O0EAY G@^SO M&T+V.QULTZJ$EFMBA($>"%B D%1V>50FA%/S>@1T;G5,3,80:"2U!]1)"=$T M&Z/)4><+=Q%X5HX(:\R7;V/R:<8;;YRHV-E]]5'7T&'D,>1)O MQ>.ZQK#"6\!+AAE\SE$:K:ZUC%W-*FL\>,1A3-R' H,.KM^(KAF^] N*O[R% MY@&>6!J. 7;-UQG!KSE''6*8J?L+Q*-1QDHM#<^[\=2&F=SRS4_Y?/15PDL\ M'D41'I>IQ'./_)C*H]6\L>-+?R+TYO.>1_KVM7]\\E"17Y? 4K\JO40&-[B? M&/)7/#QHKWC_@U\ F=]0 YC\.$9GF0PZA%18R\X@@]! MAT2JR<%J3BO#GN80!CL(Q5@V,0Q5AJ( ^+V@9S\S(%AZXQC[$><%1Z-#TCYB M0.*TT'_="YKKGN3"AAFL?4)RR/G2-R3]\;%ZUV.)2^JW1S.4AGB^ UZ79MC' M%NS/D&JC T^. ZTR<&0,*D+D[YH'2.RY)%SU"AB^_.,"FQ2R-(3T(R1+*30R MD*$+#^3@5LHP.5ER)4ES6 .:NF*1B<"+"'P:0Q"#!C\1DJR$ MG%KA0.#7TH""1*48O^-*@:K>'6@#"MI-#AH.CI M:6J0Z52D0I2H%=U#4^5 !ZMR%$8>DE&(-LX+FE+ JLT M&#W9H2<*0(%FY@"'[N0A!66(0Q_V8)[\T%)!93 OF\RRASV<@8I6-(UU6L!* M^MK$1S:Q8(K0E%HAW59NY47/BE2V!R&$MIX=+ ,N=7D&F?:2EN-U+WR%XB/[ MXHN5/KJM?UM[HOWF5P$!%DIF*U+@ R\ RO.Z0YBL1.:6#HMB3KIQ<>+6A=?@RUAW@9=%!@V71@WH#HBL%:=?$ =$V MJ?0/$?WHR0U*/T]2-+R>^J0I:=J!;2'.D$]:9'CEHJS*K%0_+:5(PZ:@:EZR>#ICLXM9"G.8Q%CI-)I!KG !I=895%NM3*46 M5UUC!.3%8$IQ,=;@>&#M&^# "$- M[FM#0/2VN &YJY!#'#@@Y$H@ @\\,P- MAN 9&,3 "$7H]PV,8(1^&P$'YO9WP&? ;X;'@ @-1SBZ87 #&! \X#>(01%F M@/$8#$'C,"B"QT&^<1R$/.2C<3B_%>Z9@%L^WOM6^M[7?O*V MOYWN./AWT E.<'\37 AT%WG!O_WM&Q!! 3F8%;USD$!\>^;?8@=[YC&O]I3W MV_-!S[S/1>]YCGO^\":?N\D9K@#.I[SG=D^XW6$>^K[3?O2VEWGMC9[RV.-= MWZLW><]9S_FY_[U?P]_XXN5-=:MCG=YI!8'E!2_PB1L>X$$/^-M[_WO<5UP! MN(\ZO\7/<[*7?^*$G_C7^2[PRT?5WWFEW[\AG^$EX ,J( -V&\7Z'X5N($8:($> MR($:Z!G@EX$+6']T1W@F>'E3-W!7YW_Y!GH4IX#[IG8S^'FBUV_@QW8ZN(-C M1X#FIW0?V($@6((A6(0+F(-$F(0DN(1!6(3IYQGI)WPHZ&\Q\'#[E@,?!WTP M4 /WQ@/89W#K]X7]MGY]-X9L1X9H. .%%W(#]W;*YX9WEW9&@(0'.(8Z5W0) M5W3VQW.9]X,6AX4&5X;:9X9V=W*>)W\\1W7X=V[J=G!D-W"!QWPL^'P^ !^5 MQP/[MG)NAWQBUX9A=WE&\&\7J'&DV'0'Z'$Y2'.C>'.K2'/NYXKP!XNJF("R MR(JT>'.O. 2M=XL7.'"B>'R(AWAX%XK$>'DU00.!UW]:F /2EV_4!X5?.'?9 M=W0.D7*]IX%VUX &*(C888J79HF)%F6'T^*(8#B('R5@0FIXP^\'^0> ,*H'U& MD .%-W"(-WP'EW!JB'8^MWYW&'0*"(,\27H^V7GH:(- .93U%Y%KV(91)V\T MP(+Q6(5&99@270,.0-7&7<3 MIX879WCI]G$9AXPP8))5>(EJ^9)/Z(D%EXWAZ',U!WQJ-X<,B),*^'2&UWDR M*'H >785=X<5EX<5EWX%!YGGAW_^1@.-UY)-*0-@000_P6W1DU\D,6Y\"8W7 MAW2/>'%("9FJN9I+EWY(B91J^7&?N(8Z!Q]QX7C]=P.56": ML8^9]W6%6'I#QW#R)W_DN)RCLIR+V7<4.6]51WE2YP/RUH5Q.&^D96WEAG:D M-6\!YZ'^A@,?.@0C.J(=.@09.@0:FH4UP&\M28$A>GEB-RH*T*#TF9S+*0/S M5IA%!Z%6MYX4>HG'R9#^R8,[.*0%YY^627'.67#1>9( " ,*V&]3^I\Z>':! MJ8,UR78(I(-=RG8T (,.$:8W2*9L%WA3BJ9GNH0!>7EM>GWKUQG@"0-R6HC@ MYY]YR)RUIYQ["@-BEX%_"J/]>'SS%P0Q$ 0L6!-$H'5<:'E@1Z<+B*(V*0.: MJ' 9*'($: .@]VZ9]Z6>X:ETNH<,^98?JN)$:R9%O6H96V9$ VZ]A*(:O0JZ^>J@^8'+T*)D[ MUX!VMYP-F%80.W\Y.'_S9W*I-W086X(;>X&;5Z4D:(0BFX3NAX1"R'8A2[(J MF[(L"[(NJX.[>*53JI9?!Q/DVI*_FK!/J8:_UY?R&9[;"70>9Z,[]WWAV'%( M:W$QD'']DG,?YV]4>6X32GG-.'8F=W.CXG'LAG NXUM&G Y**"?IYPI=[4[ M6G4]:K6A& ,^D /NF6\SJ+5H!Z$AZI\D^I\3Z+4J![!%RFYF:K9XEY66Z(A5 M6(G^UHP[.IJ*F[A&NH,F^Y>"&KDAN(J3*[DE2+E\Z!DU$03HZ+8P$ 2&RYM> M:+F86[JD>[J56[*I>[FH6X*?&)>'6I(Y\+F&:RKXIFZR>7G.602:FGH8%WA, M1W1F9[$-2[P5%[%]B;S%NX#':[P+Z+#/F[S&.X+.J[S-RW,N6020^'"#>VZ= M<:[I]J=$(*67MZW;.G[+*H+,^<_'3VM\^!:*K^/*H.P<]0B,]Q6-!Y6,^"JK=B MNZ>>=ZG\N:-$( ,W3 2&"LK+V8RS+)1$J+<#.J,SFM#S#- %EX,"38T&3=". MB=(J/=#_7-+@.,\Q$+R*6WKQ_+4AJ)]4JG81/=$530/Z&[#\6JK^&M3[RH-D M6-0[>-1 C=0BR-1$O=10W:].S9HNNIK!2]5/+=51/=1.W=5F^+A;K=1:/=9< M'=9&>I9)S:6:.0.X6<4Y4&_&@F\_EVX327 #-P-"@';6YFXGEYZ0ZJ>6. 0R M87%0*H&167@H.(5]#(E8Q[;_-]< %]G:JZ*_!V^"#<;_QY8.>,)QNW#+O'"R M7)AQFY?S%YFE?6ZG#<6.F-JL'8"JC=JN3;&K'=NTC7FO/=JV+'BXG71)!W*U M.=MQQXY-)V^/%Z$?![K(J,[KAZ7WZ';.FLS4'-W0/=TX^77@1]V=5]W9O=V? MI]W=S=W3^-WB#7?8/=Y1>'ZI5X4W/ 18B+"9#72@^(6CLJ7[QGG8AW[:=]53 MB7UH2\L+U\"K;'"#28"<=\+C7=#_G'9(2((IAZ>>X9]&=Z+$.H%@9W[Z>'Y5 M/-4 M3N,ACM>SK',YJ*D$J*)-AW0%"N9K=X>(2+ZUJCR7L9?G&0601(N,MR M+H-T3H,?^86$)W(9=\,OZM[D%GP5+I-+-WCR_8-J^7F$:9U!QW:*;I.?Q[-! M-W!L3GVOEWKZ)M/0+'#KU]\-/'%HZ^G:5W.A;LL)-W'^.7R!)W=^"'2IN.%M M[>"M)^!K: 1$\(#CFW38)WC);MJU M/=NV?=JCC7#0?MJL5YB]O7B@;:HUV,J@F)1.WN%06J0F.)-1B)=H";87'G57 MN^@HS&Y#)^Y,O,Y]ZLZ>BEGI>K MYXB@>&X&I_+ AYTL7[1B5Z.WG.U/_'1JV.0W_.0+'^)3J-OF.)K-'-HNGN3* M7MI*SNS/WNRPC7G-[..:EW0U4.L$5^S#Z))B9YE/E^^CJ=L?FN))M^)5VT AW_X.-EBNH.0_?8 MV^]UWCL;6U&$.5E/=;[#G?] MCK*BBN@W.'B%WVXOWF\VD/AZJ-3-U]1J]_@H:YI72OF,KGF77^#MQ_!L=^I3 M>NJ8;J4'O(EB>'WJN,Y;*J/_;IV:S_J$Z9_YGJF0&[!X7OOW;?OR.2M&$*$[ M3&\VT*A>F'Y&2>&W3,8U2-]-!WO)7W/+?\N<7X//'X&:#?W*;_C%3W?[J'?G MC9;6=_S8G_+.[^F8[ND^^.O-7M] 5 '53Z M2%H$O( ZJ %JNLZW !]4JPB-Z0I+A^3>X M:8?9@',E_/X29") Y$G[T:"H0Y@:8(AK@$#PZZ2^$XB=:M;3:8#_!IX9L "T M!#G?Z'."2+#[&<%9)]R:H!3$05!P"EI!*@C^GN 1-(*=2 @6P8!7P')0$&Q_ M!DSS&;]]=@-)7^G33##0ZO0^&E@##9O(.V#&3ULM00+VX)9@[!&"2Y#=H*T, M5''-"F\WA4B;DMPAVXQPJAE4);_>D2KA]1AX$ G FL M69ZP]P@H3PA[>,]ADTRMZ0F1HMTG!S43'11Y\\^ Y<%YU@#YX!X#@I<.$(X^ M1)B<>"$AW%^*L%)!'4D("9'2#L12.=!?#4)*& PKX>C;@*SLJ&G )0@- =\S MI(;HC?1]K#B8 W:88XM2^F_'%9XPY/\L$L!K;H'061$X'KAY3&%&^H#?2E3A MJ0=H!A_@!-Q!$C# 44"QE@_O85V:2F!' @E 6<@(E0XE/(<'[ .2,36H#JLA M)@R$^XP<&AZH$WLB3Q10:,TGYD25^(2* M8D@L.#( Z]V_CAC\TH\$PH-\B592*LS 97L6HR!6'&>&Q3:RP M&X*RS%:73)P?>G$3I^,-N-F'!A\26W2+;1'&Q46TN!;5XEN4BW#1+:85\@?C M[IN+&G7W3?B(P+NSI6A64W-X,0 N[+Z6)'*$P"N$1O3O^-A"+(4$!9 N7(*& M$!J2(#(&@\@8O"-C4ZK%W: 5EP$'433$/(^K'MTXJK3X0F,1D'S51^*P,EV7 MJKI>"_Q',@ALH<.J:, 4(CNLAC^P(T+\+RER0X[X"OL0"SR( MT+$:LD3IB VOH76 &I'^L M93#A0!(XE]34-)40?$8.\O- R GI'RFDXC-IN:L//IT,F9QF4.M)=10QLS8FDK?QNPZ5I%9D86*1#7*@&;T^>'1FY"UT3BZ22:4>_QCK3"3 M\Y&ZJM_YI[-#?5!0K@L[BBW0X2>%%Q8WC@RPCYNH_$1)9;:'BA0DNI %4O8] MN 98I#05CP2!8J=+%K@N*1=A7X>,TPY M-DD9P!3CF^BQ@^PHU85! V9]<-W3P3S[CL?MH4;TE[07(]2 52 MMF,TY([G,EU&1^]H+DL5>#Q5IZ]8KL+[Y],\X@OSBN?2">9":L@9]U"_/(B\ M,B'V0%-H&:U?;]2/ O,@HLJN)X.*)5IRC=%M?_T],M9SXMP_NHUYL3WFQHQ) M,0OB;GR6!W$.+1Q9J.L.YF!3A0]H"EU)27G_=!-^JEHWKU81GJP5Y ZAV)E) M H=KA1[[,RK:T$0"_05.: MB%8OF^+B64LH\PMIP%F&UIC8Y)2.LVP38L[-20TS9^1K:I>SSF!901)R6]>6_Y9PH5 MN9.GS1[5KHMFVXR:23JE(P2ZWHDL9D&/&B&[GY=\2ASXJ0%5Z?]5."''W_3< M9>H_;XUJW:Y1J>_*)P,RG^P(\NV[]8D^ ]\O*FUM:"(>'VC6[:(EBADRH]( M4DLED/>1O-*Z8DTI13OX=U,AU>_5%\G5#LQ*W?J,Y7) HV/E\-E PH?$;QV MI$O+UT&C.A_-4^( 4"K,G,[ER3C:"S/Y.4@)*=GG^7RFZ3.:&K@*!DW=)](S M FJHZRE&S2;UA,^(E'H#K4A^TQ&YB,2I.?T[X_2P.CX'-:CR*(,:4H=J M0C6J0I6H*M6CNE1!$35=1\*LH5(E!AE1)=A4@G0 QYB&I!SVAU243&50X\NC MDB2).=+HI_,TH$8/K7+4[^=1V>KCA&9M%:Z^U=Q&F=1J7,UMU21[Q.,NYK:C.H%4"LK663=; MH8X4?*VOE>.0-*1S,3$/??M!QM3?$%9EZN&"'^>S:X7GHS90?F0_$T\ZRI_; MYW]*5P$Z>*AK 6VNOXR*RB8%NAAG:A[#J.T3O&[44"F&/-ZXRGFE]5Q5) MX M)1TK%"-)[W7I.;N2*5XM:D:MKT]5HUI4=:2.](\*[3\ST"E5+8#C)>N>PH%P M$4XW_D=HY$E%)7,E)QD;@WXME);*/$T3:-\2'=_#/B1URH6BTXJ8-!R6OY%IJKW+'!Z6> M/K1ED9F=0SM(*.F(.S'[3"V023V?@.@OQ01X.1H'7P?,/F -NHVL)72,["AB M#7[)5/&PI#P+S(HDNQ.GUTV&]IPB145-CI7\.$* W\PR1*MH>5D,:)Y,S/20 MHLPC:46.C+N3V/1\'B=%]V^.4UZ;?=,P6](@/39J%5?.-+4BZ%:YJN]Y26<@ M'E,\DC&XPM$O6Q!WDJ4]GZ"'I+G9HR9G$:+2N4$+-O+MLGDSW4;DVD&-'2F) M2CTJNFQ33YU5IG?VRC);C .?LJP,95SP:9AZV6T[C<9L(BRSX)8=I5F#LV9M M8)L%:V\V8JK;EE7YVFW.K)TJZE3I(GC7OBY9:%R-S,T862%H"Z7^8:!#1,W, MFPHD-@GP,A2:W&6$J?7M(3)KRTZ=H66" +"8.:PDIW,0)^)T1TM)F>HF>SF; MSJB_F5TR &.I/7(3HM9-6ZHZZD9[@;E#&*.2U T0 HP,8=TFZ4/*C, 5,15Q M84J(IB7VI_J-G-)3HB]Q62?K9":+5'B<7"+6G96>[V2>6IH\LVD*#NIR(ZE; MTIHN>!JZ2;>A!2K3N<8J8=\:6ZZ4B6VRGUO),L]RVC@W#.:ZI7KC$/"-V?6Y M&$CM9!XMZ>A8WY_:NJ*O#%E)ICNV7W3FZ(D6 >JX(^KF;3/2@7<<3!-8N2D)M$^SMW0!&UAE*+Z1: M3J@7L$&MSI#$,@X"$0*DHG#1@".&;\S-!&M+ZN;AOAO8*V_8UDA09V\6%OFE M45GOV"/F.H2F2/"2I3NDF/I0O0,\_2Q/H5-!RV5-FL51@L12X+*T[&M]"RWU M_;[;M_IRWZQ'C<9O]96^SS?](KCMDWP7%YN#:4ENH_4IZ#M\*U#(ZH P@5)6 M'42E<>K-,'54E6Q.D5S0/1!$? "OG<&6 %#8 <\@4E5 M Y; *T"/^ ,S($C\ ,N<)[H*GFB#W5)$0[,1:8_K8N*G:JTHVJ2G,(\/_?@ M;+)],X/#EVV-ORBW0.$C'=PI52Z_W'2.-&C*N"SU--UE"^17#.X(.TJV8X'$ M3GZ"NT5J.<4JQK6DD%!.G4#B\HR>T:45^H@ELIVV' G(T,Z"@[G6\M$AN!9OH6L#(@L(4OFQL/6#\1:/R1N5NGAM(*E M;I5U>\%?!Y ]7F?E<>$C$7[$!.]*D6'="(E#6B1F=/WQA7DB9]N%'RH*K@%U MP5%]S.T9XS+0V6\9$*C8OY_X*1G$\PE"F=M"6KYX%_DJWU[TI]S5/#O&W1<9R^/N MJWW+K[95QBQ-^N*=/S5\DA^I+3Y#1P90).6$-:64S0L\+[: K48.?.\:TE9\IIE%^3F4_&9N%-X=[!')?H5#)+ MYIF54RXIV^2:=-THXE2&R@G18^+D9-:25_(2;'O!S%G& MPD]% SXRYY(!H,L&B#'6%);5$1$\<':G*A,EZ"9TE]N,(D-W^4S9Y$(F9_,R M+-UB1D=. 69D"73MT<\-;XP3O[-%]_*28&!)&L_N()KG;8@[,C XS M6^;,#'EV_-#AFJ@VM%,9AD_Z:;O(XIY MCB4K2H[N^?DO:D9U;.CB"WR%<;E]/\@W?6D0#FU8@T]#)6=UJZ'(L'6T1.8P M[OJRN'@7JS-UOLX9$W*!M>P\%PD/PO7.C_D:WCHR-)X%7S4257E"WO/7GI-^&A\J&2IM,G' M#P@CZ)F\E!5T=$O07U8N-^@O^Z 9=*9CRA;ZEF%H!"W3-K3A-'2J*4-#Z E- MHB\T3![1)II">^@5[:!9M(JFQ!JZ1I[-V(=*D:TM*M2"=I(:VDD70RD]!&^L YZ29-I9GTD7Z$VC ;5J'8 MG!B9);%43=#QRAEE\F8$#YQ2AHLN&AHR9=ZCE3>=>FS3 '-&HT&7[)?YW4\6 M;R".TKKFT,RGU6V?!LU^^IAM9T!-J%-S:?[,AEI+5<[1S*BK#SYTEEGZ-5]2 MRO-0\=-;0T>.*MDA.AZW\G+./&-KZWC[.%\$%WN,H$TM,U8S&QCGM M.Z&TZ82/J29,<*[HM+-;FH=DD\,[>00N",@ _TS1Z +;0CK-2.35I9.'?M;2 MN'YG/T@,!4P@2.#T':4MTZ_4)B?I#L>I? MJR"TMLEHJ-1)Q/)6!1U=%9WZ1F- ?D:CT2+I*/MS@PQS\=%21F,S:Q$W;X. [.#L#=;9/U8E@:M,DM#_HW0MN17:F!>;29-@_J@3B0 L;BISVU M=Y"JBGMAF''I($49E(X4 ZK8VAI1_6*DLZ@03M72EVDG3Q'BJ-FF6&MW,X-X M-T\1M%++RFIQ"WQA7^\9&[@\%$4-6ME1:9WA".(GDV9N O<],]P#;3X!J/PT M?Q@.Q$I2NJKL4-'+@W5ZE=OJO^(3;MT@W:D[K>^IK=L9L&M_;KI-ND>WZ:YW MIQO!I6Z59/F #R[2-Y\V.SDR_71X.5GSI86C&OVN7VVKCW>W[^[=P%MO^S/= MG8<,Z(=UQR7H^)6=UMN)Y-37@0NO3$\AP8@FMH. M_YI5Y)Y73JQXZSYDF*Z MI3&HGC%12^3*9JCG%L+F^X7^:EN\RW)2F)K"7Z=[IY6$\X(;[3A.C ;KSYTJ6RIX/ M4KZC"OVI7]T-CSOXJ%;?H\J#&^/<3<+[64Z:QOZ,2-J?P/QVR!-!#E1 TSV& MG8>#EO?O]0;#)Y"R\1VOM'C*CN(RN:D6X7RT7VKS;#!?NH'H^U6<.:VZF;?+3"- MEVXTOHDBDJIDXFK<=+-Q.1['X?@:%]9GO([G\36NQ]&?,+N#4J>&_^( MY'O;W*NQ.,ESBF!?OR&%.0U45T>ZGR-QJ#Z-E7LQAN3/W2ZQ\EC]S:9[*6>!SC&B4 M9VP7KD/.=B00(B]\BUR26_+5+.+Y\DUJBJE7RI)"+O>6O')I3\Y$.TDGZ-"_IK#NDF_1J M3G8HW ZKWC7A&]Z= J=L!UNTWE#8JV>YLU^L;Q098YK=XXLLC>CO'921-_/5 MC;\4=Z]CH]Y^D[I0#[Q/?:ES,K/4U*'Z[7:_4[VJ2_6"=M2S^@6+YEV=JVMU MK(Z%_:K9-.N9]F:Y+5&AO];-L>1#KYM^M2F>'IY .2D7Y:5\I<]R6W[2^[I* M1^G//)H#]I"NRR=82]_E(D=LNZU?CL/1\R9WX7/*^$KD]AO6B?<'%[^8W>!@ MW\R.C^WQ,H8])=R?A?6P?G;4<4#29?9.^(YC?6NY:T)5U=RI+^S$]7[QST9O MTKSK/]PO%V_D;;SWMO!FQC(4> MKT![T\:K=[=0T=2$6Z;2]#?Z"$W234[)0D&ABM1L2MH H;R6LMV<7 MB@,TC8TQ-QNA8\2 B=#IZ3K7C@L9R!%D3"R0-:N<9FVSK91B4"3;AZH@+'Y' M"YD@EKMZ.5Z'77E'[UJ\+9Y#,J[COJXY7M]K_!Z_[\JLCZMQY@UT$PZ/__%^ M"KKCEV:3()YFMO+(DI53G_UG MXI28SOE26XS?M"J@"W(XE84/.'_K@CUQYXNF8AJI:O,Q#K(JNKE0= XSG0\Y M=CZH&P%OJV\*MCVZ 06[M-MB)T;)PAP3EKPG_I"%7+5.%QQC%2+D)!D:Y4=) M'Y/SNGZRO(KKY]XA3:^9R=(FTYI UY\A)I)=BM-X/D?(AFDQ[^SL!N\T#LMN M/47@92_D16ZU:[V7VD$I^V6'>FNHZY6P*PO M>Y?)^:"P[))RPWZ>_XFHH5W MR$,7-+J."M<$.JR6)(43RN):S3T<"03)$Z<_MV\ *W+%:WIMY_ U731RN):< M"CQ+Z[+!AWKSE%;3B6V#"]#3\4Q/*H0Z(+UO:M1V7W7 ^K1X'J[0\O?]OD,& M?(.HRTR> W*A(I%IDFI=I_#G^< /TBT8XJ^>(#VV]CW%)Y'TF43NH7Q/B'CI MQ?]ZJN[=0R!W7WH1R$.-"S3L4W0A,.T5=2#%AV_/;Y_=^_VU /L;:KWX=6<; M!^F:/T4==R%C/BVE]SLRX8-\?Y_OY_W!+_?ZON$?_(/Z\!=^PB_X M%W]DAM1JR; Y8=B\]9G)*M' M+_6KMM2/MB0XV@I?3DC=61-XXQ9/[Q( M_*T/25.C'#.$4D-OQJ,\7SPDEE'',MG^'"!O"'G;>EOLB#SGPU[+_=$P:6[4 M]LAD=7^._?T9'C,[/,XJU?' WLBFV;\99- ]&$T7XV@6_V_R_&>M\)]!UZ"^ M/:+_O![F/O5J+.#2Y@*J M@ '<117X3%//5!04^^E1X8^"XH]U@-43CV*/W$\&S@\8X0F!01DK!@3Z@.L? M#U@$+H%*8#9S!%X<9D\!$@4>@/N7 @@?/"5.C,NG3P5E5)/0E0>T/+V@C]8*IGR^X"ZHZQ-R6 MPOD(@:,.054+5E#MV@NX4O8_LI M'(^/QO%$*1SGH&\U(^57]95^Y0ZV@_ @>:7S]5>S0@G(0@E8TPE@H72#UIM@2$CM0_Y M4V+-H 2S '"TFI'R#/)]>A\I9K6]A*P, 0C68%/]4,@Q09TAJZ$0@@(N(*]A MQ;60F27,'.@V-&TGI"'?D1O:'OD0#T2>\4 ZGQ/BOS$LFUI)]J'Y MEQL$J6$U30VO!, %3'B;"[4"37B!'Y,3'\YJ!E.^(P;)./=A]C2V3L%":UK"Q?Y]1(&3!,4A,@?;F3Q80H8$&8N M%V(#F"':/$$3A[B1S2@=(HA((1I,UT?@=]U,B!Y)X'<#FF0.#WIHDL4IWQA% M@W2P+0H &$;HK'C^%@QR1N4IAPZ3\J7Q8Y^2K 0BQE\&4_ U2U% .Y(TE"1. MBJKBBT-,I8IWXJH( M*[H=LV*G:"J&BK2)HE@@6HI&(6GH!)&&!"!IF+T)BSP3C?/&68H/8N:W2HUE M+*)SU ;Y7-@*C:!3:AR+C!&4R$BPH8\BX*QJ%+./): ZYC"5CRA@S MJHPMH\RX,@9*)./-:#,:A4C!)$9<&NAR Y@EM9ED=O"IB?)>FZ4M54&K M74#((%I#^E(S%6%I@RNCK=@6,HQ7TFTX=@0O5>*_Z!(FC0[CESAXL"1=(=F( MB9F-XM_M4S:*C6"'V;CCN(T5(=LXJ^E.N@JUU15Z4O<6WC@;F3A78VZ(95&- M\M,'Q0:=3PS@^00@!H3ZTINUAK2&\Z)"2/KP0Q+0MA8H#HH^S5S0,8IEJPFB MB"FF6MUBI/@27DF?8SBS O&-<6.RB.*L0*=C-'0$XGIBB='Z0,0 MR2&#CQ^"FQU\8A#Q8WQ >'/4N ,L#65[&EJRJU% JU'7J'DH2@<'3(9Y"&=6 M4Z9D/@V0>AI>A.Q@)U6-;61Q](DGAV%C=)0V[4BT*"CB)UU?7(.)L";R'E9# M-B%.H&/L>"A1BK3,D"AX'32=DII#*88KE:*+DT(*0Y';ABF. M_6N%RZ$/FD#_D#HDPWI!"I)](1"Z10V03 MZ2<&D3.11503Q4I#F>3X1"$JU@8GY<_%2YI2!<,M/3\\4)?'TO!*(6!7:$9R MA5>?<^3- 2&\$H1U\KR1 (_9%UT)'VQ?H4-'6C]V)%5")E)\5,_3 \YD.'G4 M,LB/-$81BK;&MF1N1N,Z@C_": <:/L0//9)/&R3I2#YMBYH^=*I(DI>A(]D: MXDH=XD#T*MYK\ID^Q/,X*Z1DU4<3Z4/Q'@,(8M%$-Q,#V$JJA+M1]L9*#DJR M9.$X*%&/J&1$)$JB9(OCCX@0,4;/T!1UXWPHY*..4L,]5'2!J[7%W4M#V>E7 MP+21-I;K46(E=S!>O=+T@8'8Y$2534:*VF0WB8.D6^#DU[AU^4K"V(AED3TJ MYICZ",RD(H:*?V9U&"K2HSA4^'R&FQKCAT8V?D+-A5@A[I,DHH%X3_Z3!B*? MN)X%5AL9)Q+P?(84$[$DN?%C(J+!).)]?$=0L0CR!'X.3QLI48:!>U]%>22& M<1ME1GE10I0399'X4?)*ZJ&'*$.1)U ;EKA:Q23.XF=X\]2"QF2OXLLIDV,C M.9;H4";L&K]3;;USTR2,$^_-?+3,&.3P?#ICD+5X^]1 *&!2>4U:?4QE?*A MBB#SGWG$T$A6YXEPUHY@'>ZD8_B]V(@+$"5UCUP[PQ30P;.(E3U?SA>D@7Q- M90>D5OI+;"7IT^9<-<3/6IE6MI55']4G5]:5"C&.XY,MW66J6 MXQBXE-SM@#S/8&3Z@$)XVSTV&6)PHIGA!"3V/.7ALVCTF3XH2-^V\[5KYX8K M(X3=EJX,@J3K@(_/"!%5VH!8_I:#IW!T8EJE(8=G/6I*32(YBNE#_1LF>4E& MDM#E)"E=7H;;66IH70)] 5 4"(;8)^00 $3IX6+'$GLX1WJ.T!^)F$?Z0^5E M0'A>@E)L'WK9A[27Z!!["%^>E_%E>OE0UI?OI7G97H96SQ%_*>.](2%;7("H M=&LR $UIPK T@B2*HV!J-H2;8"@8JH&*)/;!7MY#>,X_8F%2F!4Z("3EM:YR7H=(X?2/2>$-!=@YFC$D8%E,T9NEC M8\)D-V8CJ1GFF)8DC[EC2D3,YF9IAF+EGO:1PW7K8U%P8\GM4JY'=8:BJ-L MJ2BJ55XB!THJ/,O,AVZ4-FM6;(Y;4Z;TB;<\6PZF\UF1EEN:IOAIK)Y M.,5'L-8< +*>S:0M?:1 %,-$"AUM^!B M.!+!"4?:BLZ1?JEPJI<$4\:Y]4N>:CO)HY9L%YD^S8IH^*]"NR031=#96EM6BU>Y[0)=J*:8&8:4GZG7KG4-;&G89& MHS$);S"=RN0N=]A@6"<6B8+L."= ![$C&]DEMMD!"7^0G4AFCUED9IY&IN:I M8V*>/N:P(GKV/(%'5FFH "OXX L"3PV$GM_IX1!H)]@)0/.8Q#-H41=U] DZ M:^91@CGVAQ^4I(++"$$0G$[",]66.Y,/EUQI'UR3E!):'<3Y?QZ@%R<"&BXY;=F;5M0>^APL97R#&O:',&45PJUIE8GG_LEN MDF*0V3-8\S&5JHHL:2!21+Z.X:B$0#%3BJHDIA Y2J,QM_.)B/AT;FQCT]A4-FHYSN,2LHB<_EE+HJTU3@HBN?8<_5;*EWS3 M)CJ)I=RH6--D;W;'4!EFXIU^8_Z8/OIO_\WE,0J6'JA.@'AZT%^2TQ0**8Z7 M!M1FR?(9E?I6\[GW:'N]";?1);P;J,RV]^]H>)%*Z*&8"'5$!XQI[\PIA&CT M^3CN<(AHNY*(LBM[!V1GD3VBBVB](HE^*Y,H)*J(*J(#2#;5>C (M0H]]=:D M,[49)8.R<"F(SL^%J:@^O(=G\&FA2+&;OY'V\6AK'YVBK,@J:)ZRHJ8,,MJ( M;<)OP 4QB@W P^ =&C@CJ#>25ZR>B!]WA%7G47V 6>9$9>U],U=7VD M"HU'^KPA2GN7Y,5R25XHU=RU.A4I9!>*M\3(*0V5]D+1;&EL5Q?R=A%F4,N) MQ\3X21II2NI*92!=SNJTC80M(FE1*G4M;$R,H(*1"ET:Z9TD*%5>M]E$2NKU M&S$IYT63HB1(U,F5>J5>&(MM&G>%92N,SYIW15F M!:86J6#:E[I2=ZGDI2<9>(JI^D*G\#1SB?[R 9VB9LS#Y7WHAMV'N^B9=F\5 M5QCGH@A>TUAI2IJ>IJ.):9J:HJ:A*=!3>\P>2M#LD=#1)-W'CC(DU5N8Z3FD M?X1%"@^3%V)M7W_7=9-U#:>*E])%G!JGQ>G?A9R^,\\CKEE9<>4K,/7?003/A94U8<>DQ=0HDI<L' MC^:' 6(D:MSU=70&)VH9DN"1>O%;LK*?OJA]QW*RQJ@K89E3HZ\ -3?JF[*6 M,![)U.*TH5:+@Y0\=6R9(9['V*.1X1[L1F>DA*&82LL^TXQF5LN)P^5W #IE MJ&K:FEZIHZEKJJ7J'+(IDHJ.N(MG2T[SO)EB['0)/G !X61N*F9IAQ^#)MJOY$O M06FB*H@-22;'"V;)_%R'*H9:%W!#TVE= 3-M?"A5W#>H=A^E6MOQ>M0>HMJH M-:QIELJE0C.QA[IXL4 GZHK4H8--.3W)9'A@"D)^"9[RKH@^OZB;HJK0 M.&:JU7&?8B)(5&TI@TY]1DI;*JQZ!G54W@,#T*7(Z&G9XLT[EN$CE0%5*6[8 M8GC45*M0"WK&@<$'HLI\(GIXJ[ 4N*K@33EXX+BJ@*1BM4HZ2; L8(=,.S+! MF6QYR,\5KWYNFPR94X3UEBR)6:1X8%(NB2OT^W2$D% 9ZI=01B15/O.Y"6[- M7,)*N 4E"*OL6;!>* T=-G;ZT"3QG$-W,QVLG0A?A]=MK'X;Q^J8Y'6Q7,,* MT>E/TM,^@J[,1Y,2'!BE3!PS&-H!HZ19GD>+PG[8JQH(K/TRS H M"@B#(GHP>$ABT"JP"36S'CAGM JMEQR5P[.J'>4JGW*!Y"!_F$L*B+$?=JD3 M=K+8<\\JC6-(XB9&P'CG%%F$IA:6)\I];I>>\J7<%317'7*7P0UWSU="EX\9 M=VXKV%G=TZT#C+])?&5QHE[8R=5,=2O.YI7]\B:YE7C%)]T\$XSBUB!?K M5$>V?FZ'3/$VMVFL4ZG)QV.KE:KJ1;G=*I MU#NBJX*'X/!XV:FPEM>-1Q@IB^6(/5KTD?3(\IDT$)VCD]+9KIB>XUKOS&V\ MZ^[ZN9Y:EZL1)HZ:'9DKY@JZ J_'Z^]JW64>V]TXM[QR=XZT2I4*UPIAG"W'0HZT>*LH3=(3F(XJ:,VF*(V]!JOAUG MGAO\6K3N1Q,,5*BVF3^I5,7#6]8L,M4EYO&!)Z">Y_&]!B0C0L0KJV0<3F!")Q_G5^GUPUV>YT-B\.6:^H' M#,08K7N9S2'5Q!DFXM].8L16;:@6K'K$%F%,+&JIQ!:Q2*P2&\4&9(H+CW,) M7K&9X'N:AX!X?I>_DG!I)E.5GD,'G:7VG^U&T#2N5BLG,X.!6 *(I7-JV7DF MASU'N6JO=5NC8Y^D& MP_J6"IF\.4@N1\$)'822[7'-JXWW#UZR.MY\M\KA>'.S\CT\+[Q(+!3XQ7CX%@0QBRNJ_9'S)K?-9OU+(.@02GG"1B]D?W M"L7ULH7(R[.4S"K +#$+Q6DP"QXRV\MZ*]PJ%-> !&[.K)BWX#VS"][)H;$I M>&A>-9O-]K([1R![Q'2SU6S%XHHZ&Y",4475 M:;..6&L'!UT!R>Z;Y%K)5OP8>EO(%(>L^K/,R39VR"PE;BQS O$!)M,I).MK0\J-.J\AANFI22@Q'V^,I,H594!?2FJ[/ MB!_3PH5ZW"S[T;*V;?W.!A6-*)V3D@PK>!)WMYU(>,BJL NKPBJR$C0[;3ZS MW1&L-NW"YRI5=]D=4R#JR-G1 K2%KU69@=J?V^M[!:*7..K?.M;%C[2"KSQXY%>M" MM[*MF=&<&HO& M*"UJ8RN(49]G7(.(?7XD0M!3M).9;E*L$$+D:2";;1\:HQAZJ2A#OVKB*K'RKN+!4X$>].G2P M83ZNYI*Q?3?-+!-CZXPJ[5"V.I46)N#JI804S70'F+<*[.DI#D?=I@-BH]0H MPX'EQA^JGN^B %BC@HW" >;Z+BP;+^@6_FHZY;'7T!%M"PU',JSF*CO(V/6: M[6PLR [#EI8[ HOYA ,2=DLT5&[U6[XC(HUP>IAA&YFB[J17QD8<\/9ZZ M'FJP:Z,*NW1(,O,:N9X7"!SRE5"BS*X[YNS.*]!N'!*OW*K-;D"B[(950P?4 M9)WP5I<'*)81AB*5$J03R(P<)4?.<;7(/.R'2[. 55W?B0:CP5"S&AZNHV&M M4"=F&*>G_20:S;P3J^:[+=Z^R]"P'.W&HZ4$':G6"*#SF7JJH&G"*ZHJO*%J MJ-JEPJ8&+Z #\8P]JB'LE7WP+*^"7PON4J<:">6"K#R\:P=DUZ4VO*!J?\G MI2K2IT;3914R">VE4PGY2DZ)'57OUB"2"M T>NB:]0GC!;1X)U*2,J/S6EU M[\\K]/*\\1-\<,68,R$'W\.FB0I%!\.!(F$M"4E:NYU.O5*OU'M[H"*N6.F1 MS"1FB]GE(PYMA\LB@>?:KAUP;@ED;92]8PN99)T0+V1HTZ$4M21+GO[RZ^:H M79? (NSBJ!ZJL1NFC"$,H:F2[!XA)T>Q4H*,*,0*C2KX'KZ&;^);^"Z^@:_B M>Y&$*[C2Q^&+?KNJK3U%V?U_*8N,V9&0,5U72'J4&J4@*>@;D:"EG ?D$('/):"2*CO:BD8!PV%21Y\5A*R='(?*[ MI!V'B.*2[1QVD0B_&F7)O1:0Z&O^?K[H;^C[KWB^ZF_[Z[5$5>5,7&)2R;WI M&8&%H92%10>:$KV!5-&*/^.U>"7+[O\+=0' %@D!S)4$P!V) ;SL(L!C20,< M\",L*P,SAP 1:(Z$?(B:FB VL[A B1 MRL'['^O0QP^&J)MKI4\+MB!7\K,D<^ZJ!P M)3650ZNNQ%M-K]YB]PZ[-NKC,K#4+,2-'17N.K\![YK5@)0*0$_$JXIUI@HO M??:I*B2@:AZ\F7H?5NNDP2O4[Y1O MJ%P AR:GM$"GT=J9Q?Y>PN>O^OO'L5IQ06'S;\PN&\HPFM".PE#+FMM!1B3M M1_"Q96U9%\O%,C*-+\9>LJGP[+J=<&;S<]W"B.DU9I30*ICPUT*'F+^Z1S!\ M<@C#O*C/08@9'0H/AM6"&)E+Q(W !##PK,$5A!\;;OUX@-&HA4]\&)$')\;+YV"":WN 6>L2WG]X0 M\.G%37RO1K*D#J)V"DY:L(C#+H@XHWA0:[]'!M,'%<$5*J'*_5*XVW#K53S% M,S1 L;9S^+(>C4Q0M2(<=JE@,S1B(,<.V77L*&UEB0(B A.E)$B'\K-.I:2( M.#S>9:+H!R#:BX18#>ZJI\68+/@PZL:3.%*^[*Q2B%@B8\M[>X&0KT2'BY.7 MN#U+R[=1DL0C>(QI@H?9.MDN.^P4]QWQ3.,*G^*W\/#G <_0PQW(/2P2:U[[ M<"%*BBJC3.LR^I<%(FR>P5')3+Y-K+^1!BM3CG!= G,X;U2,@D*-6IG@R5GR MQ8U847'@:^MD,"G'EW*0AAQYCFT"$#.A:,<=Z^.8&\Z8AI)VB&3LC1@[<]6A M\4(: "B\!(F1'@HOT5T'7U(H#ET<$#"M^?F]C>_6(]0.N606412T-BH=+*'6 M.5U"C--2%]@O]6S:3\]VEJQF9,EK&!2GAH$O;KQ@&C66(EBS.O(@_%YE&!P; M*?Q>F5@<]U-KI#_E)6*)76*9R!R'B7!B$+J?*9[4MQV;B MUM8=GZAU()CX#GKJK4 M*$(&')'(!/&:C4W9*-2OFE.,9^VJ(C@-9K.J+^./,(BJD7?X"QQ&L7(X. M$P9YTK*(ZN.!6.',1G=;AIQ$3HI5XY4D.*Y*;1;3%"+#DHWB?RPIZH^SVAX) M&G/(-26+7!Z;R"\RBCQ+0CXKIHS<\-R-)#(0DB/_Q_ICE4@](G(@,N$8)/.0 M76.M5B6>G#-1_$A%YFHNLIC83^F/3C)VG&P>R-4QE(PA/\G ';.4!;EGUR!VYF(Q^RXXKR=(4F%V8H.B+YGXC M692R)R^/-)^-@Z[*F>#-(+MHV5!'7E$&G$57T-0'U(:V9P#D,_1DKH!WY$[& MFL1'C9AS"7CFG??(=F8=54?M<;KL:_&^D\]^K/HPI!KIBS,1*B!]B^;4[VRN M-4W 4X8]1XYRG+(^[%^^:(!UN-1F\)!V.8T0=*.24LS9J&\@WZ:$A7J7#R!W MQOA,S%4*Q0SX$7\2<\6L,5- &W/"Y@:9K)%FQ6B=6

\\C<,5MGY&/&S#&O MS"7S=48RWT7''\ML,LO,+O/)7#-?S"]SAXPX<3^2F_M(!,P ?$ZBM?,LBZO4 M6P>I58D&4,*E- O*EZV[G#0SS:0RU.PT+\U-\]-<-5/->)0!9'%:S5DSUCPU M2\U<\]>,@6S-7G/8;#:7S6@SV$PVPX?,(RJD"KUO,$D74[NH,^?Q)C*SZ#I) M'^$6#>8X7!F-6T/Y9*;U9/ L\A#@+/(/S4\DIM4#5+10"7,)K M=AK82N6,SESI3R:)C8FD@1*OBB,E!KR:44W)Z/A M^$').,B?L@@8@)@OV/%#N M@$QC]@P^6\_4,QX5/9O/G_+ XRY??,HS]&SE),]OY]7LE8$BP[,&] DKFBD/ M;23X\,Y3RK8,^$G*T//^;*0 T.:S -VTF99+6YE(0*_/!O0.LD#OAH+K:T@< MRLFXGAMX> 8!LH+*"O P6[01_8/[\ARZ+_T49;E]F18)/4+M2#"2X:&DN)@L M-(/)-#8U!'(,[16ZA31T UU R] Q3P"-0]O0#/0.[3CST)AR (TN;C^MY?8# MWNU?H-B3]-\Y*ML+B A/J5CMU6^DRP Z@BR5.)2X:_A.R\4/)ERO;+?<);." MFW&[%B\=4J.B>24O( ME(5JOTUOSDJ^L$ 5BZ7X:'5A%(TO:LAU)LD&1' 7D ',!FUP!@ &K(&SX20L M!397M3 19 0J0%D!(E0([(8" &VD!M.&LD$&2-)P0%8P2V0$'T9!\23\/B3! M?V L( ]&0!J @P!/0$;D )8&ZH!"O!8I !F H !:0 ;@ *D"BD '( "B!% MS $I0*E $L %((#<8 2@ 2A 8D @F 4I $GT1B=R-M,@@,V% @@!.4$* $TC 5+$D= 3B '@17;!!=S4W<$8P$^O M 8\%+\$%I >-31]!$@1R@(_K5&7"1WU1YU+%YAQ1@Z@4T?390 ]2.- L $.0 -X *D ,C(E!!RQ=/8M#8-31,(+?5)T%)+$> T.UT& MH "^0_" 4B.T+GT1) FV="^]%P0/EG4<@ (<"BF +$U0D]/!0TG=2X\& M[,$9(%>OTV8 +YU=Z 2" ;5@2_\'J?7DVTRC '- 'C M*!C(M$ ]'@37V'5C MD!-,#-]%+WT&1 YNP FQ5;/4OO5)P",D!4[!-HT"?!=L JP5MM,N?1K_>Q= MTY%!&# &M "HM;'P;L#5$P)/P!NP ?$U-_U=D-.T-4/]/!C5W#0:L%4W!A V M"H &I-=Q *0P!WC4]X&%;5ESTW> ?&U)B-AR@$>]5X\&[+4Q;18@T] T.TU= M&PM#H[&0!W33UL-"C5T["2GV1:!0,]C-M5F=*!07D4$:X!W4UGM!A1TUI-?N M 1FP5?O3W+04D09P 97)@1 B!-@9 @[ C,S8%D$*T%[G!VMU"P!OB*5P-3W] M7:?6U_0T?4[#U"4U-/U=D]-A 'B!78<7D((M+5!GV0QU<;U5%P@E-3EM/6 - MX'5%D (H "\V" !R7==.0!J@!NP%7($V/08,U-HT.:T$E 5Y]EF]V'G4O?1) M34X7%_(U1X!]!KZ]M*-L/-2ZC7 MUC8T36DSVBU%'4 & -C$]KQA;#/:9P ^356OT_3!8"!.Q]I=@;!A9+O9/D-M M;7 ;T_,V5N!ON]D\ 7I06T\+-G>[T&=3T\2V 1GUW M2QUIZG5]4E?&U[1) 7#_&+6UD3U:R]<)]QN071S373:\\1)8)C;!C/U:0]-! M=I*046_59P/ C5FKT[Y#TXT" -6^]:RM3>_5#3=?+5^WV:;W?(U,D],$-32M M7.P$\K6$36R/! G$C/U8X-;X=+>]6SL4GS>+C0+P!-IT+\U[E]O( 38 MV4%CH&0CWV>W9:UG)P4W-Y6=\4X),_;2G124U)SW;^U0*]?@=98=!V07$,+ MS7+7UE%#3R%_3P3J-+*-?T/3UW=O_5M/WG9W:OTJH",SMF#0%7C49#8*4'YW MW<#WD5U;V]F'MZU=7J, 68(4P0;D >HUPUUC]]*!=P/.ZVHJT;<%KF" UX3W MQ]UDRP%SP%I- _S<5$ *4%^?!#M!9OUW,]>U-4'-;TL1O$00;B!$"*,!O2UL M#]YH0!J@@O<*D8?>C6N0WR-W;4U;@QBV M]9 A3A/7HW>$_80O+7#I=8UA:]AN-D%]7-_?R[7^O4[G!S-W $X&&-S9Q?RM M3O_;O?<8$')_&U(V.RU+=P=NP!IN:%W79P"SP!4LWM]&+AU\&^ +]_^M )S8 M(W:331O 6:W?*U00].6MC&-;PO3$4(83FS+!.HV$"Y+3]^U=![0 H 1?7?X M;8?WWV7U_XV"P]J,MB<>&)3?4S;!75L_%FMX34#(S=BX]0CN=^?2L+B2/8"41^DHKKUV;)-2V$=]-C0]\M2T?>.@&:K7 [WJ>U++UT M(]R\=@JP:!/4)OBPW5B7,Z>V-!YQV]BT=2^MAP_@73@T/HA/XV'X/>Y_+]WI MA2T-BB/3*@(*\'5/"*MVSQUHZR@W^'4-73L%XK0L38D#U&JW4R!A]]((=IX M%=S9<7?7?9 M!_FLH&[7U.3T% ]M %.@3;><^_7PC0,/DR/U7'W2*[KTM37=BP-;XOC"D"9 MS8.?UCPVTKU5$PAM0'>A&*39'ODPW7O'W0YW+DY.WP5GP-Z-!BS54[=#P2-( MW ?Y,'M=8^$V-GIP=JO367:M'6F;!&[ F6T@P.54PT'-:2O4MWBD/4/(%,=W M=B$8P-O:]$@.BK7@6#AMX)/[W)*X95UI&PD7@HA=6]_DY'1WH"=LX!KX(VT$ M,-1T!3[-C%S3\P(0T7R[V6@U#9 "/ G7-E.>6M,5X-J,701 !0Q#@5(>.=C2Y/3X0)7/ >Q!@7!\V^59^5Z=8T\+*()*X%73WK>UGSUQ%Y@7S8SM MAU?:^8'Z+4P+$UTUM2 &0 5K=8&92__2W+1<[E(CTTM++GU/<]/6 F6. DP4 M._;IC0=@$O:XQUVD".6? ES]C_<4R/1 7HE/$'XU<"YSX]XN.4YN!O (;$ + MD%,$Y="T--Z(RQ10-UEP=L?B3_=([HVGXNR&TBU?7P2'PEK-G%_318!_O9M' MXORU?1YOR]*3Q5^^CR/A)?4]#EYXW"FZ/[ZB]Q0!-H]6DH#EH+@8D#/XUW1 M?-YM!P'S-DR02^<49#<-KG1/#!KY[@UP=^$3P9G==U?:6WAV86?WTM+X-SU= MW]UO]9[P+*0 ,4$",1*TWNNT-IW. -XG. K08(CHP'5:3D[;VR-VOJT=8!(>M=/- MC$_DW#>F3I./%&9Z@CU?Z^ H@$==J(,$^?F,32 8">)VB4"=U^(M!7RM4%OA MX7I>9.]7&/A!D+S+7LGW*>Z2';$J.H'-9'@%"#3LO10 MC1Z4U'MU:/YA\]5+M8M.)X, +/AU_5K+TF8V$?Z8U]:8]OZ]?3\+7X/V_:9O MU82Y=@X]Z.7VN)9NA9_JGP+\G94OVDE""@!NJP$[N:CMD:_KX\%RL5:?ZM0H M6$Y.,QLL=3&-:YP'Q_@UO4L3UY*W2H"P%^J01^;=6OO2AL%VCK!SW-?T>8Y= M0P@[@5/0=PO4NW2=W; +V5EZ9%!T[]MB^LCM?[/3I[IM@JA3ZJ.X=N")X],3 MM0SN4G/J83@*KH#WWS@Y.9Z33^O0> UNF^?7-?:\D4O/XXU!(DZHFVWP 1Z* M94_9PK7V'3SXV1UYI]U-C^Q#-U^-I':>7;#E;GEC M8(RW[#O*=;V@E][&M)*]:),%_KECT*>[Y9FZ!5X18. TMLP.BH_3S[5B\)R3 MZ(-!SE '_-=+>[87G!#84W:PS4X[Y-/ZV]U-6];0M&R-?-,!M;CU\*W+XC4V M.2U;^^+D-+!N9 _KH3O>+6-OW\EZ0MU=#]0<.2GN(6#N-_89\(B;W_%Y G%- MO]9&.^"-M8?CT;E?SF>KV4I[RQX>#N/;-X].FF?LO[>_C1Y0YYTXORV&-]LY M SIQG8?B&'D8(%%T!>-[Z-YZ1*E;=W.]:'/@JWO>'HZ#Z4HV-)VC\]GD]#2- M29S=Y7<7SDY#TXDV7IU;_]IS (#=LH\$J?CS<%I'H]?T@[V;5]K7.7I )*@$ ML_JH7E^7W!8X0M"?N^J+=V7^9S/4HT&#,:CKZKU[P7)J(^UX]4A]NKO@&?9! M#2UXU'-VCKL4=#FC#1J$ 0X\T^Z-(^HS D.^JR_AQ#4/;E2#XM2TONZYAP9% MPJS=; ??)KMA[HF/W/\ZTXZQ:.LUMD -9(/Q"+NGO9.3X;^%&=_*:^WS]A"? MGMO8(;@<< :P[EEY+ST1-/+9GDP@KY?M(79PTIR'Z^,Z=8YT;^$#=;^]9O_L MVWG?79.@,_3<>7H M;TY[ZYC$6@U/-^=0^O&.E6/D&7H+3WFTX&QY%ZZQK_+M=1BO?>_2'?EH8%)L M!]B!RGYG%]Q#^AJ@7I_J^8F\+FU_U4([+AU2V]7]_,5.R"GL^7J>%_S;_9ACK_2]=&0>=Q_>EC5#_VW8%>8Y:CZ68^QK?&WMFL?;M;;,7AK,YBA ;2Y0Y^9' M-SG=F__F^ ^\.QO[N5/J6;J4KWU&\\6Y91^M;ND[] M:Q_A-G>[3E 7\>HT,D^@E^NE?#N^O0OL-S5,S4^C ;R[,7]-&]0(];+NU8\$ M,G9-#4T' =7TLOUF]]L-N4:OUT?8P[JY7M83YF9U#*YI?^GN^JC.9D\4*'<> M8%)8"UZ]MWM=&P4L-2AN%,3;*@)3/P.D ,$V$3!:O^#<-!8>=^_5:/5JGR/X M\92YQ[W+;^G%M0MP4(B'<'.WU<7J6K]4"W6@Y[&P8D?<@5EUS7 M%KLMS5#OTH8\PR[+A_@$>(F/'10(>?F"?7H;"&1!=L 5J/%9MF[MOJOF#+U, ML'/+UJ;[)%]<2]T!?/"^K OG9HF&TGK7U(LV%0 %# %$0$2MG=O;'(30/7L/ M\02#B(Y)E._=M(L.3__@04!DX**K)-=T;?^;LPDG@2G-%7P%?$59_CH$VEYV M @%+#^R& 9_NIU/9-<"5O=Q#[]IVMXY.1]I[>G:PZ.OKYSJ.KFTHU RU->ZC M']?$MV8/A.?\%%+KN?1Z<]6L]/XY2S^,<@?FM3B/GOP6( M;J?#^C\[5?Z$AX[5,870WWRQY+IZGD^F5R4(N2]/6>W628&33 M#BV SZ!R"_SA-S2^\%,M%K23YZ<%\'VFK94VX$ MD--P1<$.=%,+VG0PK5!7X-S#:1UH1W=(NK-/?]L5\GA;GK=S%3*[^7YB>P?: MMQ\^WO_BLT;J+K07^H*V2,9:U]37],-] P#[';=J+Y WU&^^?"W;\^9KW9Y_ M;4?4+< E!2A(':QU7E_A6]B1O4F]:UOJ$P/=/9/+TAQ!FPVFL],*]F=?O)/V M[/@DF,XXTWF_<,7W4]2T>0WP]T/U%[RDG58;_M TXJ_X5R$$?N,?2YOI!3A% M0 8@V"4">#[;4_(WMA@PG5?GE3C'[^*+]7/_E\WU1=]X/W-O^D/[0/K?_VCW M_KWT5"^AHP"R/U@0R/WN1,"0O5>K^VO\A*#R5^16_'J.27C5EWK&W4ZKWM_& M<$+Z._]+R^F/?S#4,8#TSR-\X-;_P%X@.] "F CD M!#YPYH)?7T@/4O#T8_^)9)A_1H#27_P/^L?4PZI12OY^B0&O&FS/L5>3<_WY MYF)NV+]VVNQ/4_&[8\PYYM)IE3:%VEYM"9 4R ^P%JP'7+Z7 ,(! DA.>P+H M\K0#[0%3W$'.%17V>ZW]7LQRC3EV7J3MF7<1.*\AV:1YH34VW=G-&#?NL\+1 M] !M:+IVPZE-LK:#H\$=W?AS:($Y@'N @ =JNZ7]W+)IK+@)0<*M0Q=9TP(D M 99J)K;L @M0#N "K /4V$9R7!_-&S6M H>_RZ9-"YP"$@(#7K,M+S N0.HU MU)AQR#N?'150F,8C4*C! 5\FKC=2'80 K_:M(^I1[99PT+0J0'HM:">J,_*5 M_]: ;4#K0>3NJ6:&Z^R1ZF* :XU3V^MM^[;.F_2)X6Z 1T 27Q_NDK;^X_"= MLQQ]3#T3H! 0O*;3BZ@9[9(BL8*P'TZ@7J=@^R[4YVQL2P!06U*@J99=, *8 M 6MKF, YP M0_>=EX_#)"I1[3#UF@Z(/WP=-JP5:U>@*=(&[W[6M"9 &0-QU MX0:!23YEP"^_%I MWZR!MT &0;?OT>=0P"7\_98 %3LS0%,-!: .I 3.ZK(+>+I+8 M0&>@&9 8. MC?@*1SIG&D.-":" "[L%VX( 1@+MP"V!+^")\PI\U(QTXZ&)'1)@8N -! ;2 M!EYUZC1C8!( &;@07 ;6]? %JC?(FC3PWE=2\^N1 O4"5;E!':#*KA?V"RU0 MY=YP8[]MK4$&D6I$ =G<6A*JE_>9K?D&J8%+DU 86'.B! MUVY_C3;%8! "< $F+E5 98 F<$$@K5AY\8-+ F2TXX +#IL'W-O,7@A6*M) MZF9I?3K!GTH 5U &**ME%TZ#J<&2@2_JNK8$N!YP]*Z"1#_-WVRP(+A68^'U MTHJ#9[=:'' P!5!-^PM^N8QV,[;"6GUM:, 1)*<% 6R#5\&RP,S.T28'>/?E MTH9J0P F@#@NEY9-&P,XZ9IS58 I0! @.+B4V+G1YPB!MC2B'D5P2X>1(^A= M#RIQ0[4I0!7 "= 4C _.!ZF#;$%9 :*.&^BPP[6A )@ SX*HPE8-/7@1*!&( M]VB#=@"-6VW-0!@<+!4,4Q*!.[C\7A,@O1 UZFQ!NVZH ;K8F ,"-"["TV/LM M!'YP1C^*'\FMFD;V*PM:!CM[P<'CQ76M^Y=I^QVHTZ8 U@,XP'*AY38;S*:9 M%!9O#+48(5O0&]>"4P) V<)#NCR.(#1M"D M* MX[EAJ=3DF0!X +?#J&]5% M AF#,S?7GAM@6)<:M,/(ZZP FP&N7IMM34@MR+3M!LD"ZK03X220U]8.O U2 M!,T"!0+I(&H006@=Y%IJDRE8 M_0H$HX%O7VNZX1U"AX2[B]FC2.!N?,(^BE_W!XCCTWFRC/?#?-@^LY MW62!ID#"G<)BQH8/_ L>$!YK'K==8*@O#^ +S,HM+9ISP4#9FXSPG9:JV[:- M^8@ M35XH3Z.G*;3&QB^!-@:\CIPH!5P-U=\*PN\%[: P[XNX%X-#!B>$P,Z M#+\-N+09FVLOI\!5@/,IU&1I +;#GGQM") $0!BR!8UB+;C!X.^@!9 E: $X M M,2AJ80 4P!I &"@' *8 ?0 %[)[P_"M MY;1\:+?J7;;P"I?6:]FEU4YMZ\)N&ED.\*:>"[[1 SUZU<"HP4'-%F@O?,* MY>:!_<"DFRP-('@2:*ZQ!A(4GN=U<09!32 M 8B$\(9V6H&I.>=GB]ZA ):&'H8[";7%=LP,VZ?!IND)=6F,0!> @,+*5 M"(X$,SL06Y' >=@DK /$Y^*'@\ L'%2 J[ (A KJ =2'= 6XVB^MON8"> *X MZ+1M8P'Y&AY@J_8I,#F8#3,BJ;BCX?I :=@2; C.W)Z&GD#MX3GK'4>JLQK" M#YMS6<.M8=ZX,8"SUX>QE"DBJ"P.L#8-M*<2WX=^OA8@" -4@ M[VYPJC_M(5QJY[8W?,[Y#?M^@<,U0$ 0"/#;"^ZM 8![BL/TWN_CI&(8#N0GC&-;QCBNQ7"[YY^=SXLP""@">@D_!+&!5&"I,%+(*8P.O@H+ +O $F$, end Received: by CLI.COM (4.1/1); Mon, 6 Sep 93 02:54:38 CDT Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from inf.fu-berlin.de (160.45.110.10) with smtp id ; Mon, 6 Sep 93 09:43 MEST Received: by inf.fu-berlin.de (/\==/\ Smail3.1.28.1) from ki1.chemie.fu-berlin.de [130.133.2.21] with smtp id ; Mon, 6 Sep 93 09:44 MET DST Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from ixgate.GmD.de (192.88.108.4) with smtp id ; Mon, 6 Sep 93 09:43 MEST X400-Received: by mta ixgate.GmD.de in /PRMD=GmD/ADMD=d400/C=de/; Relayed; Mon, 6 Sep 1993 09:42:17 +0200 X400-Received: by /PRMD=uni-kiel/ADMD=dbp/C=de/; Relayed; Mon, 6 Sep 1993 09:42:40 +0200 Date: Mon, 6 Sep 1993 09:42:40 +0200 X400-Originator: khb@informatik.uni-kiel.d400.de X400-Recipients: nqthm-users@inf.fu-berlin.de X400-Mts-Identifier: [/PRMD=uni-kiel/ADMD=dbp/C=de/;gutemine 012896.0747301360000] X400-Content-Type: P2-1984 (2) From: Karl-Heinz Buth Message-Id: <9309060742.AA26532@lucy.informatik.uni-kiel.d400.de> To: NQTHM users mailing list Subject: nqthm mode for emacs, version 19? Is there a new version of the nqthm mode for emacs that works together with the new version 19? It seems that there are some .el-files missing or renamed (or whatever), with the result that nqthm won't start at all from inside emacs. I'm not an expert for emacs lisp, so I find it hard to tell the exact reason or even give an exact description of this problem. -- Karl-Heinz Buth ------------------------------------------------------------ | Institut fuer Informatik, Universitaet Kiel | | Preusserstr. 1-9, D-24105 Kiel, Germany | | e-mail: khb@informatik.uni-kiel.d400.de, khb@causun.uucp | | Tel.: ++49-431-560421 Fax: ++49-431-566143 | Received: by CLI.COM (4.1/1); Mon, 6 Sep 93 03:06:57 CDT X400-Received: by mta ixgate.GmD.de in /PRMD=GmD/ADMD=d400/C=de/; Relayed; Mon, 6 Sep 1993 09:56:51 +0200 X400-Received: by /PRMD=uni-kiel/ADMD=dbp/C=de/; Relayed; Mon, 6 Sep 1993 09:57:04 +0200 Date: Mon, 6 Sep 1993 09:57:04 +0200 X400-Originator: khb@informatik.uni-kiel.d400.de X400-Recipients: nqthm-users@cli.com X400-Mts-Identifier: [/PRMD=uni-kiel/ADMD=dbp/C=de/;gutemine 013050.0747302224001] X400-Content-Type: P2-1984 (2) From: Karl-Heinz Buth Message-Id: <9309060757.AA26674@lucy.informatik.uni-kiel.d400.de> To: NQTHM users mailing list Subject: nqthm mode for emacs, version 19? Is there a new version of the nqthm mode for emacs that works together with the new version 19? It seems that there are some .el-files missing or renamed (or whatever), with the result that nqthm won't start at all from inside emacs. I'm not an expert for emacs lisp, so I find it hard to tell the exact reason or even give an exact description of this problem. -- Karl-Heinz Buth ------------------------------------------------------------ | Institut fuer Informatik, Universitaet Kiel | | Preusserstr. 1-9, D-24105 Kiel, Germany | | e-mail: khb@informatik.uni-kiel.d400.de, khb@causun.uucp | | Tel.: ++49-431-560421 Fax: ++49-431-566143 | Received: by CLI.COM (4.1/1); Wed, 15 Sep 93 04:59:23 CDT X400-Received: by mta ixgate.GmD.de in /PRMD=GmD/ADMD=d400/C=de/; Relayed; Wed, 15 Sep 1993 11:58:22 +0200 X400-Received: by /PRMD=uni-kiel/ADMD=dbp/C=de/; Relayed; Wed, 15 Sep 1993 11:58:42 +0200 Date: Wed, 15 Sep 1993 11:58:42 +0200 X400-Originator: khb@informatik.uni-kiel.d400.de X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=uni-kiel/ADMD=dbp/C=de/;gutemine 028200.0748087122000] X400-Content-Type: P2-1984 (2) From: Karl-Heinz Buth Message-Id: <9309150958.AA07988@daisy.informatik.uni-kiel.d400.de> To: Larch interest mailing list , NQTHM users mailing list Subject: Change of e-mail address Please note that my e-mail address has changed. It used to be khb@informatik.uni-kiel.dbp.de and is now khb@informatik.uni-kiel.d400.de For an intermediate time (until the end of the year), the old address is still valid. My postal address has changed as well (as have all german postal addresses): what used to be "D-2300 Kiel 1" is now "D-24105 Kiel". -- Karl-Heinz Buth ------------------------------------------------------------ | Institut fuer Informatik, Universitaet Kiel | | Preusserstr. 1-9, D-24105 Kiel, Germany | | e-mail: khb@informatik.uni-kiel.d400.de, khb@causun.uucp | | Tel.: ++49-431-560421 Fax: ++49-431-566143 | Received: by CLI.COM (4.1/1); Thu, 23 Sep 93 08:12:01 CDT Date: Thu, 23 Sep 93 08:12:00 CDT From: Robert S. Boyer Message-Id: <9309231312.AA11540@rita.CLI.COM> Received: by rita.CLI.COM (4.1/CLI-1.2) id AA11540; Thu, 23 Sep 93 08:12:00 CDT To: nqthm-users@cli.com Subject: [cade-12@aisb.edinburgh.ac.uk: CADE-12: Calls for Workshops & Tutorials] Reply-To: boyer@cli.com From: cade-12@aisb.edinburgh.ac.uk Date: Thu, 23 Sep 93 13:10:58 BST To: boyer@cli.com Subject: CADE-12: Calls for Workshops & Tutorials Enclosed are the CADE-12 Calls for Workshops, Tutorials and Papers. Please distribute. Thank you. [ LaTeX, DVI and PostScript versions of these files are available by anonymous FTP from dream.dai.ed.ac.uk (192.41.104.168) in the directory /pub/cade-12. ] ----------------------------------------------------------------------- Twelfth International Conference on Automated Deduction Nancy, France Tutorials & Workshops: June 27 Conference: June 28-July 1, 1994 C A D E - 1 2 CALL FOR WORKSHOPS The CADE conferences are the major forum for the presentation of new research in all aspects of automated deduction. In conjunction with CADE-12 we hope to run several workshops. The workshops will be held, in parallel, on Monday 27th June and the main conference will be held from Tuesday 28th to Friday 1st July. Proposals for workshops are hereby solicited. CADE conferences cover all aspects of automated deduction: First vs. Higher Order Logics Classical vs. Non-Classical Logics Special vs. General Purpose Inference Interactive vs. Automatic Systems Specific topics of interest include (but are not limited to): Resolution Sequent Calculus Decision Procedures Unification Rewrite Rules Mathematical Induction and any applications of automated deduction, including: Deductive Databases Logic and Functional Programming Commonsense Reasoning Software and Hardware Development The CADE-12 workshops will be held at INRIA Lorraine and CRIN Campus Scientifique on Monday 27th June 1994. Following this the CADE-12 conference will be held at the Palais des Congr`es de Nancy, sponsored by CADE Inc. and hosted by INRIA and CRIN. Following CADE-12, the LICS-94 conference will be held in Paris, France from July 4-7, 1994. A sight-seeing trip to Dijon will link the two conferences. Anyone wishing to organise a workshop in conjunction with CADE-12 should write to the Programme Chair by 1st December 1993 describing the topic of the proposed workshop; explaining why this topic is relevant to CADE; naming the organisers and specifying the workshop's format and length. Further information about the arrangements for workshops and submission of papers can be obtained from the Programme Chair. Other information about the conference may be obtained from the Local Arrangements Chair. Programme Chair Local Arrangements Chair Alan Bundy Claude Kirchner Department of Artificial INRIA Lorraine & CRIN Intelligence Campus scientifique University of Edinburgh 615, rue du Jardin Botanique 80 South Bridge BP101 Edinburgh EH1 1HN 54602 Villers-les-Nancy CEDEX Scotland France Tel: [+44] 31-650-2716 Tel: [+33] 83 59 30 26 Fax: [+44] 31-650-6516 Fax: [+33] 83 27 83 19 Email: cade-12@ai.ed.ac.uk Email: cade-12@loria.fr ---------------------------------------------------------------------- Twelfth International Conference on Automated Deduction Nancy, France Tutorials & Workshops: June 27 Conference: June 28-July 1, 1994 C A D E - 1 2 CALL FOR TUTORIALS The CADE conferences are the major forum for the presentation of new research in all aspects of automated deduction. In conjunction with CADE-12 we plan to run several tutorials. The tutorials will be held, in parallel, on Monday 27th June and the main conference will be held from Tuesday 28th to Friday 1st July. Proposals for tutorials are hereby solicited. CADE conferences cover all aspects of automated deduction: First vs. Higher Order Logics Classical vs. Non-Classical Logics Special vs. General Purpose Inference Interactive vs. Automatic Systems Specific topics of interest include (but are not limited to): Resolution Sequent Calculus Decision Procedures Unification Rewrite Rules Mathematical Induction and any applications of automated deduction, including: Deductive Databases Logic and Functional Programming Commonsense Reasoning Software and Hardware Development The CADE-12 tutorials will be held at INRIA Lorraine and CRIN Campus Scientifique on Monday 27th June 1994. Following this the CADE-12 conference will be held at the Palais des Congr`es de Nancy, sponsored by CADE Inc. and hosted by INRIA and CRIN. Following CADE- 12, the LICS-94 conference will be held in Paris, France from July 4-7, 1994. A sight-seeing trip to Dijon will link the two conferences. Anyone wishing to give a tutorial in conjunction with CADE-12 should write to the Programme Chair by 1st December 1993 describing the topic of the proposed tutorial; explaining why this topic is relevant to CADE; naming the speakers and specifying the tutorial's length. The default length is 2 hours. Further information about the arrangements for tutorials, workshops and the submission of papers can be obtained from the Programme Chair. Other information about the conference may be obtained from the Local Arrangements Chair. Programme Chair Local Arrangements Chair Alan Bundy Claude Kirchner Department of Artificial INRIA Lorraine & CRIN Intelligence Campus scientifique University of Edinburgh 615, rue du Jardin Botanique 80 South Bridge BP101 Edinburgh EH1 1HN 54602 Villers-les-Nancy CEDEX Scotland France Tel: [+44] 31-650-2716 Tel: [+33] 83 59 30 26 Fax: [+44] 31-650-6516 Fax: [+33] 83 27 83 19 Email: cade-12@ai.ed.ac.uk Email: cade-12@loria.fr ---------------------------------------------------------------- The Twelfth International Conference on Automated Deduction Nancy, France June 28-July 1, 1994 CADE-12: Call for Papers The CADE conferences are the major forum for the presentation of new research in all aspects of automated deduction. Original research papers, descriptions of working reas- oning systems, and problem sets that provide innovative, challenging tests for automated reasoning systems, are solicited. CADE conferences cover all aspects of automated deduction: First vs. Higher Order Logics Classical vs. Non-Classical Logics Special vs. General Purpose Inference Interactive vs. Automatic Systems Specific topics of interest include (but are not limited to): Resolution Sequent Calculus Decision Procedures Unification Rewrite Rules Mathematical Induction and any applications of automated deduction, including: Deductive Databases Logic and Functional Programming Commonsense Reasoning Software and Hardware Development CADE-12 will be held at the Palais des Congres de Nancy and will be sponsored by CADE Inc. and hosted by INRIA and CRIN. Following CADE-12, the LICS-94 conference will be held in Paris, France from July 4-7, 1994. A sight-seeing trip to Dijon will link the two conferences. The Proceedings of CADE-12 will be published by Springer-Verlag in their Lecture Notes in Artificial Intelligence Series. Research papers should not exceed 15 (fifteen) proceedings pages. System descriptions and problem sets should not exceed 5 (five) proceedings pages. Springer style files should be used if possible; send an email with contents "HELP" to svserv@dhdspri6.bitnet. Alternatively, FTP anonymously from dream.dai.ed.ac.uk (see instructions in pub/cade-12/README). The title page of the submission should include the name, address (with email if possible) and telephone number of each author. Papers must be unpublished and not submitted for publication elsewhere. Submissions which are late, too long, or which require major revision, will not be considered. +-----------------------------------------------+ | Submission deadline: December 1, 1993 | | Notification of acceptance: February 14, 1994 | | Camera-ready copy due: March 29, 1994 | +-----------------------------------------------+ Authors should send 4 (four) copies of their submission to the Programme Chair. Further information about the conference may be obtained from the Local Arrangements Chair. Programme Chair Local Arrangements Chair Alan Bundy Claude Kirchner Department of Artificial INRIA Lorraine & CRIN Intelligence Campus scientifique University of Edinburgh 615, rue du Jardin Botanique 80 South Bridge BP101 Edinburgh EH1 1HN 54602 Villers-les-Nancy CEDEX Scotland France Tel: [+44] 31-650-2716 Tel: [+33] 83 59 30 26 Fax: [+44] 31-650-6516 Fax: [+33] 83 27 83 19 Email: cade-12@ai.ed.ac.uk Email: cade-12@loria.fr Received: by CLI.COM (4.1/1); Fri, 15 Oct 93 09:12:19 CDT Received: by inet; Fri Oct 15 10:09 EDT 1993 Received: by hunny.research.att.com (/\==/\ Smail3.1.25.1 #25.11) id ; Fri, 15 Oct 93 10:10 EDT Received: by lutece.research.att.com (/\==/\ Smail3.1.25.1 #25.1) id ; Fri, 15 Oct 93 10:10 EDT Message-Id: Date: Fri, 15 Oct 93 10:10 EDT From: felty@research.att.com (Amy Felty) To: lics-forwarders@research.att.com Subject: LICS'94 Call for Papers [This announcement is being sent to email lists. Our apologies for multiple copies. Latex and ps sources for this announcement are available for anonymous ftp on research.att.com, directory /dist/lics] Ninth Annual IEEE Symposium on LOGIC IN COMPUTER SCIENCE July 4-7, 1994, Paris, France CALL FOR PAPERS The LICS Symposium aims to attract high quality original papers covering theoretical and practical issues in computer science that relate to logic in a broad sense, including algebraic, categorical and topological approaches. Suggested, but not exclusive, topics of interest include: abstract data types, automated deduction, concurrency, constructive mathematics, data base theory, finite model theory, knowledge representation, lambda and combinatory calculi, logical aspects of computational complexity, logics in artificial intelligence, logic programming, modal and temporal logics, program logic and semantics, rewrite rules, logical aspects of symbolic computing, problem solving environments, software specification, type systems, verification. DATES: Submission deadline: December 13, 1993 Notification: February 25, 1994 Final papers due: April 15, 1994 Conference: July 4-7, 1994 PAPER SUBMISSION: 10 hard copies of a detailed abstract (not a full paper) and 20 additional copies of the cover page should be received by December 13, 1993 by the program chair. This is a FIRM DEADLINE: late submissions will not be considered. Authors without access to duplication facilities may submit a single copy of each. Authors will be notified of acceptance by February 25, 1994. Accepted papers (in a specified proceedings format) will be due April 15, 1994. The cover page of the submission should include the title, authors, a brief synopsis, and the corresponding author's name, address, phone number, fax number, and e-mail address, when available. Abstracts must be in English, clearly written, and provide sufficient detail to allow the program committee to assess the merits of the paper. References and comparisons with related work should be included. It is recommended that each submission begin with a succinct statement of the issues, a summary of the main results, and a brief explanation of their significance and relevance to the conference, all phrased for the non-specialist. Technical development of the work, directed to the specialist, should follow. While abstracts of fewer than 1500 words are rarely adequate, the entire abstract should not exceed 10 typed pages, with roughly 35 lines per page. If the authors believe that more details are essential to substantiate their main results, they may place additional details in a clearly marked appendix. Submissions departing significantly from these guidelines run a high risk of rejection. The results in the abstract must be unpublished, and not submitted for publication elsewhere, including proceedings of other symposia or workshops. All authors of accepted papers will be expected to sign copyright release forms, and one author of each accepted paper will be expected to present the paper at the conference. The symposium is sponsored by the IEEE Technical Committee on Mathematical Foundations of Computing, in cooperation with the Association for Symbolic Logic and the European Association for Theoretical Computer Science. The cooperation of the ACM is anticipated. The symposium is organized by INRIA, and hosted by the Conservatoire National des Arts et Metiers (CNAM) as part of its bicentennial. Sponsorship by the CNRS and Universite d'Orsay is expected. LICS GENERAL CHAIR: Robert L. Constable Department of Computer Science Upson Hall Cornell University Ithaca, NY 14853, USA rc@cs.cornell.edu PROGRAM CHAIR: Samson Abramsky Attn: LICS Department of Computing Imperial College of Science, Technology and Medicine 180 Queen's Gate London SW7 2BZ United Kingdom sa@doc.ic.ac.uk Phone: (010-44) 71-589-5111 ext. 5005 Fax: (010-44) 71-581-8024 PROGRAM COMMITTEE: S. Abramsky, Imperial Coll. J.-J. Levy, INRIA K. Apt, CWI D. McAllester, MIT H. Ganzinger MPI Saarbrucken P. Panangaden, McGill C. Gunter, Univ. of Pennsylvania F. Pfenning, CMU A. Jung, Darmstadt V. Pratt, Stanford P. Kannelakis, Brown P. Schroeder-Heister, Tubingen D. Kozen, Cornell C. Stirling, Edinburgh D. Leivant, Indiana G. Winskel, Aarhus CONFERENCE CO-CHAIRS: Gerard Huet INRIA Rocquencourt B.P. 105 78153 Le Chesnay CEDEX, France huet@margaux.inria.fr Jean-Pierre Jouannaud CNRS and LRI Bat. 490, Universite de Paris Sud 91405 Orsay CEDEX, France jouannaud@margaux.inria.fr ORGANIZING COMMITTEE: M. Abadi, S. Abramsky, S. Artemov, A. Borodin, A. Bundy, S. Buss, E. Clarke, R. Constable (Chair), A. Felty, U. Goltz, Y. Gurevich, S. Hayashi, D. Howe, G. Huet, J.-P. Jouannaud, D. Kapur, C. Kirchner, P. Kolaitis, R. Kosaraju, D. Kozen, D. Leivant, A.R. Meyer, D. Miller, J. Mitchell, Y. Moschovakis, M. Okada, P. Panangaden, A. Pitts, G. Plotkin, J. Remmel, S. Ronchi della Rocca, G. Rozenberg, A. Scedrov, D. Scott, J. Tiuryn, M.Y. Vardi PUBLICITY CO-CHAIRS: Amy Felty and Douglas Howe AT&T Bell Laboratories 600 Mountain Avenue, Murray Hill, NJ 07974, USA felty@research.att.com, howe@research.att.com Received: by CLI.COM (4.1/1); Wed, 20 Oct 93 09:50:44 CDT Via: uk.ac.leeds.gps1; Wed, 20 Oct 1993 15:22:24 +0100 Received: from mailer.leeds.ac.uk by leeds.ac.uk; Wed, 20 Oct 93 15:22:20 BST Received: from sunserv1_ie0.leeds.ac.uk by mailer.leeds.ac.uk; Wed, 20 Oct 93 15:23:20 +0100 Received: from sun054.leeds.ac.uk.sun.leeds.ac.uk by sun.leeds.ac.uk; Wed, 20 Oct 93 15:22:16 BST From: csc8aaa@sun.leeds.ac.uk Date: Wed, 20 Oct 93 15:22:15 BST Message-Id: <2391.9310201422@sun054.leeds.ac.uk.sun.leeds.ac.uk> To: nqthm-users@cli.com Subject: Inductive proofs - order of attempts Greetings. I am implementing an inductive theroem prover based on the '79 book A Computational Logic. I am currently working on the induction itself. After identifying an induction to attempt I am left with various goals: a base case and n induction cases. Has anyone done any investigation into the best order for attempting to prove these? For instance, should I try and prove the base case first since it is fairly simple to prove yes or no, and then go on to prove the inductive cases? Or has anyone identified a heuristic for deciding which inductive cases to try first? Thanks for any help. A.A.Adams Computational Logic Group AI Division School of Computer Studies University of Leeds. Received: by CLI.COM (4.1/1); Wed, 20 Oct 93 10:09:32 CDT Date: Wed, 20 Oct 93 10:09:32 CDT From: J Strother Moore Message-Id: <9310201509.AA07582@rana.CLI.COM> Received: by rana.CLI.COM (4.1/CLI-1.2) id AA07582; Wed, 20 Oct 93 10:09:32 CDT To: csc8aaa@sun.leeds.ac.uk Cc: nqthm-users@cli.com In-Reply-To: csc8aaa@sun.leeds.ac.uk's message of Wed, 20 Oct 93 15:22:15 BST <2391.9310201422@sun054.leeds.ac.uk.sun.leeds.ac.uk> Subject: Inductive proofs - order of attempts Nqthm makes no effort to order the subgoals produced by induction. Loosely speaking, the order is dictated by the recursive definition that suggested it. So (if (nlistp x) 0 (recur (cdr x))) puts the base case first while (if (listp x) (recur (cdr x)) 0) puts the induction step first. I've thought about ordering but never got anywhere. Yes, the base case is often a counterexample and is hence best attacked first. But the base case is often trivial and the user is really wants to get to the meat of the issue. The latter view often prevails if the user is iteratively submitting the formula after changes in definitions and lemmas: waiting for the system to get to the induction step is annoying because you know the preliminary cases all succeed. This argument suggests attacking them in different orders at different points in the evolving proof effort -- a injection of nondeterminism that would problably drive users crazy and argues for an alternative to the Nqthm-encouraged practice of iteratively submitting the formula to the whole process. J Received: by CLI.COM (4.1/1); Wed, 20 Oct 93 11:13:14 CDT Via: uk.ac.oxford.prg; Wed, 20 Oct 1993 16:48:58 +0100 Received: from comlab.ox.ac.uk (opal.comlab) by prg.oxford.ac.uk id AA04628; Wed, 20 Oct 93 16:48:14 +0100 Received: by comlab.ox.ac.uk (4.1/comlab3.1) id AA20684; Wed, 20 Oct 93 16:49:00 BST Date: Wed, 20 Oct 93 16:49:00 BST From: Andrew.Stevens@prg.oxford.ac.uk Message-Id: <9310201549.AA20684@opal.comlab.ox.ac.uk> To: csc8aaa@sun.leeds.ac.uk Cc: nqthm-users@CLI.COM In-Reply-To: csc8aaa@uk.ac.leeds.sun's message of Wed, 20 Oct 93 15:22:15 BST <2391.9310201422@sun054.leeds.ac.uk.sun.leeds.ac.uk> Subject: Inductive proofs - order of attempts Hi, >For instance, should I try and prove the base case first since it is >fairly simple to prove yes or no, and then go on to prove the >inductive cases? Or has anyone identified a heuristic for deciding >which inductive cases to try first? Not directly, but possibly relevant work relating to dealing with inductive sub-goals is that of Bundy el al at Edinburgh (see AI Journal) or the work of Walther et al from Karlsruhe (now Darmstadt). Drop me an email if you'd like detailed references. Out of interest... Is there a particular reason why the *order* of tackling sub-goals should be particulary important? Are you trying to spot failing proofs as early as possible or are you using some kind of least-commitment strategy to solving for unknowns that make the ordering important? Andrew Received: by CLI.COM (4.1/1); Thu, 21 Oct 93 11:18:17 CDT Received: from CLOYD.CS.CORNELL.EDU by thialfi.cs.cornell.edu (5.67/I-1.99E) id AA29906; Thu, 21 Oct 93 12:18:03 -0400 Received: from LEO.CS.CORNELL.EDU by cloyd.cs.cornell.edu (5.67/I-1.99D) id AA20971; Thu, 21 Oct 93 12:18:07 -0400 Message-Id: <9310211618.AA05757@leo.cs.cornell.edu> Received: by leo.cs.cornell.edu (5.67/N-0.13) id AA05757; Thu, 21 Oct 93 12:18:01 -0400 To: J Strother Moore Cc: nqthm-users@CLI.COM Subject: Re: Inductive proofs - order of attempts In-Reply-To: Your message of "Wed, 20 Oct 93 10:09:32 CDT." <9310201509.AA07582@rana.CLI.COM> Date: Thu, 21 Oct 93 12:18:00 -0400 From: Wilfred Chen Nqthm makes no effort to order the subgoals produced by induction. Loosely speaking, the order is dictated by the recursive definition that suggested it. So (if (nlistp x) 0 (recur (cdr x))) puts the base case first while (if (listp x) (recur (cdr x)) 0) puts the induction step first. I've thought about ordering but never got anywhere. Yes, the base case is often a counterexample and is hence best attacked first. But the base case is often trivial and the user is really wants to get to the meat of the issue. The latter view often prevails if the user is iteratively submitting the formula after changes in definitions and lemmas: waiting for the system to get to the induction step is annoying because you know the preliminary cases all succeed. This argument suggests attacking them in different orders at different points in the evolving proof effort -- a injection of nondeterminism that would problably drive users crazy and argues for an alternative to the Nqthm-encouraged practice of iteratively submitting the formula to the whole process. J Instead of injecting non-determinism by dynamically reordering cases, I wonder if there is a way in which those preliminary cases can be skipped during re-evaluation due to changes, in a similar spirit to "intelligent backtracking". Or perhaps, I should call this "incremental verification": when a change is made, and a (set of) formulas resubmitted, we would like to recheck only those formulas that are affected, based on some decidable conservative estimate. Whatever that is can proabably also be applied to the checking of inductive subgoals -- although this seems to require storing some amount of the proofs. All this may seem like a lot of pain. But, if a user should ever ask "why?" about some lemma, then a similar justification structure could prove to be useful. Has this been considered before? Wilfred Received: by CLI.COM (4.1/1); Thu, 21 Oct 93 13:07:41 CDT Date: Thu, 21 Oct 93 13:07:40 CDT From: Matt Kaufmann Message-Id: <9310211807.AA22094@thunder.CLI.COM> Received: by thunder.CLI.COM (4.1/CLI-1.2) id AA22094; Thu, 21 Oct 93 13:07:40 CDT To: chen@cs.cornell.edu Cc: moore@CLI.COM, nqthm-users@CLI.COM In-Reply-To: Wilfred Chen's message of Thu, 21 Oct 93 12:18:00 -0400 <9310211618.AA05757@leo.cs.cornell.edu> Subject: Inductive proofs - order of attempts As long as the subject (of avoiding re-proving cases) has come up.... What I typically do is to use Pc-Nqthm (my interactive enhancement of Nqthm) to avoid re-proving cases. Below is a small example. If this interests you, you can get this system as follows. ftp to ftp.cli.com cd pub/proof-checker get README-pc binary get pc.tar.Z and then read the instructions in README-pc. (The "pc" is for "proof-checker".) We at CLInc are interested in who obtains and uses Nqthm and Pc-Nqthm; although only Nqthm requires a license, please let me know if you obtain Pc-Nqthm. Now for the example. Everything below is output from the system, except for comments (extending from ";" to end of line) and for lines beginning with the prompts ">" or "->". ;; Let us start by entering the interactive loop, with a goal of proving ;; the commutativity of TIMES. Incidentally, Nqthm fails to prove the ;; following goal automatically. >(verify (equal (times x y) (times y x))) ->: induct ;; use Nqthm's heuristics to obtain base and induction steps Inducting according to the scheme: (AND (IMPLIES (ZEROP X) (p X Y)) (IMPLIES (AND (NOT (ZEROP X)) (p (SUB1 X) Y)) (p X Y))) Creating 2 new subgoals, (MAIN . 1) and (MAIN . 2). The proof of the current goal, MAIN, has been completed. However, the following subgoals of MAIN remain to be proved: (MAIN . 1) and (MAIN . 2). Now proving (MAIN . 1). ->: p ;; print the current term (IMPLIES (ZEROP X) (EQUAL (TIMES X Y) (TIMES Y X))) ->: prove ;; this is a base case, so we try an automatic proof ***** Now entering the theorem prover *****: This formula simplifies, expanding the functions ZEROP, EQUAL, and TIMES, to two new conjectures: Case 2. (IMPLIES (EQUAL X 0) (EQUAL 0 (TIMES Y 0))), which again simplifies, trivially, to the new formula: (EQUAL 0 (TIMES Y 0)), which we will name *1. Case 1. (IMPLIES (NOT (NUMBERP X)) (EQUAL 0 (TIMES Y X))), which we would usually push and work on later by induction. But if we must use induction to prove the input conjecture, we prefer to induct on the original formulation of the problem. Thus we will disregard all that we have previously done, give the name *1 to the original input, and work on it. ;;;;; The prover goes on to perform an induction that contains two ;;;;; sub-inductions, which I've edited out here. That finishes the proof of *1.1, which, consequently, finishes the proof of *1. Q.E.D. The current goal, (MAIN . 1), has been proved, and has no dependents. Now proving (MAIN . 2). ->: p (IMPLIES (AND (NOT (ZEROP X)) (EQUAL (TIMES (SUB1 X) Y) (TIMES Y (SUB1 X)))) (EQUAL (TIMES X Y) (TIMES Y X))) ->: bash ;; Simplify the current goal. ***** Now entering the theorem prover's rewriter - simplifier ***** The goal has been simplified using TIMES, ZEROP, NOT, AND, and IMPLIES. Creating 1 new subgoal, ((MAIN . 2) . 1). The proof of the current goal, (MAIN . 2), has been completed. However, the following subgoal of (MAIN . 2) remains to be proved: ((MAIN . 2) . 1). Now proving ((MAIN . 2) . 1). ->: p (IMPLIES (AND (NOT (EQUAL X 0)) (NUMBERP X) (EQUAL (TIMES (SUB1 X) Y) (TIMES Y (SUB1 X)))) (EQUAL (PLUS Y (TIMES Y (SUB1 X))) (TIMES Y X))) ->: reduce ;; since the goal above seems to need more work, we call ;; on more than just the simplifier (which was used by ;; the preceding BASH command). Notice that elimination ;; is done below. (BASH T) ***** Now entering the theorem prover *****: . Applying the lemma SUB1-ELIM, replace X by (ADD1 Z) to eliminate (SUB1 X). We rely upon the type restriction lemma noted when SUB1 was introduced to restrict the new variable. We thus obtain the new formula: (IMPLIES (AND (NUMBERP Z) (NOT (EQUAL (ADD1 Z) 0)) (EQUAL (TIMES Z Y) (TIMES Y Z))) (EQUAL (PLUS Y (TIMES Y Z)) (TIMES Y (ADD1 Z)))), which simplifies, clearly, to the new goal: (IMPLIES (AND (NUMBERP Z) (EQUAL (TIMES Z Y) (TIMES Y Z))) (EQUAL (PLUS Y (TIMES Y Z)) (TIMES Y (ADD1 Z)))). We use the above equality hypothesis by substituting (TIMES Z Y) for (TIMES Y Z) and keeping the equality hypothesis. We must thus prove the goal: (IMPLIES (AND (NUMBERP Z) (EQUAL (TIMES Z Y) (TIMES Y Z))) (EQUAL (PLUS Y (TIMES Z Y)) (TIMES Y (ADD1 Z)))). This further simplifies, obviously, to: (IMPLIES (AND (NUMBERP Z) (EQUAL (TIMES Z Y) (TIMES Y Z))) (EQUAL (PLUS Y (TIMES Y Z)) (TIMES Y (ADD1 Z)))), which we will name *1. The goal has been simplified using SUB1-ELIM, NOT, AND, and IMPLIES. Creating 1 new subgoal, (((MAIN . 2) . 1) . 1). The proof of the current goal, ((MAIN . 2) . 1), has been completed. However, the following subgoal of ((MAIN . 2) . 1) remains to be proved: (((MAIN . 2) . 1) . 1). Now proving (((MAIN . 2) . 1) . 1). ->: goals ;; Where are we? (((MAIN . 2) . 1) . 1) ;; Good, we have only one goal to prove. ->: p (IMPLIES (AND (NUMBERP Z) (EQUAL (TIMES Z Y) (TIMES Y Z))) (EQUAL (PLUS Y (TIMES Y Z)) (TIMES Y (ADD1 Z)))) ->: exit ;; The current goal suggests a useful rewrite rule, so we ;; exit the interactive loop and attempt to prove such a rule. Quitting the interactive proof checker. Submit (VERIFY) to get back in at this state. **NOTE** -- No event has been stored. NIL >(prove-lemma times-add1 (rewrite) (equal (times y (add1 z)) (plus y (times y z)))) Give the conjecture the name *1. ;;;;; Proof successful, and omitted here. That finishes the proof of *1. Q.E.D. [ 0.0 0.1 0.1 ] TIMES-ADD1 >(verify) ;; Re-enter the interactive loop where we left off ->: bash ;; Now let's try further simplification, in the presence of ;; our new rewrite rule. ***** Now entering the theorem prover's rewriter - simplifier ***** The current goal has been proved, without the creation of new subgoals. The goal has been simplified using TIMES-ADD1, AND, and IMPLIES. The current goal, (((MAIN . 2) . 1) . 1), has been proved, and has no dependents. *!*!*!*!*!*!* All goals have been proved! *!*!*!*!*!*!* You may wish to EXIT -- type (HELP EXIT) for details. ->: exit ;; I could create an event here that has a hint appropriate for ;; Pc-Nqthm, but I prefer at this point to exit the interactive ;; loop and hope that Nqthm can get the proof on its own. That ;; seems likely, since I've only used Nqthm-like commands in the ;; interactive loop. (Lower-level commands, such as a command ;; to expand and simplify the current function call, are available.) Quitting the interactive proof checker. Submit (VERIFY) to get back in at this state. **NOTE** -- No event has been stored. NIL ;; In fact, the proof succeeds now! >(prove-lemma times-comm (rewrite) (equal (times x y) (times y x))) WARNING: the newly proposed lemma, TIMES-COMM, could be applied whenever the previously added lemma TIMES-ADD1 could. Give the conjecture the name *1. We will appeal to induction. Two inductions are suggested by terms in the conjecture, both of which are flawed. We limit our consideration to the two suggested by the largest number of nonprimitive recursive functions in the conjecture. Since both of these are equally likely, we will choose arbitrarily. We will induct according to the following scheme: (AND (IMPLIES (ZEROP X) (p X Y)) (IMPLIES (AND (NOT (ZEROP X)) (p (SUB1 X) Y)) (p X Y))). Linear arithmetic, the lemma COUNT-NUMBERP, and the definition of ZEROP inform us that the measure (COUNT X) decreases according to the well-founded relation LESSP in each induction step of the scheme. The above induction scheme produces the following two new conjectures: Case 2. (IMPLIES (ZEROP X) (EQUAL (TIMES X Y) (TIMES Y X))). This simplifies, expanding the functions ZEROP, EQUAL, and TIMES, to the following two new conjectures: Case 2.2. (IMPLIES (EQUAL X 0) (EQUAL 0 (TIMES Y 0))). This again simplifies, obviously, to: (EQUAL 0 (TIMES Y 0)), which we will name *1.1. Case 2.1. (IMPLIES (NOT (NUMBERP X)) (EQUAL 0 (TIMES Y X))). Name the above subgoal *1.2. Case 1. (IMPLIES (AND (NOT (ZEROP X)) (EQUAL (TIMES (SUB1 X) Y) (TIMES Y (SUB1 X)))) (EQUAL (TIMES X Y) (TIMES Y X))). This simplifies, opening up ZEROP and TIMES, to the new conjecture: (IMPLIES (AND (NOT (EQUAL X 0)) (NUMBERP X) (EQUAL (TIMES (SUB1 X) Y) (TIMES Y (SUB1 X)))) (EQUAL (PLUS Y (TIMES Y (SUB1 X))) (TIMES Y X))). Applying the lemma SUB1-ELIM, replace X by (ADD1 Z) to eliminate (SUB1 X). We employ the type restriction lemma noted when SUB1 was introduced to restrict the new variable. This produces the new conjecture: (IMPLIES (AND (NUMBERP Z) (NOT (EQUAL (ADD1 Z) 0)) (EQUAL (TIMES Z Y) (TIMES Y Z))) (EQUAL (PLUS Y (TIMES Y Z)) (TIMES Y (ADD1 Z)))), which further simplifies, rewriting with TIMES-ADD1, to: T. So we now return to: (IMPLIES (NOT (NUMBERP X)) (EQUAL 0 (TIMES Y X))), which is formula *1.2 above. We will appeal to induction. There is only one plausible induction. We will induct according to the following scheme: (AND (IMPLIES (ZEROP Y) (p Y X)) (IMPLIES (AND (NOT (ZEROP Y)) (p (SUB1 Y) X)) (p Y X))). Linear arithmetic, the lemma COUNT-NUMBERP, and the definition of ZEROP inform us that the measure (COUNT Y) decreases according to the well-founded relation LESSP in each induction step of the scheme. The above induction scheme generates the following two new goals: Case 2. (IMPLIES (AND (ZEROP Y) (NOT (NUMBERP X))) (EQUAL 0 (TIMES Y X))). This simplifies, unfolding ZEROP, EQUAL, and TIMES, to: T. Case 1. (IMPLIES (AND (NOT (ZEROP Y)) (EQUAL 0 (TIMES (SUB1 Y) X)) (NOT (NUMBERP X))) (EQUAL 0 (TIMES Y X))). This simplifies, expanding the functions ZEROP, TIMES, NUMBERP, PLUS, and EQUAL, to: T. That finishes the proof of *1.2. So we now return to: (EQUAL 0 (TIMES Y 0)), named *1.1 above. We will appeal to induction. There is only one plausible induction. We will induct according to the following scheme: (AND (IMPLIES (ZEROP Y) (p Y)) (IMPLIES (AND (NOT (ZEROP Y)) (p (SUB1 Y))) (p Y))). Linear arithmetic, the lemma COUNT-NUMBERP, and the definition of ZEROP can be used to prove that the measure (COUNT Y) decreases according to the well-founded relation LESSP in each induction step of the scheme. The above induction scheme produces two new goals: Case 2. (IMPLIES (ZEROP Y) (EQUAL 0 (TIMES Y 0))), which simplifies, expanding the functions ZEROP, TIMES, and EQUAL, to: T. Case 1. (IMPLIES (AND (NOT (ZEROP Y)) (EQUAL 0 (TIMES (SUB1 Y) 0))) (EQUAL 0 (TIMES Y 0))), which simplifies, unfolding ZEROP, TIMES, PLUS, and EQUAL, to: T. That finishes the proof of *1.1, which finishes the proof of *1. Q.E.D. [ 0.0 0.2 0.4 ] TIMES-COMM > -- Matt Kaufmann Received: by CLI.COM (4.1/1); Wed, 1 Dec 93 09:35:17 CST Received: by inet; Wed Dec 1 10:33 EST 1993 Received: by hunny.research.att.com (/\==/\ Smail3.1.25.1 #25.11) id ; Wed, 1 Dec 93 10:35 EST Received: by lutece.research.att.com (/\==/\ Smail3.1.25.1 #25.1) id ; Wed, 1 Dec 93 10:35 EST Message-Id: Date: Wed, 1 Dec 93 10:35 EST From: felty@research.att.com (Amy Felty) To: nqthm-users@cli.com Subject: REMINDER: LICS'94 submission deadline Ninth Annual IEEE Symposium on LOGIC IN COMPUTER SCIENCE July 4-7, 1994, Paris, France SUBMISSION DEADLINE: December 13, 1993 10 hard copies of a detailed abstract (not a full paper) and 20 additional copies of the cover page should be received by December 13, 1993 by the program chair. This is a FIRM DEADLINE: late submissions will not be considered. Program Chair: Samson Abramsky, Attn: LICS, Department of Computing, Imperial College of Science, Technology and Medicine, 180 Queen's Gate, London SW7 2BZ, United Kingdom, sa@doc.ic.ac.uk, Phone: (010-44) 71-589-5111 ext. 5005, Fax: (010-44) 71-581-8024 The full announcement can be obtained by anonymous ftp from research.att.com, directory /dist/lics, or by emailing lics-request@research.att.com. Received: by CLI.COM (4.1/1); Fri, 10 Dec 93 04:51:03 CST Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from inf.fu-berlin.de (160.45.110.10) with smtp id ; Fri, 10 Dec 93 11:38 MET Received: by inf.fu-berlin.de (/\==/\ Smail3.1.28.1) from inf.fu-berlin.de [160.45.111.53] with smtp id ; Fri, 10 Dec 93 11:40 MET Received: by inf.fu-berlin.de (/\==/\ Smail3.1.28.1) id ; Fri, 10 Dec 93 11:37 MET Message-Id: Date: Fri, 10 Dec 93 11:37 MET From: weberwu@inf.fu-berlin.de (Debora Weber-Wulff) To: nqthm-users@inf.fu-berlin.de Subject: Etudes for NQTHM Content-Type: X-sun-attachment ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 19 Hello everybody! Traffic's been a little slow lately ;-) so I thought I'd give folks something to do over Christmas. While I was at CLInc this summer I collected some exercises using NQTHM that I've put together as "NQTHM Etudes". I'm enclosing the etudes in this letter, after Christmas I'll post a file containing solutions. If anyone out there has *worked* solutions to little problems using NQTHM, I'd love to have a copy. Please mail to me at dww@inf.fu-berlin.de or my new address weberwu@tfh-berlin.de. Happy Holidays! Debbie Weber-Wulff FB Informatik Technische Fachhochschule Berlin ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: nqthm-etudes X-Sun-Content-Lines: 507 ;; ;; NQTHM Etudes ;; ;; ;; This is a collection of NQTHM-exercises I collected at CLInc in August 1993. ;; I feel that a collection of "etudes" or finger exercises that demonstrate ;; one particular point of using the theorem prover will be valuable for those ;; who want to learn to use NQTHM. Also, other theorem provers may want to ;; adapt these or similar exercises for teaching the use of their own systems. ;; I welcome suggestions for further exercises! ;; ;; Special thanks to Matt Kaufmann and Bill Bevier for their giving me their ;; collections of exercises and lots of advice on the solutions, and to Simon ;; Read for the pebble game. ;; ;; Debora Weber-Wulff, December 1993 ;; Technische Fachhochschule Berlin ;; weberwu@tfh-berlin.de ;; ;; ;; --------------------------------------------------------------------------- ;; ------------- Exercise 1: The Towers of Hanoi ----------------------------- ;; 1. The following function represents the ``Towers of Hanoi'' game. ;; Prove the lemma LENGTH-HANOI below, which states that the length of a ;; solution for n discs is equal to 2^n -1. ;; --------------------------------------------------------------------------- (boot-strap nqthm) (defn hanoi (from help to n) (if (zerop n) nil (append (hanoi from to help (sub1 n)) (cons (cons from to) (hanoi help from to (sub1 n)))))) (defn exp (i j) (if (zerop j) 1 (times i (exp i (sub1 j))))) (defn length (x) (if (listp x) (add1 (length (cdr x))) 0)) ;; -----------> Your events go here! (prove-lemma length-hanoi (rewrite) (implies (numberp n) (equal (length (hanoi a b c n)) (sub1 (exp 2 n))))) ;; --------------------------------------------------------------------------- ;; ------------- Exercise 2: Reverse and Pairlist --------------------------- ;; --------------------------------------------------------------------------- (boot-strap nqthm) ;; Given the following definitions (defn rev1 (x acc) (if (nlistp x) acc (rev1 (cdr x) (cons (car x) acc)))) (defn reverse (x) (rev1 x nil)) ;; and the definition of PAIRLIST from (BOOT-STRAP NQTHM), formulate and ;; prove a lemma about (pairlist (reverse keys) values). Note: try ;; (PPE 'PAIRLIST) to see the definition of PAIRLIST. ;; -----------> Your events go here! ;; --------------------------------------------------------------------------- ;; ------------- Exercise 3: Factorial -------------------------------------- ;; --------------------------------------------------------------------------- ;; Prove appropriate lemmas in order to prove the equivalence of the two ;; definitions of the factorial function. factorial is tail-recursive, ;; fact1 uses an "accumulator" parameter. ;; You will either have to prove a few facts about TIMES, or else you can ;; load a naturals library instead of doing the boot-strap. On my machine ;; it is called ;; (note-lib "/home/macho/weberwu/bm/nqthm-libs/naturals") (boot-strap nqthm) (defn factorial (n) (if (zerop n) 1 (times n (factorial (sub1 n))))) (defn fact1 (n acc) (if (zerop n) acc (fact1 (sub1 n) (times n acc)))) (defn fact (n) (fact1 n 1)) ;; -----------> Your events go here! (prove-lemma fact-factorial (rewrite) (equal (fact n) (factorial n))) ;; --------------------------------------------------------------------------- ;; ------------- Exercise 4: Powerset -------------------------------------- ;; --------------------------------------------------------------------------- ;; Complete the following script, which defines and proves a couple of ;; properties of a list version of the ``power set'' operator. (In set ;; theory, the power set of a set is the set of all its subsets.) ;; Use a library of facts about sets and subsets. I used a version called (note-lib "/home/macho/weberwu/bm/nqthm-libs/sets") (defn cons-to-all (a x) (if (listp x) (cons (cons a (car x)) (cons-to-all a (cdr x))) nil)) (defn powerset (x) (if (listp x) (let ((p (powerset (cdr x)))) (append p (cons-to-all (car x) p))) (list nil))) (defn exp (i j) (if (zerop j) 1 (times i (exp i (sub1 j))))) ;; -----------> Your events go here! (prove-lemma length-powerset (rewrite) (equal (length (powerset x)) (exp 2 (length x)))) (prove-lemma powerset-append-1 (rewrite) (subsetp (powerset x) (powerset (append x y)))) ;; Now state and prove that powerset "works", i.e. all subsets of s are ;; members of the powerset of s. This is not a trivial task! ;; -----------> Your events go here! ;; --------------------------------------------------------------------------- ;; ------------- Exercise 5: The Pebble Game---------------------------------- ;; --------------------------------------------------------------------------- ;; Here is part of a proof script developed by Simon Read (with some help ;; from Matt Kaufmann). The game is described in Gries, "The Science of ;; Programming". It seems to have been first proposed by Dijkstra. ;; [Debbie and Matt had a *long* discussion about the necessity for the oracle ;; in order to play this game, neither could convince the other. ;; The problem centers on the representation of mathematical sets as lists, ;; and on the representation of "non-determinism", i.e. picking a pebble. ;; ;; Some comments made by Simon have been left in the script. ;; ;; The game is that one has an urn with black and white pebbles in it. ;; If there is at most one pebble in the urn, the game is over. ;; Otherwise, a move is to take two pebbles out of the urn and then put a ;; pebble into the urn according to the following rule: ;; - if the two pebbles have the same color, ;; put a black pebble into the urn; ;; - otherwise put a white pebble into the urn. ;; Notice that if the urn is non-empty to start with, the game will ;; continue until a single pebble remains in the urn. ;; The theorem is that if the urn has an even number of white pebbles ;; to start with, then the final pebble in the urn is black. (boot-strap nqthm) (defn take-out (e l) (if (nlistp l) l (if (equal e (car l)) (cdr l) (cons (car l) (take-out e (cdr l)))))) (defn length (urn) (if (nlistp urn) 0 (add1 (length (cdr urn))))) (defn only-one-thing-in (urn) (nlistp (cdr urn))) ;; Normally I would make the following definition so that there is no ;; special case for only-one-thing-in, but this way we are guaranteed ;; that nth returns an element of the urn (if the urn has at least one ;; element). (defn nth (n urn) (if (or (zerop n) (only-one-thing-in urn)) (car urn) (nth (sub1 n) (cdr urn)))) ;; Pebbles must be black or white. (defn pebblep (pebble) (or (equal pebble 'black) (equal pebble 'white))) ;; An urn must contain something. ;; If there's only one thing in the urn then it must be a pebble. ;; If there's more than one thing it an urn if: ;; 1. you take something out and it's a pebble. ;; 2. What's left is an urn. (defn urnp (urn) (if (listp urn) (and (pebblep (car urn)) (urnp (cdr urn))) (equal urn nil))) ;; The basic rule of the game is if the two pebbles are the same we put ;; back a black one. Otherwise we put back a white one. ;; I choose to have rule return a single pebble, rather than a list of ;; 1 pebble; it just seems more "primitive" this way, somehow. (defn rule (first second) (if (equal first second) 'black 'white)) ;; When does an urn have an even number of white pebbles in it? (defn evenwhitep (urn) (if (nlistp urn) t (iff (equal (car urn) 'black) (evenwhitep (cdr urn))))) ;; When we've got just one pebble in our hand we've got to get another ;; one, and put back the one that the rule gives us, and that's our new urn. (defn got-one-pebble (first urn oracle) (cons (rule first (nth (car oracle) urn)) (take-out (nth (car oracle) urn) urn))) ;; When we haven't got any we have to get a pebble, and do what we ;; should do when we've got a pebble. (defn got-no-pebbles (urn oracle) (got-one-pebble (nth (car oracle) urn) (take-out (nth (car oracle) urn) urn) (cdr oracle))) ;; The following lemmas help with getting the definition of pebble-game ;; accepted. (prove-lemma take-out-leaves-one-fewer-things (rewrite) (implies (listp urn) (equal (length (take-out (nth x urn) urn)) (sub1 (length urn))))) ;; If there's something in the urn then doing the one-pebble action ;; keeps the *number* of pebbles in the urn the same. (prove-lemma got-one-pebble-maintains-number-of-things (rewrite) (implies (listp urn) (equal (length (got-one-pebble x urn oracle)) (length urn)))) ;; If there's more than one thing in the urn then there's still ;; something in it if we take something out. (prove-lemma take-out-leaves-something (rewrite) (implies (not (only-one-thing-in urn)) (listp (take-out x urn)))) ;; If we take something out of a non-empty urn, then there's fewer ;; things in the urn. (prove-lemma take-out-leaves-fewer-things (rewrite) (implies (listp urn) (lessp (length (take-out (nth x urn) urn)) (length urn)))) ;; If there are at least two things in the urn, then doing the no-pebble ;; action decreases the number of pebbles in the urn. (prove-lemma got-no-pebbles-decreases-number-of-things (rewrite) (implies (not (only-one-thing-in urn)) (lessp (length (got-no-pebbles urn oracle)) (length urn))) ((disable got-one-pebble))) ;; When proving that this definition terminates the theorem prover is ;; told not to try to use the definitions of the two actions, only the ;; lemmas about them. (disable got-no-pebbles) (defn pebble-game (urn oracle) (if (only-one-thing-in urn) urn (pebble-game (got-no-pebbles urn oracle) (cdr (cdr oracle)))) ((lessp (length urn))) ; This is a hint saying use induction ; on the number of things in the urn ; to show termination. ) ;; Let's turn the definition of got-no-pebbles back on, unless ;; we find that this gets us into trouble. (enable got-no-pebbles) ;; -----------> Your events go here! ;; Our ultimate goal: ;; Given a valid starting position, if there are an even number of ;; whites in the urn, then the result is a black pebble, otherwise ;; the result is a white one. (prove-lemma pebble-game-result (rewrite) (implies (and (listp urn) (urnp urn)) (equal (pebble-game urn oracle) (if (evenwhitep urn) '(black) '(white))))) ;; --------------------------------------------------------------------------- ;; ------------- Exercise 6: Subsequence ------------------------------------- ;; --------------------------------------------------------------------------- ;; Here's a really tricky one. [Debbie spent 2 1/2 days fussing with this one ;; proving all sorts of interesting but unhelpful lemmata before she gave up ;; and asked Matt, who of course was able to solve it in 10 minutes ;-) ] ;; Without using any libraries, define the notion `x is a subsequence of y' ;; (i.e., if you punch the right holes in y then you get x), and ;; prove the following two lemmas. (By the way, Matt ignored the issue of ;; final CDRs when he did this.) ;; ******************************************* ;; *** JUST TO EMPHASIZE: THIS IS TRICKY! *** ;; ******************************************* ;; Here is Matts's original definition, based on the notion that a list ;; represents a sequence if we ignore its final CDR. However, in order ;; to get the proofs to go through without induction hints, he follows a ;; suggestion by Laurence Pierre on hiding the IF structure in order to ;; make more hypotheses available in cases in a proof by induction. ;; (defn subseq (x y) ;; (if (nlistp x) ;; t ;; (if (nlistp y) ;; f ;; (if (equal (car x) (car y)) ;; (subseq (cdr x) (cdr y)) ;; (subseq x (cdr y)))))) (defn subseq (x y) (if (nlistp x) t (if (nlistp y) f (or (and (equal (car x) (car y)) (subseq (cdr x) (cdr y))) (and (not (equal (car x) (car y))) (subseq x (cdr y))))))) ;; -----------> Your events go here! (prove-lemma subseq-cons-1 (rewrite) (implies (subseq (cons a x) y) (subseq x y))) (prove-lemma subseq-cons-2 (rewrite) (implies (subseq x y) (subseq x (cons b y)))) ;; --------------------------------------------------------------------------- ;; ------------- Exercise 7: Condensing ------------------------------------- ;; --------------------------------------------------------------------------- ;; Define a function (CONDENSE L) which takes a list L and eliminates ;; multiple consecutive occurrences of the same value. ;; ;; E.g., (condense '(a a a b b c c c a d)) = '(a b c a d) ;; ;; Define a function (CONDENSED L1 L2) which decides if L1 is a ;; (partially) condensed version of L2. That is, whereever L2 has ;; repeated consecutive values, L1 has the same number or fewer. ;; ;; E.g. (condensed '(a a b c c a a) '(a a a b b c c a a a)) = T ;; (condensed '(a a) '(a)) = F ;; ;; Prove the following: ;; ;; 1. (implies (condensed l1 l2) (equal (condense l1) (condense l2))) ;; ;; 2. (condensed (condense l) l) ;; ;; -----------> Your events go here! ;; Can you prove that condended is a reflexive and transitive function? ;; -----------> Your events go here! ;; --------------------------------------------------------------------------- ;; --------------------------------------------------------------------------- ;; ------------- Exercise 8 : Positional Notation --------------------------- ;; --------------------------------------------------------------------------- ;; The positional notation for a natural number in a given base is a list of ;; natural numbers, call them "digits", where each digit is less than the ;; value of the base. The high-order digits occur at the end of the list. For ;; instance, the positional notation for the integer 16 is as follows: ;; ;; BASE POSITIONAL NOTATION ;; ---- ------------------- ;; 10 (6 1) ;; 2 (0 0 0 0 1) ;; ;; The function NAT-TO-PN computes the positional notation for a natural ;; number n in base b. The function PN-TO-NAT takes the positional notation ;; for a natural number n in base b and uses the Horner method to ;; calculate the value. ;; Exercise: state and prove the two theorems that say that NAT-TO-PN ;; and PN-TO-NAT invert each other. ;; ;; Given: The following lemmata about the natural numbers ;; and the function definitions nat-to-pn and pn-to-nat ;; --------------- Lemmata from a natural numbers library ------------------ (prove-lemma commutativity-of-plus (rewrite) (equal (plus x y) (plus y x))) (prove-lemma times-zero (rewrite) (implies (zerop y) (equal (times x y) 0))) (prove-lemma times-add1 (rewrite) (equal (times x (add1 y)) (if (numberp y) (plus x (times x y)) (fix x)))) ; fix coerces non-numbers to zero (prove-lemma plus-remainder-times-quotient (rewrite) (equal (plus (remainder x y) (times y (quotient x y))) (fix x))) (prove-lemma lessp-quotient (rewrite) (equal (lessp (quotient i j) i) (and (not (zerop i)) (not (equal j 1))))) (prove-lemma commutativity-of-times (rewrite) (equal (times y x) (times x y))) ;; --------------- The function definitions ------------------------- (defn nat-to-pn (n b) (if (lessp 1 b) (if (zerop n) nil (cons (remainder n b) (nat-to-pn (quotient n b) b))) nil)) (defn pn-to-nat (l b) (if (listp l) (plus (car l) (times (pn-to-nat (cdr l) b) b)) 0)) ;; -----------> Your events go here! ;; ---------------------------------------------------------------------------