From owner-reliable_computing [at] interval [dot] usl.edu Wed Mar 1 07:48:24 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id HAA12466 for reliable_computing-outgoing; Wed, 1 Mar 2000 07:48:24 -0600 (CST) Received: from mscs.mu.edu (studsys.mscs.mu.edu [134.48.4.15]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with SMTP id HAA12460 for ; Wed, 1 Mar 2000 07:48:19 -0600 (CST) Received: (qmail 20001 invoked from network); 1 Mar 2000 13:45:54 -0000 Received: from ppp101.csd.mu.edu (HELO mscs.mu.edu) (134.48.24.1) by studsys.mscs.mu.edu with SMTP; 1 Mar 2000 13:45:54 -0000 Message-ID: <38BD1F6C.9F24BDB3 [at] mscs [dot] mu.edu> Date: Wed, 01 Mar 2000 07:47:24 -0600 From: George Corliss Organization: Marquette University X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: reliable_computing [at] interval [dot] usl.edu CC: anupama.govindarajan [at] tatainfotech [dot] com, Xin Feng Subject: Training Neural Network with back propagation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Forwarded from ANUPAMA V.GOVINDARAJAN: > > Dear Professor Corliss, > > I am working on an Artificial Intelligence related experiment dealing with > pattern recognition in Uncertainity. We plan to train a Neural network > (using backpropagation algorithm) to recognize inputs with missing data. > We would like to use interval arithmetic to represent the uncertainity and > train the network > > I would like to find information on modifying the backpropagation > algorithm to include > intervals instead of crisp inputs during the > training phase > > Also I would be grateful if you could put me in touch with Dr Xin Feng and > Dr Richard Kelnhoffer - Marquette Dept of Electrical and Computer > Engineering who are using interval arithmetic in Artificial Neural > Networks > > Thank You, > Anupama > > ---- > Anupama Govindarajan > Associate Systems Engineer - Expert Systems > Applied Technology Group > Tata Infotech Ltd > SDF 5, Seepz, Andheri(E), Mumbai - 400096 > India > > ph: +91-22-8291317/ 8291320 Ext 645 > email: anupama.govindarajan [at] tatainfotech [dot] com > anupama.g [at] ieee [dot] org -- Dr. George F. Corliss Dept. Math, Stat, Comp Sci Marquette University P.O. Box 1881 Milwaukee, WI 53201-1881 USA georgec [at] mscs [dot] mu.edu; George.Corliss [at] Marquette [dot] edu http://www.mscs.mu.edu/~georgec/ Office: 414-288-6599; Dept: 288-7375; Fax: 288-5472 From owner-reliable_computing [at] interval [dot] usl.edu Wed Mar 1 10:00:58 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id KAA12888 for reliable_computing-outgoing; Wed, 1 Mar 2000 10:00:58 -0600 (CST) Received: from happy.dt.uh.edu (happy.dt.uh.edu [129.7.174.25]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with SMTP id KAA12883 for ; Wed, 1 Mar 2000 10:00:52 -0600 (CST) Received: by happy.dt.uh.edu (950413.SGI.8.6.12/940406.SGI.AUTO) id JAA28863; Wed, 1 Mar 2000 09:34:11 -0800 From: "Chenyi Hu" Message-Id: <10003010934.ZM28861 [at] happy [dot] dt.uh.edu> Date: Wed, 1 Mar 2000 09:34:10 -0800 In-Reply-To: George Corliss "Training Neural Network with back propagation" (Mar 1, 7:47am) References: <38BD1F6C.9F24BDB3 [at] mscs [dot] mu.edu> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: reliable_computing [at] interval [dot] usl.edu Subject: Re: Training Neural Network with back propagation Cc: Xin Feng , anupama.govindarajan [at] tatainfotech [dot] com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Our paper "On Interval Weighted Three-layer Neural Networks" could be a reference. You may find it in the Proceedings of the 31 Annual Simulation Symposium, pp. 188-194, IEEE Computer Society Press, 1998. It is also available at the URL: http://happy.dt.uh.edu/~hu/Papers/IEEESimu98.ps Chenyi HU On Mar 1, 7:47am, George Corliss wrote: > Subject: Training Neural Network with back propagation > Forwarded from ANUPAMA V.GOVINDARAJAN: > > > > Dear Professor Corliss, > > > > I am working on an Artificial Intelligence related experiment dealing with > > pattern recognition in Uncertainity. We plan to train a Neural network > > (using backpropagation algorithm) to recognize inputs with missing data. > > We would like to use interval arithmetic to represent the uncertainity and > > train the network > > > > I would like to find information on modifying the backpropagation > > algorithm to include > intervals instead of crisp inputs during the > > training phase > > > > Also I would be grateful if you could put me in touch with Dr Xin Feng and > > Dr Richard Kelnhoffer - Marquette Dept of Electrical and Computer > > Engineering who are using interval arithmetic in Artificial Neural > > Networks > > > > Thank You, > > Anupama > > > > ---- > > Anupama Govindarajan > > Associate Systems Engineer - Expert Systems > > Applied Technology Group > > Tata Infotech Ltd > > SDF 5, Seepz, Andheri(E), Mumbai - 400096 > > India > > > > ph: +91-22-8291317/ 8291320 Ext 645 > > email: anupama.govindarajan [at] tatainfotech [dot] com > > anupama.g [at] ieee [dot] org > > -- > Dr. George F. Corliss > Dept. Math, Stat, Comp Sci > Marquette University > P.O. Box 1881 > Milwaukee, WI 53201-1881 USA > georgec [at] mscs [dot] mu.edu; George.Corliss [at] Marquette [dot] edu > http://www.mscs.mu.edu/~georgec/ > Office: 414-288-6599; Dept: 288-7375; Fax: 288-5472 >-- End of excerpt from George Corliss -- Ph.D., Associate Professor, Computer and Mathematical Sciences Center for Computational Science and Advanced Distributed Simulation University of Houston-Downtown Phone: 713 221-8414 One Main Street Fax: 713 221-8086 Houston, Texas 77002 E-mail: CHu [at] uh [dot] edu http://happy.dt.uh.edu/~hu/Hu.html From owner-reliable_computing [at] interval [dot] usl.edu Fri Mar 3 12:30:57 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id MAA17657 for reliable_computing-outgoing; Fri, 3 Mar 2000 12:30:57 -0600 (CST) Received: from lua.dimap.ufrn.br (IDENT:root [at] lua [dot] dimap.ufrn.br [200.19.160.19]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id MAA17652 for ; Fri, 3 Mar 2000 12:30:42 -0600 (CST) Received: from dimap.ufrn.br (baltazar.dimap.ufrn.br [10.9.96.16]) by lua.dimap.ufrn.br (8.9.1a/8.9.2) with ESMTP id PAA02204 for ; Fri, 3 Mar 2000 15:35:09 -0300 Received: from localhost (regivan@localhost) by dimap.ufrn.br (8.9.1/8.9.2) with SMTP id PAA03744 for ; Fri, 3 Mar 2000 15:17:56 -0300 (EST) Date: Fri, 3 Mar 2000 15:17:56 -0300 (EST) From: Regivan Hugo Nunes Santiago X-Sender: regivan@baltazar To: reliable_computing [at] interval [dot] usl.edu Subject: Scan 2000 and INTERVAL'2000 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Dear Intervalers, I did not found the format of submissions of abstracts for Scan 2000 and Interval'2000 is it free? or does it have any limit of pages, format, etc. Regards Regivan From owner-reliable_computing [at] interval [dot] usl.edu Sat Mar 4 15:57:32 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id PAA20087 for reliable_computing-outgoing; Sat, 4 Mar 2000 15:57:32 -0600 (CST) Received: from cse.unl.edu (root [at] cse [dot] unl.edu [129.93.33.1]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id PAA20082 for ; Sat, 4 Mar 2000 15:57:29 -0600 (CST) Received: from localhost (fayad@localhost) by cse.unl.edu (8.9.1/8.9.1) with ESMTP id PAA1075747; Sat, 4 Mar 2000 15:40:14 -0600 (CST) Date: Sat, 4 Mar 2000 15:40:14 -0600 From: Mohamed Fayad To: Undisclosed recipients: ; Subject: Enterprise Frameworks - CFPs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Dear Colleagues, You will be doing us a great favor if you disseminate the content of this Call for Papers among your interested colleagues. Please accept our apologies if you receive multiple copies of this announcement. Cheers, M. E. Fayad --------------------------------------------------------------------- *** Papers submission deadline for the theme issue *** *** >>>>> August 1, 2000 <<<<< *** --------------------------------------------------------------------- Software Practice & Experience Journal - Theme Issue Call for Articles and Reviewers on Enterprise Frameworks Editors: Dr. Mohamed Fayad -- fayad [at] cse [dot] unl.edu, m.fayad [at] computer [dot] org, fayadm [at] acm [dot] org David S. Hamu -- dhamu [at] ix [dot] netcom.com, dhamu [at] acm [dot] org Davide Brugali -- brugali [at] polito [dot] it, dbrugali [at] acm [dot] org Software Practice & Experience Journal seeks articles and reviewers for this theme issue, scheduled for publication in March 2001. For more journal information, check the following link: http://www.interscience.wiley.com/jpages/0038-0644 An Object-Oriented Enterprise Framework (Enterprise Framework for short) is a software architecture exposing a rich set of semantics and modeling paradigms for developing and extending enterprise applications. Enterprise frameworks are, by design, the cornerstone of an organization's systems engineering activities. Enterprise frameworks offer a streamlined and flexible alternative to traditional tools and applications, which feature numerous point solutions integrated into complex and often inflexible environments. Enterprise Frameworks play an important role since they allow reuse of design knowledge and offer techniques for creating reference models and scalable architectures for enterprise integration. These models and architectures are sufficiently flexible and powerful to be used at multiple levels, e.g. from the integration of the supply chain of a multi-national corporation, to the construction of a global virtual factory, and down to the monitoring and control system for a single production cell. These frameworks implement and enforce well-documented standards for component integration and collaboration. The architecture of an Enterprise framework provides for ready integration with new or existing components. It defines how these components must interact with the framework and how objects collaborate. In addition, it defines how developers work together to build and extend enterprise applications based on the framework. Therefore, the goal of an Enterprise framework is to reduce complexity and lifecycle costs of enterprise systems, while ensuring flexibility. The theme issue is designed to help organizations effectively develop or adapt enterprise framework technology in the real world. As such, we are seeking submissions which provide a treatment of: + Comprehensive technical and management guidelines: ranging from specifying enterprise framework structures and behaviors, to cost estimation and selecting the right enterprise framework and tools for the job. + Technical issues such as documenting frameworks and how to utilize enterprise frameworks. + Real world issues such as keeping your expensive framework up-to-date, ferreting out hidden costs, grappling with the problems of frameworks, and providing insight into successful development or adaptation of OO Enterprise Frameworks. + Limitations such as maintaining frameworks and adding value to your business. Submissions will be presented in a practical, easy to understand manner. This is information that readers can apply today. We seek original articles on specific issues related to enterprise frameworks that might be addressed include (but are not limited to): 1. What are the key enterprise-oriented framework issues? 2. How to develop enterprise frameworks and what are the framework design guidelines? 3. What kind of evolution does an Enterprise Framework undergo and how is it correlated with the enterprise life span? 4. How can the adaptation of OO enterprise framework be accomplished with minimum impact on the cost and schedule? 5. Understand make vs. buy decisions, selection guidelines, and how to select and adapt the right enterprise framework for the job. 6. Understand the implication of enterprise business requirements on the framework design. 7. How to use your large-scale enterprise framework and how to protect your investment. 8. How to deal with resource requirements, enterprise framework integration problems, framework reporting, and others. 9. What are the impacts of enterprise frameworks on the national and global economy? Reviewers: Please e-mail your contact information and your area of interests to the lead editor. Authors: Please submit one electronic copy in RTF interchange or Microsoft Word document formats by August 1, 2000 to the lead guest editor: Dr. Mohamed E. Fayad J.D. Edwards Professor Computer Science & Engineering Dept., University of Nebraska, Lincoln 108 Ferguson Hall, P.O. Box 880115, Lincoln, NE 68588-0115 Ph: (402) 472-2615, Fax: (402) 472-7767 E-mail: fayad [at] cse [dot] unl.edu, m.fayad [at] computer [dot] org, fayadm [at] acm [dot] org URL: http://www.cse.unl.edu/~fayad Articles may be of any length, ranging from a few pages (2-3 pages or 1,200 words) to a full treatment of a substantial software system or an enterprise framework (say 40 pages or 25,000 words), including illustrations. Submissions are peer-reviewed and are subject to editing for style, clarity, and space. For detailed author guidelines, check the following web site: http://www.interscience.wiley.com/jpages/0038-0644/authors.html or www.cse.unl.edu/~fayad Theme Issues From owner-reliable_computing [at] interval [dot] usl.edu Mon Mar 6 05:00:53 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id FAA23706 for reliable_computing-outgoing; Mon, 6 Mar 2000 05:00:53 -0600 (CST) Received: from iamk4510.mathematik.uni-karlsruhe.de (root [at] iamk4510 [dot] mathematik.uni-karlsruhe.de [129.13.129.10]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id FAA23701 for ; Mon, 6 Mar 2000 05:00:49 -0600 (CST) Received: from math.uni-karlsruhe.de (axel@localhost [127.0.0.1]) by iamk4510.mathematik.uni-karlsruhe.de (8.9.3/8.9.3) with ESMTP id MAA24596; Mon, 6 Mar 2000 12:00:40 +0100 Message-ID: <38C38FD8.21D7876A [at] math [dot] uni-karlsruhe.de> Date: Mon, 06 Mar 2000 12:00:40 +0100 From: Axel Facius X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i686) X-Accept-Language: en MIME-Version: 1.0 To: reliable_computing [at] interval [dot] usl.edu CC: Regivan Hugo Nunes Santiago Subject: Re: Scan 2000 and INTERVAL'2000 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Regivan Hugo Nunes Santiago wrote: > > Dear Intervalers, I did not found the format of submissions > of abstracts for Scan 2000 and Interval'2000 is it free? or does it have > any limit of pages, format, etc. > > Regards > Regivan Actually, there is not yet a format for submissions specified on our web pages. We are currently working on the second announcement which will also contain information about this topic. There will be a limit of 120 words for the abstract and we are going to provide a TeX-macro for this purpose. I will post the 'Second Announcement' for the scan2000 and INTERVAL 2000 to all interested people and also send a electronic version to this mailing list (containing the download address for the TeX-Macro) I hope to see you in Karlsruhe Axel Facius (scan2000 OrgaTeam) ------------------------------------------------------------------------ For all of you hearing about scan 2000 and INTERVAL 2000 for the first time, please have a look at http:www//scan2000.de or send an email to mailto:info [at] scan2000 [dot] de. From owner-reliable_computing [at] interval [dot] usl.edu Mon Mar 6 11:50:23 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id LAA24324 for reliable_computing-outgoing; Mon, 6 Mar 2000 11:50:23 -0600 (CST) Received: from mail.cs.tu-berlin.de (root [at] mail [dot] cs.tu-berlin.de [130.149.17.13]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id LAA24319 for ; Mon, 6 Mar 2000 11:50:19 -0600 (CST) Received: from niemand.cs.tu-berlin.de (niemand.cs.tu-berlin.de [130.149.19.34]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id SAA17638 for ; Mon, 6 Mar 2000 18:40:59 +0100 (MET) Received: (from doris@localhost) by niemand.cs.tu-berlin.de (8.9.3/8.9.3) id SAA03782 for reliable_computing [at] interval [dot] usl.edu; Mon, 6 Mar 2000 18:40:28 +0100 (MET) Date: Mon, 6 Mar 2000 18:40:28 +0100 From: Doris Faehndrich To: reliable_computing [at] interval [dot] usl.edu Subject: ETAPS 2000 - 2nd Call for Participation Message-ID: <20000306184027.A3779 [at] niemand [dot] cs.tu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk (Sorry, if you receive multiple copies of this Call. Doris Faehndrich) ------------------------------------------------------------------ ETAPS 2000 - EUROPEAN JOINT CONFERENCES ON THEORY AND PRACTICE OF SOFTWARE Technical University of Berlin, March 25 - April 2, 2000 -------- CALL FOR PARTICIPATION ----- REMINDER ------------------- Welcome to Berlin, welcome to ETAPS, the European Joint Conferences on Theory and Practice of Software, the European forum for academic and industrial researchers working on these topics! For 9 days you will be able to choose between 5 conferences -TACAS 2000, FOSSACS 2000, FASE 2000, ESOP 2000, CC 2000 - with more than 120 regular papers and tool demonstrations covering a wide range of topics from theory and practice, 7 invited lectures by Abbas Edalat, David Harel, Martin Odersky, Richard M. Soley, Wlayslaw M. Turski, Reinhard Wilhelm, Pierre Wolper, 5 satellite events - GRATRA 2000, CMCS 2000, CBS 2000, INT 2000, CoFi 2000 -, 10 tutorials - XML for Software Engineers, A tutorial on Maude, Rigorous Requirements for Safety-Critical Systems: Fundamentals and Applications of the SCR Method, Multi-Paradigm Programming, Query-based Automated Debugging, The Unified Modelling Language, Swinging Types, Tables and computation, SDL 2000, Software Metrology Basis - (We reserve the right to cancel a tutorial owing to unsufficient participation.) We are pleased that so many people will be attending ETAPS 2000. For those who still haven't registered, we are extending EARLY REGISTRATION DATE UNTIL 15th MARCH! -------------------------------------------------------------------- Please, check for details http://iks.cs.tu-berlin.de/etaps2000/ Use the option of online registration or one of the downloadable registration forms! Registration Address: BWO Marketing Service GmbH Mohrenstr. 63-64 D-10117 Berlin-Mitte Germany Fax: ++49 30 22 66 84-64 Email: Etaps2000@BWO-Berlin.de Conference Mail Address: etaps2000 [at] iks [dot] cs.tu-berlin.de -------------------------------------------------------------------- Doris Faehndrich: TU Berlin FB-13 Sekr. FR 5-6, Franklinstr. 28/29, 10587 Berlin, Tel: 030/31473436 -------------------------------------------------------------------- From owner-reliable_computing [at] interval [dot] usl.edu Tue Mar 7 17:44:01 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id RAA26633 for reliable_computing-outgoing; Tue, 7 Mar 2000 17:44:01 -0600 (CST) Received: from genie.eecs.lehigh.edu (genie.eecs.lehigh.edu [128.180.98.9]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id RAA26628 for ; Tue, 7 Mar 2000 17:43:58 -0600 (CST) Received: from olympus.eecs.lehigh.edu (olympus [128.180.98.182]) by genie.eecs.lehigh.edu (8.8.5/8.8.5) with ESMTP id NAA09257; Tue, 7 Mar 2000 13:33:54 -0500 (EST) From: ASAP User Received: (from asap@localhost) by olympus.eecs.lehigh.edu (8.8.5/8.8.5) id NAA16377; Tue, 7 Mar 2000 13:33:53 -0500 (EST) Date: Tue, 7 Mar 2000 13:33:53 -0500 (EST) Message-Id: <200003071833.NAA16377 [at] olympus [dot] eecs.lehigh.edu> To: asap-announce [at] EECS [dot] Lehigh.EDU Subject: ASAP 2000 Call for Papers Cc: asap [at] EECS [dot] Lehigh.EDU Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Dear colleagues, This is a reminder that the deadline for paper submissions to ASAP 2000 has been extended to next Monday March 13, 2000. You can submit your paper and cover page via email to asap [at] eecs [dot] lehigh.edu any time between now and March 13, 2000. The revised call for papers is given below. If you have any questions about the conference or paper submissions, please send email to asap [at] eecs [dot] lehigh.edu or mschulte [at] eecs [dot] lehigh.edu. We apologize if you receive multiple copies of this email. Best regards, Mike Schulte ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ASAP 2000 CALL FOR PAPERS ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 12th International Conference on Application-specific Systems, Architectures and Processors Boston, Massachusetts Revised Dates and Deadlines Submission: March 13, 2000 Acceptance notification: April 13, 2000 Conference: July 10-12, 2000 Topics: The conference will cover the theory and practice of application- specific computing systems. Of particular interest are contributions that either achieve large performance gains, present formal methods for the specification, design and evaluation, analyze technology dependencies and the integration of hardware and software components, or describe and evaluate fabricated systems. Areas for application-specific computing systems are many and varied. Some sample areas include information systems, signal and image processing, multimedia systems, high-speed networks, compression, cryptography. Aspects of application-specific computing systems that are of interest include, but are not limited to: * Application-specific architectures: special purpose designs, design methodology, CAD tools, fault tolerance strategies, specification and interfaces, hardware/software codesign * Application-specific processors: digital signal processing, computer arithmetic, configurable/custom computing, implementation methodology & rapid prototyping, new technologies, fine-grain parallelism * Application-specific systems: network computing, special-purpose systems for exotic applications, performance evaluation, standard software objects, languages, compilers, operating systems, hardware/software integration The conference will feature a keynote speech, paper presentations, and a poster session. The proceedings will be published by IEEE Computer Society Press. Information for authors: Your paper should be a maximum of 5000 words. A PDF version of the complete paper and a separate cover page text file, with the following information * paper title; * paper abstract; * complete name, address, telephone, fax and email of each author; * author which is responsible for correspondence; * which of the conference areas is most relevant to your paper should be submitted via email to asap [at] eecs [dot] lehigh.edu. For further information about the conference, please see the conference web page at http://www.eecs.lehigh.edu/ASAP or send email to asap [at] eecs [dot] lehigh.edu. General Chair: Earl Swartzlander e.swartzlander [at] compmail [dot] com Program Chairs: Graham Jullien jullien [at] uwindsor [dot] ca Michael Schulte mschulte [at] eecs [dot] lehigh.edu Program committee: Magdy Bayoumi, Shuvra Bhattacharyya, Wayne Burleson, Peter Cappello, Liang-Gee Chen, Ed Deprettere, Milos Ercegovac, Gerhard Fettweis, Jose Fortes, Sayfe Kiaei, Israel Koren, S. Y. Kung, Tomas Lang, Wayne Luk, John McCanny, Jean-Michel Muller, Takao Nishitani, Tobias Noll, Peter Pirsch, Patrice Quinton, Sanjay Rajopadhye, Vwani Roychowdhury, Valerie Taylor, Juergen Teich, Lothar Thiele, Mateo Valero, Benjamin Wah, Doran Wilde, Roger Woods, Kung Yao, Pen Yew. From owner-reliable_computing [at] interval [dot] usl.edu Tue Mar 7 22:37:59 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id WAA27134 for reliable_computing-outgoing; Tue, 7 Mar 2000 22:37:59 -0600 (CST) Received: from genie.eecs.lehigh.edu (genie.eecs.lehigh.edu [128.180.98.9]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id WAA27129 for ; Tue, 7 Mar 2000 22:37:50 -0600 (CST) Received: from pandora.newcastle.edu.au (dmk [at] pandora [dot] newcastle.edu.au [134.148.100.234]) by genie.eecs.lehigh.edu (8.8.5/8.8.5) with ESMTP id SAA13557; Tue, 7 Mar 2000 18:37:30 -0500 (EST) Received: (from dmk@localhost) by pandora.newcastle.edu.au (8.9.1a/8.6.9) id KAA18155; Wed, 8 Mar 2000 10:37:12 +1100 (EST) Date: Wed, 8 Mar 2000 10:37:12 +1100 (EST) From: David Koch Message-Id: <200003072337.KAA18155 [at] pandora [dot] newcastle.edu.au> To: asap-announce [at] EECS [dot] Lehigh.EDU, asap [at] EECS [dot] Lehigh.EDU Cc: dmk [at] pandora [dot] newcastle.edu.au Subject: Pls remove aspray [at] faceng [dot] newcastle.edu.au Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Please remove aspray [at] faceng [dot] newcastle.edu.au from your mailing lists. He left several years ago. David Koch Manager - Computer Systems Group Faculty of Engineering University of Newcastle NSW 2291 Australia Tel: +61 2 4921 5292 Fax: +61 2 4921 6929 Email: dmk [at] cs [dot] newcastle.edu.au From owner-reliable_computing [at] interval [dot] usl.edu Wed Mar 8 06:15:13 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id GAA28585 for reliable_computing-outgoing; Wed, 8 Mar 2000 06:15:13 -0600 (CST) Received: from genie.eecs.lehigh.edu (genie.eecs.lehigh.edu [128.180.98.9]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id GAA28580 for ; Wed, 8 Mar 2000 06:15:09 -0600 (CST) Received: from yogi.urz.unibas.ch (yogi.urz.unibas.ch [131.152.1.4]) by genie.eecs.lehigh.edu (8.8.5/8.8.5) with ESMTP id CAA18630; Wed, 8 Mar 2000 02:20:56 -0500 (EST) Received: from unibas.ch ([131.152.31.44]) by ubaclu.unibas.ch (PMDF V5.2-29 #33343) with ESMTP id <01JMS7UHO6JU8Y4K00 [at] ubaclu [dot] unibas.ch>; Wed, 8 Mar 2000 08:19:31 +0100 Date: Wed, 08 Mar 2000 08:21:15 +0100 From: Birgit Westermann Subject: Remove from mailing list To: ASAP User Cc: asap-announce [at] EECS [dot] Lehigh.EDU Message-id: <38C5FF6B.EAFF4A01 [at] unibas [dot] ch> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (WinNT; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <200003071833.NAA16377 [at] olympus [dot] eecs.lehigh.edu> Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Please remove birgit [at] ifi [dot] unibas.ch from your mailing lists. Birgit Westermann From owner-reliable_computing [at] interval [dot] usl.edu Wed Mar 8 06:46:41 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id GAA28942 for reliable_computing-outgoing; Wed, 8 Mar 2000 06:46:41 -0600 (CST) Received: from genie.eecs.lehigh.edu (genie.eecs.lehigh.edu [128.180.98.9]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id GAA28937 for ; Wed, 8 Mar 2000 06:46:30 -0600 (CST) Received: from mailgate.rz.uni-karlsruhe.de (exim [at] mailgate [dot] rz.uni-karlsruhe.de [129.13.64.97]) by genie.eecs.lehigh.edu (8.8.5/8.8.5) with ESMTP id CAA18821 for ; Wed, 8 Mar 2000 02:46:41 -0500 (EST) Received: from rhrk.uni-kl.de (isdn216-56.rz.uni-karlsruhe.de [129.13.216.56]) by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 3.02 #2) id 12Sb8j-0003S6-00; Wed, 08 Mar 2000 08:44:17 +0100 Message-ID: <38C603E3.B3D91D1 [at] rhrk [dot] uni-kl.de> Date: Wed, 08 Mar 2000 08:40:19 +0100 From: Reiner Hartenstein Reply-To: hartenst [at] rhrk [dot] uni-kl.de Organization: University of Kaiserslautern X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,de-DE MIME-Version: 1.0 To: Diessel , Yang , Postula , Lisper , Vernalde , becker , kurdahi , wnajjar , latifi , gaudiot , wl , "catherine.dezan" , Brebner , lombardi , bohm , asap-announce , Liste BM-List1 Subject: REMINDER: 2nd Call for Papers -- deadline is near Content-Type: multipart/alternative; boundary="------------489B063A501673270C951C21" Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk --------------489B063A501673270C951C21 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit please, excuse multiple copies please, distribute 2nd Call for Papers FPL 2000 The 10th International Conference on Field Programmable Logic and Applications 28 - 30 August 2000 Villach, Austria >>> Paper deadline: 17 March 2000 <<< Growing Conference (growth 1999: 55%) - Extended Scope Prominent Professional Keynote Speakers Future SoC - System on a Chip: impossible without Reconfigurable Subsystems The conference proceedings will be published by Springer Verlag See: http://link.springer.de/series/lncs/ Topics to be covered include, but are not limited to: Reconfigurable Hardware and Systems: Fine grain - Coarse grain - Reconfigurable Computing Adaptive - Customizable - Embedded - fault-tolerant Architectures - Technologies - Low Power - Dynamically Rec. Applications: Routing - Networking - Wireless - Evolvable Real-world - Scientific - Rapid-prototyping - Others CAD, Compilation, Testing and Verification: Design Flow - Tools - Higher Level Synthesis Interconnect - Parameter Estimation - Benchmarks Testing and Verification of Dynamically Reconfigurable Apps Surveys, Tutorials, Future, History, and Education: Roadmaps to Technology, Application and Design Teaching Reconfigurables & Evolvables - Curricular Impact Student Projects - Industry / University Programs - Publicity Evolvable Hardware and Evolutionary Compilation Methods: Evolvable Hardware (EH) - Co-Evolution Tools and methodologies - Genetic Programming Emerging and Other RL/RC-related Methodologies: State machines - Cellular Automata Biologically inspired - Brain inspired fludic reconfigurable logic and applications Molecular Biology Applications For details on topic areas and conference location see: http://xputers.informatik.uni-kl.de/FPL/FPL2000/detailed_fpl.html Authors are invited to submit PDF of their paper (10 pages maximum) by date March 17, 2000 via E-mail to mailto:hartenst [at] rhrk [dot] uni-kl.de and: mailto:hoffmant [at] rhrk [dot] uni-kl.de For guidelines see http://www.springer.de/comp/lncs/authors.html Questions please, address to: mailto:hoffmant [at] rhrk [dot] uni-kl.de Download Call for Papers and Registration Form: PLEASE, DISTRIBUTE : PDF: http://xputers.informatik.uni-kl.de/FPL/fpl2000/CfP_FPL2000.pdf ps: http://xputers.informatik.uni-kl.de/FPL/fpl2000/CfP_FPL2000.ps Reiner Hartenstein Program Chair FPL-2000 --------------489B063A501673270C951C21 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
 
 
 

please, excuse multiple copies
please, distribute
 
 

                     2nd Call for Papers
 

                           FPL 2000
 

                The 10th International Conference on
            Field Programmable Logic and Applications
 

                      28 - 30 August 2000
                       Villach, Austria
 

             >>>  Paper deadline: 17 March 2000  <<<
 
 

Growing Conference (growth 1999: 55%)   -   Extended Scope
Prominent Professional Keynote Speakers

Future SoC - System on a Chip: impossible without Reconfigurable
Subsystems

The conference proceedings will be published by Springer Verlag
See:   http://link.springer.de/series/lncs/

Topics to be covered include, but are not limited to:

   Reconfigurable Hardware and Systems:
     Fine grain - Coarse grain - Reconfigurable Computing
     Adaptive  -  Customizable  -  Embedded  -  fault-tolerant
     Architectures  -  Technologies  -  Low Power  -  Dynamically Rec.

   Applications:
     Routing  -   Networking  -  Wireless  -  Evolvable
     Real-world  -  Scientific  -  Rapid-prototyping  -  Others

   CAD, Compilation, Testing and Verification:
     Design Flow  -  Tools  -  Higher Level Synthesis
     Interconnect  -  Parameter Estimation  -  Benchmarks
     Testing and Verification of Dynamically Reconfigurable Apps

   Surveys, Tutorials, Future, History, and Education:
     Roadmaps to Technology, Application and Design
     Teaching Reconfigurables & Evolvables  -  Curricular Impact
     Student Projects  -  Industry / University Programs  - Publicity

   Evolvable Hardware and Evolutionary Compilation Methods:
     Evolvable Hardware (EH) -  Co-Evolution
     Tools and methodologies  -  Genetic Programming

   Emerging and Other RL/RC-related Methodologies:
     State machines -  Cellular Automata
     Biologically inspired - Brain inspired
     fludic reconfigurable logic and applications
     Molecular Biology Applications

For details on topic areas and conference location see:
http://xputers.informatik.uni-kl.de/FPL/FPL2000/detailed_fpl.html

Authors are invited to submit PDF of their paper (10 pages maximum)
by date March 17, 2000 via E-mail to mailto:hartenst [at] rhrk [dot] uni-kl.de
                                and: mailto:hoffmant [at] rhrk [dot] uni-kl.de
For guidelines see    http://www.springer.de/comp/lncs/authors.html
Questions please, address to:      mailto:hoffmant [at] rhrk [dot] uni-kl.de

Download Call for Papers and Registration Form:  PLEASE, DISTRIBUTE :
PDF: http://xputers.informatik.uni-kl.de/FPL/fpl2000/CfP_FPL2000.pdf
ps:  http://xputers.informatik.uni-kl.de/FPL/fpl2000/CfP_FPL2000.ps

Reiner Hartenstein
Program Chair FPL-2000 --------------489B063A501673270C951C21-- From owner-reliable_computing [at] interval [dot] usl.edu Wed Mar 8 10:28:41 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id KAA29429 for reliable_computing-outgoing; Wed, 8 Mar 2000 10:28:41 -0600 (CST) Received: from mx1.iat.cnr.it (mail.iat.cnr.it [146.48.65.43]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id KAA29424 for ; Wed, 8 Mar 2000 10:28:38 -0600 (CST) Received: from mailserv.iei.pi.cnr.it (mailserv.iei.pi.cnr.it [146.48.84.11]) by mail.iat.cnr.it (PMDF V6.0-21 #36023) id <01JMSQHMJ6E88WW520 [at] mail [dot] iat.cnr.it> (original mail from t.bolognesi [at] IEI [dot] PI.CNR.IT); Wed, 08 Mar 2000 17:12:55 +0100 (MET) Received: from mailserv.iei.pi.cnr.it (mailserv.iei.pi.cnr.it [146.48.84.11]) by mail.iat.cnr.it (PMDF V6.0-21 #36023) with ESMTP id <01JMSQHJ3CO28WW52Q [at] mail [dot] iat.cnr.it> for forte-pstv-2000-lists-expand [at] reprocess [dot] iat.cnr.it (ORCPT forte-pstv-2000-lists [at] mail [dot] iat.cnr.it); Wed, 08 Mar 2000 17:12:41 +0100 (MET) Received: from [146.48.84.49] (mac-bolognesi.iei.pi.cnr.it [146.48.84.49]) by mailserv.iei.pi.cnr.it (8.9.3/8.8.7) with ESMTP id RAA09819 for ; Wed, 08 Mar 2000 17:19:16 +0100 Date: Wed, 08 Mar 2000 17:13:44 +0100 From: Tommaso Bolognesi Subject: FORTE/PSTV 2000 DEADLINE EXTENSION X-Sender: bolog [at] mailserv [dot] iei.pi.cnr.it To: forte-pstv-2000-lists [at] mail [dot] iat.cnr.it Reply-to: forte-pstv-2000 [at] cpr [dot] it Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk ------------FORTE / PSTV 2000 AT PISA - EXTENDED DEADLINE ------------ UNDER THE PRESSURE OF SEVERAL LAST MINUTE REQUESTS WE ARE GOING TO POSTPONE THE SUBMISSION DEADLINE TO MARCH 15, 2000 PLEASE USE OUR WEB-BASED SUBMISSION SYSTEM, REACHABLE FROM THE CONFERENCE SITE AT http://forte-pstv-2000.cpr.it REGARDS TOMMASO AND DIEGO From owner-reliable_computing [at] interval [dot] usl.edu Wed Mar 8 12:29:27 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id MAA29901 for reliable_computing-outgoing; Wed, 8 Mar 2000 12:29:26 -0600 (CST) Received: from genie.eecs.lehigh.edu (genie.eecs.lehigh.edu [128.180.98.9]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id MAA29896 for ; Wed, 8 Mar 2000 12:29:22 -0600 (CST) Received: from unknown-147-100.pilot.net (unknown-147-100.pilot.net [198.232.147.100]) by genie.eecs.lehigh.edu (8.8.5/8.8.5) with ESMTP id IAA21665; Wed, 8 Mar 2000 08:00:38 -0500 (EST) Received: from unknown-24-4.pilot.net (unknown-24-4.pilot.net [206.189.24.4]) by unknown-147-100.pilot.net with ESMTP id FAA26682; Wed, 8 Mar 2000 05:00:35 -0800 (PST) Received: from crdns.crd.ge.com (localhost [127.0.0.1]) by unknown-24-4.pilot.net with ESMTP id FAA00869; Wed, 8 Mar 2000 05:00:34 -0800 (PST) Received: from exc01crdge.crd.ge.com (crdmsx01.crd.ge.com [3.1.116.47]) by crdns.crd.ge.com (8.9.3/8.9.3) with ESMTP id IAA17243; Wed, 8 Mar 2000 08:01:11 -0500 (EST) Received: by crdmsx01.crd.ge.com with Internet Mail Service (5.5.2448.0) id <1WSCQSYD>; Wed, 8 Mar 2000 08:00:27 -0500 Message-ID: From: "Puckette, Charles M (CRD)" To: "'Birgit Westermann'" , ASAP User Cc: asap-announce [at] EECS [dot] Lehigh.EDU Subject: RE: Remove from mailing list Date: Wed, 8 Mar 2000 08:00:26 -0500 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Please remove puckette [at] crd [dot] ge.com from your mailing lists. Sincerely, C. M. Puckette GE Corporate R & D ______________________________ C. M. (Don) Puckette Manager - Systems Integration Electronic Systems Laboratory Bldg KW, Room C-1317 P.O. Box 8, Schenectady, NY 12301 Phone: 518-387-5284 Fax: 518-387-4042 E-mail: puckette [at] crd [dot] ge.com -----Original Message----- From: Birgit Westermann [mailto:Birgit.Westermann [at] unibas [dot] ch] Sent: Wednesday, March 08, 2000 2:21 AM To: ASAP User Cc: asap-announce [at] EECS [dot] Lehigh.EDU Subject: Remove from mailing list Please remove birgit [at] ifi [dot] unibas.ch from your mailing lists. Birgit Westermann From owner-reliable_computing [at] interval [dot] usl.edu Thu Mar 9 03:43:48 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id DAA01202 for reliable_computing-outgoing; Thu, 9 Mar 2000 03:43:47 -0600 (CST) Received: from omega.nbsp.nsk.su (omega.nbsp.nsk.su [212.20.33.242]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id DAA01197 for ; Thu, 9 Mar 2000 03:43:36 -0600 (CST) Received: from nbsp.nsk.su (novo0 [129.144.234.240]) by omega.nbsp.nsk.su (8.8.8+Sun/8.8.8) with SMTP id PAA25549 for ; Thu, 9 Mar 2000 15:44:18 +0600 (NST) Received: from novo21 by nbsp.nsk.su (SMI-8.6/SMI-SVR4) id PAA28380; Thu, 9 Mar 2000 15:43:45 +0600 Received: from novo21 (novo21 [129.144.234.21]) by novo21 (8.9.1b+Sun/8.9.1) with SMTP id PAA26669 for ; Thu, 9 Mar 2000 15:43:23 +0600 (NST) Message-Id: <200003090943.PAA26669@novo21> Date: Thu, 9 Mar 2000 15:43:23 +0600 (NST) From: "Sergey P. Shary" Reply-To: "Sergey P. Shary" Subject: "Symmetric" intervals To: reliable_computing [at] interval [dot] louisiana.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: feSWanyWkapSaZN0Psr++A== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Colleagues, I would like to draw your attention to the following terminology problem. The intervals [a,b] with the property a=-b are ususally called "symmetric", but what is a "symmetric interval matrix"? Nowdays, the following two understandigs occur in the literature: 1) it is a set of all symmetric (in the sense of common linear algebra) point matrices within a given interval matrix whose elements are "symmetric" with respect to the main diagonal, 2) it is an interval matrix whose elements are "symmetric intervals". I myself prefer the first option, which does not violate the classical linear algebra, so that there exists a need to somehow correct the very term "symmetric interval". Maybe, a "balanced interval" would be a good substitute to call the intervals [a,b] with a=-b ? I like it ... Sergey Shary From owner-reliable_computing [at] interval [dot] usl.edu Thu Mar 9 06:57:29 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id GAA00402 for reliable_computing-outgoing; Thu, 9 Mar 2000 06:57:29 -0600 (CST) Received: from homer.mat.univie.ac.at (homer.mat.univie.ac.at [131.130.29.70]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id GAA00397 for ; Thu, 9 Mar 2000 06:57:25 -0600 (CST) Received: (from neum@localhost) by homer.mat.univie.ac.at (8.9.3/8.9.3) id NAA21123; Thu, 9 Mar 2000 13:57:22 +0100 (MET) Date: Thu, 9 Mar 2000 13:57:22 +0100 (MET) From: Arnold Neumaier Message-Id: <200003091257.NAA21123 [at] homer [dot] mat.univie.ac.at> To: reliable_computing [at] interval [dot] louisiana.edu, ssh [at] nbsp [dot] nsk.su Subject: Re: "Symmetric" intervals Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk >>The intervals [a,b] with the property a=-b are ususally called "symmetric"<< I'd call that zero-symmetric, so that symmetric matrices have their natural meaning. Arnold Neumaier From owner-reliable_computing [at] interval [dot] usl.edu Thu Mar 9 07:23:57 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id HAA00804 for reliable_computing-outgoing; Thu, 9 Mar 2000 07:23:57 -0600 (CST) Received: from argo.bas.bg (root [at] argo [dot] bas.bg [195.96.224.7]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id HAA00799 for ; Thu, 9 Mar 2000 07:23:38 -0600 (CST) Received: from iph.bio.bas.bg (IDENT:0@bas-bio.lines.bas.bg [195.96.252.58]) by argo.bas.bg (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id PAA25413 for ; Thu, 9 Mar 2000 15:23:06 +0200 X-Authentication-Warning: argo.bas.bg: Host IDENT:0@bas-bio.lines.bas.bg [195.96.252.58] claimed to be iph.bio.bas.bg Received: from biomath.bio.bas.bg (biomath.bio.bas.bg [195.96.247.160]) by iph.bio.bas.bg (8.9.3/8.9.3) with SMTP id PAA29131 for ; Thu, 9 Mar 2000 15:23:43 +0200 Message-Id: <200003091323.PAA29131 [at] iph [dot] bio.bas.bg> Comments: Authenticated sender is From: "Svetoslav Markov" Organization: Institute of Mathematics, BAS To: reliable_computing [at] interval [dot] louisiana.edu Date: Thu, 9 Mar 2000 15:26:22 +0200 Subject: Re: "Symmetric" intervals Reply-to: smarkov [at] iph [dot] bio.bas.bg Priority: normal X-mailer: Pegasus Mail for Windows (v2.23) Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk In support to Arnold Neumaier's remark let me recall that "zero-symmetric convex body", and more generally "t-symmetric convex body " is an established notion in convex analysis. Intervals are a particular case of convex bodies. S. Markov > >>The intervals [a,b] with the property a=-b are ususally called "symmetric"<< > I'd call that zero-symmetric, so that symmetric matrices have their > natural meaning. > > Arnold Neumaier > -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + Svetoslav Markov Section "Biomathematics", Inst. of phone: +3592-979-3704, +3592-707460, Mathematics and Computer Sci., fax: +3592-971-3649, Bulgarian Academy of Sciences, e-mail: smarkov [at] iph [dot] bio.bas.bg "Acad. G. Bonchev" st., block 8, BG-1113 Sofia, BULGARIA home address: 11 Mizia, 1124 Sofia, tel. +3592-444651 -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + Svetoslav Markov Section "Biomathematics", Inst. of phone: +3592-979-3704, +3592-707460, Mathematics and Computer Sci., fax: +3592-971-3649, Bulgarian Academy of Sciences, e-mail: smarkov [at] iph [dot] bio.bas.bg "Acad. G. Bonchev" st., block 8, BG-1113 Sofia, BULGARIA home address: 11 Mizia, 1124 Sofia, tel. +3592-444651 -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + From owner-reliable_computing [at] interval [dot] usl.edu Thu Mar 9 09:07:51 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id JAA01184 for reliable_computing-outgoing; Thu, 9 Mar 2000 09:07:51 -0600 (CST) Received: from d61.ucs.usl.edu (root [at] d61 [dot] ucs.usl.edu [130.70.114.61]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id JAA01179 for ; Thu, 9 Mar 2000 09:07:48 -0600 (CST) Received: from d61.ucs.usl.edu (rbk5287 [at] d61 [dot] ucs.usl.edu [130.70.114.61]) by d61.ucs.usl.edu (8.9.1/8.9.1/ucs-client_1.3) with SMTP id JAA06044 for ; Thu, 9 Mar 2000 09:07:47 -0600 (CST) Message-Id: <200003091507.JAA06044 [at] d61 [dot] ucs.usl.edu> Date: Thu, 9 Mar 2000 09:07:47 -0600 (CST) From: Kearfott Ralph B Reply-To: Kearfott Ralph B Subject: Re: "Symmetric" intervals To: reliable_computing [at] interval [dot] louisiana.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: cGbJ9PuBwT1zbyxzjEL7Qw== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk I agree with Sergey that it would be good to use different terms for "symmetric interval matrices" and for intervals that are symmetric with respect to zero. I also support "zero-symmetric" for intervals that are symmetric with respect to zero, since the term is both * suggestive and, apparently, * consistent with an established term from convex analysis. (Lamentably, I'm not personally familiar with "t-symmetric", but I'll trust Svetoslav.) Hopefully such a new use will become established in our literature. Best regards, Baker > From: "Svetoslav Markov" > To: reliable_computing [at] interval [dot] louisiana.edu > Date: Thu, 9 Mar 2000 15:26:22 +0200 > Subject: Re: "Symmetric" intervals > > > > In support to Arnold Neumaier's remark let me recall that "zero-symmetric > convex body", and more generally "t-symmetric convex body " is an established > notion in convex analysis. Intervals are a particular case of convex bodies. > > S. Markov > > > >>The intervals [a,b] with the property a=-b are ususally called "symmetric"<< > > I'd call that zero-symmetric, so that symmetric matrices have their > > natural meaning. > > > > Arnold Neumaier > > > --------------------------------------------------------------- R. Baker Kearfott, rbk [at] louisiana [dot] edu (337) 482-5346 (fax) (337) 482-5270 (work) (337) 981-9744 (home) URL: http://interval.louisiana.edu/kearfott.html Department of Mathematics, University of Louisiana at Lafayette Box 4-1010, Lafayette, LA 70504-1010, USA --------------------------------------------------------------- From owner-reliable_computing [at] interval [dot] usl.edu Thu Mar 9 15:05:49 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id PAA02119 for reliable_computing-outgoing; Thu, 9 Mar 2000 15:05:49 -0600 (CST) Received: from smtprtp.ntcom.nortel.net (smtprtp.ntcom.nortel.net [137.118.22.15]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id PAA02114 for ; Thu, 9 Mar 2000 15:05:45 -0600 (CST) Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp.ntcom.nortel.net; Thu, 9 Mar 2000 16:05:11 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Mar 2000 16:05:09 -0500 Message-ID: <03E3E0690542D211A1490000F80836F402879920 [at] zcard00f [dot] ca.nortel.com> From: "Bill Older" To: Kearfott Ralph B , reliable_computing [at] interval [dot] louisiana.edu Subject: RE: "Symmetric" intervals Date: Thu, 9 Mar 2000 16:05:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8A0B.254987F4" Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF8A0B.254987F4 Content-Type: text/plain; charset="iso-8859-1" The notion of a symmetric interval is extremely important because of its "algebraic" properties ( symmetric intervals being the analogue of an ideal), so I personally find "zero-symmetric" unduly cumbersome. And wouldn't "symmetric matrix of symmetric intervals" be perfectly clear, even though "symmetric interval matrix" is clearly ambiguous? -----Original Message----- From: Kearfott Ralph B [mailto:rbk5287 [at] louisiana [dot] edu] Sent: Thursday, March 09, 2000 10:08 AM To: reliable_computing [at] interval [dot] louisiana.edu Subject: Re: "Symmetric" intervals I agree with Sergey that it would be good to use different terms for "symmetric interval matrices" and for intervals that are symmetric with respect to zero. I also support "zero-symmetric" for intervals that are symmetric with respect to zero, since the term is both * suggestive and, apparently, * consistent with an established term from convex analysis. (Lamentably, I'm not personally familiar with "t-symmetric", but I'll trust Svetoslav.) Hopefully such a new use will become established in our literature. Best regards, Baker > From: "Svetoslav Markov" > To: reliable_computing [at] interval [dot] louisiana.edu > Date: Thu, 9 Mar 2000 15:26:22 +0200 > Subject: Re: "Symmetric" intervals > > > > In support to Arnold Neumaier's remark let me recall that "zero-symmetric > convex body", and more generally "t-symmetric convex body " is an established > notion in convex analysis. Intervals are a particular case of convex bodies. > > S. Markov > > > >>The intervals [a,b] with the property a=-b are ususally called "symmetric"<< > > I'd call that zero-symmetric, so that symmetric matrices have their > > natural meaning. > > > > Arnold Neumaier > > > --------------------------------------------------------------- R. Baker Kearfott, rbk [at] louisiana [dot] edu (337) 482-5346 (fax) (337) 482-5270 (work) (337) 981-9744 (home) URL: http://interval.louisiana.edu/kearfott.html Department of Mathematics, University of Louisiana at Lafayette Box 4-1010, Lafayette, LA 70504-1010, USA --------------------------------------------------------------- ------_=_NextPart_001_01BF8A0B.254987F4 Content-Type: text/html; charset="iso-8859-1" RE: "Symmetric" intervals

The notion of a symmetric interval is extremely important
because of its "algebraic" properties ( symmetric intervals
being the analogue of an ideal), so I personally find
"zero-symmetric" unduly cumbersome.  And wouldn't
"symmetric matrix of symmetric intervals" be perfectly clear,
even though "symmetric interval matrix" is clearly ambiguous?


-----Original Message-----
From: Kearfott Ralph B [mailto:rbk5287 [at] louisiana [dot] edu]
Sent: Thursday, March 09, 2000 10:08 AM
To: reliable_computing [at] interval [dot] louisiana.edu
Subject: Re: "Symmetric" intervals


I agree with Sergey that it would be good to use different terms
for "symmetric interval matrices" and for intervals that are symmetric
with respect to zero.  I also support

    "zero-symmetric"
   
for intervals that are symmetric with respect to zero, since the
term is both

   * suggestive and, apparently,
  
   * consistent with an established term from convex analysis. 
  
(Lamentably, I'm not personally familiar with "t-symmetric", but I'll
trust Svetoslav.)

Hopefully such a new use will become  established in our literature.

Best regards,

Baker

> From: "Svetoslav Markov" <smarkov [at] iph [dot] bio.bas.bg>
> To: reliable_computing [at] interval [dot] louisiana.edu
> Date: Thu, 9 Mar 2000 15:26:22 +0200
> Subject: Re:  "Symmetric" intervals
>
>  
>
> In support to Arnold Neumaier's remark let me recall that "zero-symmetric
> convex body", and more generally "t-symmetric convex body " is an established
> notion in convex analysis. Intervals are a particular case of convex bodies.
>
> S. Markov
>
> > >>The intervals [a,b] with the property a=-b are ususally called
"symmetric"<<
> > I'd call that zero-symmetric, so that symmetric matrices have their
> > natural meaning.
> >
> > Arnold Neumaier
> >
>  

---------------------------------------------------------------
R. Baker Kearfott,    rbk [at] louisiana [dot] edu   (337) 482-5346 (fax)
(337) 482-5270 (work)                     (337) 981-9744 (home)
URL: http://interval.louisiana.edu/kearfott.html
Department of Mathematics, University of Louisiana at Lafayette
Box 4-1010, Lafayette, LA 70504-1010, USA
---------------------------------------------------------------

------_=_NextPart_001_01BF8A0B.254987F4-- From owner-reliable_computing [at] interval [dot] usl.edu Fri Mar 10 03:56:09 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id DAA03134 for reliable_computing-outgoing; Fri, 10 Mar 2000 03:56:09 -0600 (CST) Received: from argo.bas.bg (root [at] argo [dot] bas.bg [195.96.224.7]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id DAA03129 for ; Fri, 10 Mar 2000 03:55:47 -0600 (CST) Received: from iph.bio.bas.bg (IDENT:0@bas-bio.lines.bas.bg [195.96.252.58]) by argo.bas.bg (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id LAA24059; Fri, 10 Mar 2000 11:54:51 +0200 X-Authentication-Warning: argo.bas.bg: Host IDENT:0@bas-bio.lines.bas.bg [195.96.252.58] claimed to be iph.bio.bas.bg Received: from biomath.bio.bas.bg (biomath.bio.bas.bg [195.96.247.160]) by iph.bio.bas.bg (8.9.3/8.9.3) with SMTP id LAA32433; Fri, 10 Mar 2000 11:55:20 +0200 Message-Id: <200003100955.LAA32433 [at] iph [dot] bio.bas.bg> Comments: Authenticated sender is From: "Svetoslav Markov" Organization: Institute of Mathematics, BAS To: Kearfott Ralph B Date: Fri, 10 Mar 2000 11:57:59 +0200 Subject: Re: "Symmetric" intervals Reply-to: smarkov [at] iph [dot] bio.bas.bg CC: reliable_computing [at] interval [dot] louisiana.edu Priority: normal X-mailer: Pegasus Mail for Windows (v2.23) Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Let me explain what a t-symmetric convex body in convex analysis is. A convex body ( = compact convex set in E^n) is said to be "centrally symmetric with respect to the translation vector t\in E^n", or briefly "t-symmetric", if A-t= -(A-t) (the vector t is called "center" of A) According to this definition a convex body A with A= -A is centrally symmetric w.r.t. the origin, or briefly 0-symmetric. In convex analysis, if confusion is possible, then "symmetric" is replaced by "0-symmetric". There is no need to use the term "0-symmetric" if no confusion occurs -- then we say just "centrally symmetric" or "symmetric". This is just for information, in principle, I do not object alternative terminology. S. Markov > I agree with Sergey that it would be good to use different terms > for "symmetric interval matrices" and for intervals that are symmetric > with respect to zero. I also support > > "zero-symmetric" > > for intervals that are symmetric with respect to zero, since the > term is both > > * suggestive and, apparently, > > * consistent with an established term from convex analysis. > > (Lamentably, I'm not personally familiar with "t-symmetric", but I'll > trust Svetoslav.) > > Hopefully such a new use will become established in our literature. > > Best regards, > > Baker > From owner-reliable_computing [at] interval [dot] usl.edu Fri Mar 10 06:21:30 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id GAA04458 for reliable_computing-outgoing; Fri, 10 Mar 2000 06:21:29 -0600 (CST) Received: from visla.utia.cas.cz (root [at] visla [dot] utia.cas.cz [147.231.12.1]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id GAA04453 for ; Fri, 10 Mar 2000 06:21:25 -0600 (CST) Received: from [147.231.11.66] (klicava.site.cas.cz [147.231.11.66]) by visla.utia.cas.cz (8.9.3/8.9.3) with SMTP id NAA04602; Fri, 10 Mar 2000 13:20:52 +0100 (MET) X-NUPop-Charset: IBM 8-Bit Date: Thu, 9 Mar 00 14:16:53 CET From: "Jiri Rohn" Reply-To: rohn [at] uivt [dot] cas.cz Message-Id: <51417.rohn [at] uivt [dot] cas.cz> To: ssh [at] nbsp [dot] nsk.su, reliable_computing [at] interval [dot] usl.edu Subject: RE: "Symmetric" intervals Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Dear colleagues, Sergey's letter also contains another question which has not been touched by previous respondents: > what is a "symmetric interval matrix"? > >1) it is a set of all symmetric (in the sense of common linear algebra) > point matrices within a given interval matrix whose elements are > "symmetric" with respect to the main diagonal, > >2) it is an interval matrix whose elements are "symmetric intervals". or, I would add, it is an interval matrix [A,B] where both A and B are symmetric. I have seen the use of 1) in papers in some engineering journals (devoted e.g. to stability of interval matrices), but my opinion is that, according to the standard way in which mathematical terms are built, a symmetric interval matrix should be an interval matrix, which is not the case of 1). Hence I would support the definition 2). Best regards, Jiri From owner-reliable_computing [at] interval [dot] usl.edu Fri Mar 10 06:59:46 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id GAA04835 for reliable_computing-outgoing; Fri, 10 Mar 2000 06:59:46 -0600 (CST) Received: from homer.mat.univie.ac.at (homer.mat.univie.ac.at [131.130.29.70]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id GAA04830 for ; Fri, 10 Mar 2000 06:59:42 -0600 (CST) Received: (from neum@localhost) by homer.mat.univie.ac.at (8.9.3/8.9.3) id NAA22264; Fri, 10 Mar 2000 13:59:39 +0100 (MET) Date: Fri, 10 Mar 2000 13:59:39 +0100 (MET) From: Arnold Neumaier Message-Id: <200003101259.NAA22264 [at] homer [dot] mat.univie.ac.at> To: reliable_computing [at] interval [dot] usl.edu, rohn [at] uivt [dot] cas.cz, ssh [at] nbsp [dot] nsk.su Subject: RE: "Symmetric" intervals Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk >>what is a "symmetric interval matrix"?<< I agree with Jiri Rohn, that it should be an interval matrix A with A^T=A. The restricted interpretation as a set of symmetric matrices is adequately covered by the concept of a symmetric solution set for a linear interval system. Arnold Neumaier From owner-reliable_computing [at] interval [dot] usl.edu Fri Mar 10 07:02:55 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id HAA05017 for reliable_computing-outgoing; Fri, 10 Mar 2000 07:02:55 -0600 (CST) Received: from omega.nbsp.nsk.su (omega.nbsp.nsk.su [212.20.33.242]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id HAA05012 for ; Fri, 10 Mar 2000 07:02:51 -0600 (CST) Received: from nbsp.nsk.su (novo0 [129.144.234.240]) by omega.nbsp.nsk.su (8.8.8+Sun/8.8.8) with SMTP id SAA02410; Fri, 10 Mar 2000 18:59:57 +0600 (NST) Received: from novo21 by nbsp.nsk.su (SMI-8.6/SMI-SVR4) id SAA05701; Fri, 10 Mar 2000 18:55:30 +0600 Received: from novo21 (novo21 [129.144.234.21]) by novo21 (8.9.1b+Sun/8.9.1) with SMTP id SAA26813; Fri, 10 Mar 2000 18:55:07 +0600 (NST) Message-Id: <200003101255.SAA26813@novo21> Date: Fri, 10 Mar 2000 18:55:07 +0600 (NST) From: "Sergey P. Shary" Reply-To: "Sergey P. Shary" Subject: Re: "Symmetric" intervals To: neum [at] cma [dot] univie.ac.at Cc: reliable_computing [at] interval [dot] louisiana.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: +CjeMKb8YomE26CzqsTZ0w== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk > >>The intervals [a,b] with the property a=-b are ususally called "symmetric"<< > I'd call that zero-symmetric, so that symmetric matrices have their > natural meaning. > > Arnold Neumaier > Well, but how should I call an interval matrix [A,B] that combines the properties 1 and 2, i.e., A and B are both symmetric point matrices, we consider only symmetric point matrices within the above limits and all the interval elements of [A,B] are "zero-symmetric"? E.g., something like _ _ | | | [-1,1] [-3,3] | | | . | [-3,3] [-1,1] | |_ _| According to Arnold Neumaier's suggestion, this is a "zero-symmetric symmetric" matrix, or a "symmetric zero-symmetric" matrix. To tell the truth, that does not encourage me ... Sergey Shary From owner-reliable_computing [at] interval [dot] usl.edu Fri Mar 10 07:11:50 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id HAA05381 for reliable_computing-outgoing; Fri, 10 Mar 2000 07:11:50 -0600 (CST) Received: from homer.mat.univie.ac.at (homer.mat.univie.ac.at [131.130.29.70]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id HAA05376 for ; Fri, 10 Mar 2000 07:11:46 -0600 (CST) Received: (from neum@localhost) by homer.mat.univie.ac.at (8.9.3/8.9.3) id OAA22277; Fri, 10 Mar 2000 14:11:42 +0100 (MET) Date: Fri, 10 Mar 2000 14:11:42 +0100 (MET) From: Arnold Neumaier Message-Id: <200003101311.OAA22277 [at] homer [dot] mat.univie.ac.at> To: neum [at] cma [dot] univie.ac.at, ssh [at] nbsp [dot] nsk.su Subject: Re: "Symmetric" intervals Cc: reliable_computing [at] interval [dot] louisiana.edu Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk >>According to Arnold Neumaier's suggestion, this is a "zero-symmetric symmetric" matrix, or a "symmetric zero-symmetric" matrix.<< This is certainly better than `symmetric, matrix-symmetric matrix', which would be the alternative if symmetric were the label for an interval with midpoint zero. But one could call it `symmetrix matrix with midpoint zero', or perhaps doubly symmetric, to make it sound better. Arnold Neumaier From owner-reliable_computing [at] interval [dot] usl.edu Fri Mar 10 07:14:10 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id HAA05552 for reliable_computing-outgoing; Fri, 10 Mar 2000 07:14:10 -0600 (CST) Received: from omega.nbsp.nsk.su (omega.nbsp.nsk.su [212.20.33.242]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id HAA05543 for ; Fri, 10 Mar 2000 07:14:01 -0600 (CST) Received: from nbsp.nsk.su (novo0 [129.144.234.240]) by omega.nbsp.nsk.su (8.8.8+Sun/8.8.8) with SMTP id TAA02512; Fri, 10 Mar 2000 19:14:09 +0600 (NST) Received: from novo21 by nbsp.nsk.su (SMI-8.6/SMI-SVR4) id TAA06071; Fri, 10 Mar 2000 19:13:36 +0600 Received: from novo21 (novo21 [129.144.234.21]) by novo21 (8.9.1b+Sun/8.9.1) with SMTP id TAA26824; Fri, 10 Mar 2000 19:13:13 +0600 (NST) Message-Id: <200003101313.TAA26824@novo21> Date: Fri, 10 Mar 2000 19:13:13 +0600 (NST) From: "Sergey P. Shary" Reply-To: "Sergey P. Shary" Subject: Re: "Symmetric" intervals To: smarkov [at] iph [dot] bio.bas.bg Cc: reliable_computing [at] interval [dot] louisiana.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: BQnuIbfxyOF9aIcAzpqU9A== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk > In support to Arnold Neumaier's remark let me recall that "zero-symmetric > convex body", and more generally "t-symmetric convex body " is an established > notion in convex analysis. Intervals are a particular case of convex bodies. > > S. Markov > > > >>The intervals [a,b] with the property a=-b are ususally called "symmetric"<< > > I'd call that zero-symmetric, so that symmetric matrices have their > > natural meaning. > > > > Arnold Neumaier In support to my own standpoint, let me recall the following definition from classical linear functional analysis: a set X in a (real or complex) vector space is called "balanced" if x \in X and | \lambda | < 1 implies \lambda x \in X (see, e.g., the book Kantorovich L.V., Akilov G.P. Functional analysis in normed spaces). In real one-dimensional case, the "balanced sets" are nothing but the "zero-symmetric" intervals. Sergey Shary From owner-reliable_computing [at] interval [dot] usl.edu Fri Mar 10 07:25:32 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id HAA06041 for reliable_computing-outgoing; Fri, 10 Mar 2000 07:25:32 -0600 (CST) Received: from omega.nbsp.nsk.su (omega.nbsp.nsk.su [212.20.33.242]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id HAA06036 for ; Fri, 10 Mar 2000 07:25:28 -0600 (CST) Received: from nbsp.nsk.su (novo0 [129.144.234.240]) by omega.nbsp.nsk.su (8.8.8+Sun/8.8.8) with SMTP id TAA02554; Fri, 10 Mar 2000 19:26:14 +0600 (NST) Received: from novo21 by nbsp.nsk.su (SMI-8.6/SMI-SVR4) id TAA06240; Fri, 10 Mar 2000 19:25:40 +0600 Received: from novo21 (novo21 [129.144.234.21]) by novo21 (8.9.1b+Sun/8.9.1) with SMTP id TAA26829; Fri, 10 Mar 2000 19:25:17 +0600 (NST) Message-Id: <200003101325.TAA26829@novo21> Date: Fri, 10 Mar 2000 19:25:17 +0600 (NST) From: "Sergey P. Shary" Reply-To: "Sergey P. Shary" Subject: Re: "Symmetric" intervals To: neum [at] cma [dot] univie.ac.at Cc: reliable_computing [at] interval [dot] louisiana.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: xBQRiD0WWjM8GJR62UJFOw== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk > >>According to Arnold Neumaier's suggestion, this is a "zero-symmetric > symmetric" matrix, or a "symmetric zero-symmetric" matrix.<< > > This is certainly better than `symmetric, matrix-symmetric matrix', > which would be the alternative if symmetric were the label for an > interval with midpoint zero. But one could call it `symmetrix matrix > with midpoint zero', or perhaps doubly symmetric, to make it sound > better. > > Arnold Neumaier > I did not propose what you wrote. My alternative for _ _ | | | [-1,1] [-3,3] | | | | [-3,3] [-1,1] | |_ _| is "symmetric balanced matrix" or "balanced symmetric matrix", and that sounds best of all. Sergey Shary From owner-reliable_computing [at] interval [dot] usl.edu Fri Mar 10 07:35:55 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id HAA06407 for reliable_computing-outgoing; Fri, 10 Mar 2000 07:35:55 -0600 (CST) Received: from homer.mat.univie.ac.at (homer.mat.univie.ac.at [131.130.29.70]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id HAA06402 for ; Fri, 10 Mar 2000 07:35:52 -0600 (CST) Received: (from neum@localhost) by homer.mat.univie.ac.at (8.9.3/8.9.3) id OAA22481; Fri, 10 Mar 2000 14:35:50 +0100 (MET) Date: Fri, 10 Mar 2000 14:35:50 +0100 (MET) From: Arnold Neumaier Message-Id: <200003101335.OAA22481 [at] homer [dot] mat.univie.ac.at> To: reliable_computing [at] interval [dot] louisiana.edu Subject: Re: "Symmetric" intervals Cc: neum [at] cma [dot] univie.ac.at Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk >>"symmetric balanced matrix" or "balanced symmetric matrix", and that sounds best of all.<< I object to a needless multiplicity of concepts. Names that must be learnt should be reserved to objects that occur very frequently. zero-symmetric is self-explaining and hence acceptable even if rarely used; balanced requires one to look up the definition to find out what is meant, and hence less useful. I think the best choice is to avoid a special word for `zero-symmetric/balanced' and simply write `with midpoint zero'. This is almost as short, natural in language, cannot be misunderstood, and self-explaining. Arnold Neumaier From owner-reliable_computing [at] interval [dot] usl.edu Fri Mar 10 09:33:03 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id JAA06911 for reliable_computing-outgoing; Fri, 10 Mar 2000 09:33:03 -0600 (CST) Received: from argo.bas.bg (root [at] argo [dot] bas.bg [195.96.224.7]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id JAA06906 for ; Fri, 10 Mar 2000 09:32:44 -0600 (CST) Received: from iph.bio.bas.bg (IDENT:0@bas-bio.lines.bas.bg [195.96.252.58]) by argo.bas.bg (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id RAA29387; Fri, 10 Mar 2000 17:32:05 +0200 X-Authentication-Warning: argo.bas.bg: Host IDENT:0@bas-bio.lines.bas.bg [195.96.252.58] claimed to be iph.bio.bas.bg Received: from biomath.bio.bas.bg (biomath.bio.bas.bg [195.96.247.160]) by iph.bio.bas.bg (8.9.3/8.9.3) with SMTP id RAA03814; Fri, 10 Mar 2000 17:32:46 +0200 Message-Id: <200003101532.RAA03814 [at] iph [dot] bio.bas.bg> Comments: Authenticated sender is From: "Svetoslav Markov" Organization: Institute of Mathematics, BAS To: "Bill Older" Date: Fri, 10 Mar 2000 17:35:24 +0200 Subject: RE: "Symmetric" intervals Reply-to: smarkov [at] iph [dot] bio.bas.bg CC: reliable_computing [at] interval [dot] louisiana.edu Priority: normal X-mailer: Pegasus Mail for Windows (v2.23) Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk > From: "Bill Older" > To: Kearfott Ralph B , > reliable_computing [at] interval [dot] louisiana.edu > Subject: RE: "Symmetric" intervals > Date: Thu, 9 Mar 2000 16:05:03 -0500 > The notion of a symmetric interval is extremely important > because of its "algebraic" properties ( symmetric intervals > being the analogue of an ideal), so I personally find > "zero-symmetric" unduly cumbersome. And wouldn't > "symmetric matrix of symmetric intervals" be perfectly clear, > even though "symmetric interval matrix" is clearly ambiguous? > > Indeed, symmetric intervals are very important and we need simple terminology related to such intervals. In relation to the above comment by Bill Older let me formulate another terminological question. A quasilinear space (O. Mayer, H. Ratschek, G. Schroeder, etc) is a modification of a linear space abstracting interval properties. Algebraic extension (such as the one used for the definition of negative numbers) of a quasilinear space turns it into one having group structure. A quasilinear space with group structure is a direct product of a linear space and a symmetric quasilinear space with group structure. This shows that "symmetric quasilinear spaces with group structure" are EXTREMELY important and thus deserve a special name! I shall highly appreciate any suggestions in relation to this terminological question. S. Markov -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + Svetoslav Markov Section "Biomathematics", Inst. of phone: +3592-979-3704, +3592-707460, Mathematics and Computer Sci., fax: +3592-971-3649, Bulgarian Academy of Sciences, e-mail: smarkov [at] iph [dot] bio.bas.bg "Acad. G. Bonchev" st., block 8, BG-1113 Sofia, BULGARIA home address: 11 Mizia, 1124 Sofia, tel. +3592-444651 -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + From owner-reliable_computing [at] interval [dot] usl.edu Sat Mar 11 05:37:13 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id FAA10508 for reliable_computing-outgoing; Sat, 11 Mar 2000 05:37:13 -0600 (CST) Received: from relay.rhein-main.de (root [at] hermes [dot] rhein-main.de [195.37.8.6]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id FAA10503 for ; Sat, 11 Mar 2000 05:37:08 -0600 (CST) Received: from menuett.rhein-main.de (menuett.rhein-main.de [195.37.9.79]) by relay.rhein-main.de (8.9.3/8.9.3) with ESMTP id MAA13346 for ; Sat, 11 Mar 2000 12:30:15 +0100 Message-ID: <38CA3004.90B342FA [at] menuett [dot] rhein-main.de> Date: Sat, 11 Mar 2000 12:37:40 +0100 From: Jens Maurer X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i686) X-Accept-Language: en MIME-Version: 1.0 To: reliable_computing [at] interval [dot] louisiana.edu Subject: New C++ Library for Interval Arithmetic Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Hello! I've had a look at the two C++ interval arithmetic packages available via http://www.cs.utep.edu/interval-comp/main.html, namely RVInterval 1.1.1 (http://www-math.cudenver.edu/~rvan/Software.html) and PROFIL/BIAS (http://www.ti3.tu-harburg.de/Software/PROFIL.html). >From a software design perspective, I felt that both were inadequate. Most importantly, they are not templated, so they always employ "double" as the underlying type. Thus, I have written another C++ package with the following features: - Configurable base type (float, double, long double, or even your own floating-point like type; I've included an example using a rational type). - Configurable behavior for out-of-range arguments (exception or NaN) - Abstracted rounding-mode control into a separate class to allow easy adaption to the computing environment. - Transcendental functions implemented. It is available at http://www.rhein-main.de/people/jmaurer/interval.tar.gz for testing now, but its final place will be at http://www.boost.org You may want to adapt the Makefile to suit your C++ compiler and its options. I've tested the package on gcc 2.95.2, and I hope I've removed all things which prevented Microsoft Visual C++ 6.0 SP3 from compiling it as well. If you have any suggestions for improvement, please send them in. In particular, I feel that the name of the current "dist" function is unintuitive. Originally, I only intended the package to assess rounding errors in lengthy computations. Since then, I've learned that there are other application domains where interval arithmetic is useful, so I've provided some utility functions for set-like operations, affine transforms etc. as well. What is the current preference among the numeric computing community regarding behavior on out-of-range argument values? I've read W. Kahan 's "Lecture Notes on the Status of IEEE Standard 754 for Binary Floating Point Arithmetic" which seems to imply that raising exceptions has growing support. C++ provides language-based exceptions, but they are not required to be raised for illegal floating-point operations. Thank you for your help. Jens Maurer From owner-reliable_computing [at] interval [dot] usl.edu Sat Mar 11 12:05:37 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id MAA11057 for reliable_computing-outgoing; Sat, 11 Mar 2000 12:05:36 -0600 (CST) Received: from lsc.nd.edu (lsc.nd.edu [129.74.22.171]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id MAA11052 for ; Sat, 11 Mar 2000 12:05:33 -0600 (CST) From: jsiek [at] lsc [dot] nd.edu Received: from philoctetes.lsc.nd.edu (philoctetes.lsc.nd.edu [129.74.48.56]) by lsc.nd.edu (8.9.3/8.9.2) with ESMTP id NAA27944; Sat, 11 Mar 2000 13:05:08 -0500 (EST) Received: (from jsiek@localhost) by philoctetes.lsc.nd.edu (8.9.3/8.9.2) id NAA16414; Sat, 11 Mar 2000 13:05:12 -0500 (EST) Date: Sat, 11 Mar 2000 13:05:12 -0500 (EST) Message-Id: <200003111805.NAA16414 [at] philoctetes [dot] lsc.nd.edu> X-Authentication-Warning: philoctetes.lsc.nd.edu: jsiek set sender to Jeremy Siek using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: reliable_computing [at] interval [dot] louisiana.edu Cc: Jens Maurer Subject: New C++ Library for Interval Arithmetic In-Reply-To: <38CA3004.90B342FA [at] menuett [dot] rhein-main.de> References: <38CA3004.90B342FA [at] menuett [dot] rhein-main.de> X-Mailer: VM 6.40 under Emacs 19.34.1 Reply-To: Jeremy Siek Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Jens Maurer writes: > >From a software design perspective, I felt that both were inadequate. > Most importantly, they are not templated, so they always employ > "double" as the underlying type. The over-arching advantage of this new interval class is that it would be suitable for acceptance into the C++ standard. The core interface follows the design principles used for the C++ std::complex class. This uniform standard interface is particularly important for modern C++ libraries that use generic programming, and allows intervals to be used seemlessly in place of other numeric types. In terms of the functionality and implementation, the class is quite similar to the existing interval arithematic software that I have seen. The design goal of this interval class was to take the best features of the existing software, and package it in an interface that follows C++ stardard guidelines. The group of C++ experts at www.boost.org (many of whom are on the C++ stardard committee) has reviewed this interval class to ensure that the interface would be appropriate for standardization. It would be excellent if the reliable computing community also reviewed this class, to ensure that the functionality meets your needs, and that the implementation provides that functionality in a high-quality manner. Regards, Jeremy Siek ---------------------------------------------------------------------- Jeremy Siek Ph.D. Candidate email: jsiek [at] engr [dot] sgi.com Univ. of Notre Dame work phone: (650) 933-8724 and cell phone: (415) 377-5814 C++ Library & Compiler Group fax: (650) 932-0127 SGI www: http://www.lsc.nd.edu/~jsiek/ ---------------------------------------------------------------------- From owner-reliable_computing [at] interval [dot] usl.edu Sun Mar 12 03:28:29 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id DAA12001 for reliable_computing-outgoing; Sun, 12 Mar 2000 03:28:28 -0600 (CST) Received: from into.nit.spb.ru (into.nit.spb.ru [212.193.6.225]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id DAA11996 for ; Sun, 12 Mar 2000 03:28:24 -0600 (CST) Received: from slava.UUCP (uucp@localhost) by into.nit.spb.ru (8.8.7/8.8.7) with UUCP id MAA01843 for reliable_computing [at] interval [dot] usl.edu; Sun, 12 Mar 2000 12:29:11 +0300 (MSK) (envelope-from slava.nit.spb.su!nest [at] slava [dot] nit.spb.su) Received: by slava.nit.spb.su (dMail for DOS v1.23, 15Jun94); Sun, 12 Mar 2000 12:24:01 +0300 To: reliable_computing [at] interval [dot] usl.edu Message-Id: Organization: Slava Nesterov Date: Sun, 12 Mar 2000 12:24:01 +0300 (MSK) Reply-To: nest [at] into [dot] nit.spb.su From: "Slava Nesterov" X-Mailer: dMail [Demos Mail for DOS v1.23] Subject: special issues Lines: 37 Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Dear colleagues, As you know a few special issues of the Reliable Computing journal were published. Some more will be published soon. These issues are Vol. 5, issue 1, 1999 Proceedings of Interval'98 Guest editors: Shen Zuhe and Vladik Kreinovich Vol. 5, issue 3, 1999 Proceedings of the SCAN-98 Guest editor: Tibor Csendes Vol. 6, issue 1, 2000 Special issue on Reliable Geometric Computations Guest editors: Helmut Ratschek, Jon G. Rokne Vol. 6, issue 3, 2000 Special Issue on Applications to Control, Signals and Systems Guest editors: Juergen Garloff and Eric Walter The practice to publish special issues is good accepted by our readers and Kluwer Academic Publishers as well. We are going to continue to publish both types of special issues: ones devoted to different conferences and devoted to special topics. I would appreciate any suggestions concerning future special issues. If anybody has particular proposals and consider a possibility to be a guest editor of some issue please contact me directly. Thank you, Slava Nesterov From owner-reliable_computing [at] interval [dot] usl.edu Sun Mar 12 06:04:53 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id GAA13281 for reliable_computing-outgoing; Sun, 12 Mar 2000 06:04:53 -0600 (CST) Received: from argo.bas.bg (root [at] argo [dot] bas.bg [195.96.224.7]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id GAA13276 for ; Sun, 12 Mar 2000 06:04:48 -0600 (CST) Received: from iph.bio.bas.bg (IDENT:0@bas-bio.lines.bas.bg [195.96.252.58]) by argo.bas.bg (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id OAA16953 for ; Sun, 12 Mar 2000 14:03:57 +0200 X-Authentication-Warning: argo.bas.bg: Host IDENT:0@bas-bio.lines.bas.bg [195.96.252.58] claimed to be iph.bio.bas.bg Received: from biomath.bio.bas.bg (biomath.bio.bas.bg [195.96.247.160]) by iph.bio.bas.bg (8.9.3/8.9.3) with SMTP id OAA07087 for ; Sun, 12 Mar 2000 14:04:40 +0200 Message-Id: <200003121204.OAA07087 [at] iph [dot] bio.bas.bg> Comments: Authenticated sender is From: "Svetoslav Markov" Organization: Institute of Mathematics, BAS To: reliable_computing [at] interval [dot] louisiana.edu Date: Sun, 12 Mar 2000 14:07:16 +0200 Subject: RE: "Symmetric" intervals Reply-to: smarkov [at] iph [dot] bio.bas.bg Priority: normal X-mailer: Pegasus Mail for Windows (v2.23) Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Colleagues, In my last leter I made a mistake: please replace "direct product" by "direct sum". I attach the corrected text. ============== Indeed, symmetric intervals are very important and we need simple terminology related to such intervals. In relation to the above comment by Bill Older let me formulate another terminological question. A quasilinear space (O. Mayer, H. Ratschek, G. Schroeder, etc) is a modification of a linear space abstracting interval properties. Algebraic extension (such as the one used for the definition of negative numbers) of a quasilinear space turns it into one having group structure. A quasilinear space with group structure is a direct sum of a linear space and a symmetric quasilinear space with group structure. This shows that "symmetric quasilinear spaces with group structure" are EXTREMELY important and thus deserve a special name! I shall highly appreciate any suggestions in relation to this terminological question. ============== Let me add that a symmetric quasilinear space with group structure is a quasilinear space with group structure consisting of symmetric elements. More specifically, I would be interested to know if anybody of you objects the short term "symmetric spaces" for the above mentioned spaces. The observation that any quasilinear space is a direct product of a linear and a symmetric space is rather simple to prove. One only needs to extend in a natural way the term direct sum to quasilinear spaces with group structure. Nevertheless, I have not found the above statement in the literature. H. Ratschek et al. consider general quasilinear space, not specifically ones with group structure. E. Kaucher considers the case of group structure but not in the setting of quasilinear spaces (addition and multiplication by scalar). Am I wrong? S. Markov -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + Svetoslav Markov Section "Biomathematics", Inst. of phone: +3592-979-3704, +3592-707460, Mathematics and Computer Sci., fax: +3592-971-3649, Bulgarian Academy of Sciences, e-mail: smarkov [at] iph [dot] bio.bas.bg "Acad. G. Bonchev" st., block 8, BG-1113 Sofia, BULGARIA home address: 11 Mizia, 1124 Sofia, tel. +3592-444651 -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + -- + From owner-reliable_computing [at] interval [dot] usl.edu Tue Mar 14 08:29:09 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id IAA17218 for reliable_computing-outgoing; Tue, 14 Mar 2000 08:29:09 -0600 (CST) Received: from mscs.mu.edu (studsys.mscs.mu.edu [134.48.4.15]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with SMTP id IAA17213 for ; Tue, 14 Mar 2000 08:29:03 -0600 (CST) Received: (qmail 17838 invoked from network); 14 Mar 2000 14:28:53 -0000 Received: from ppp107.csd.mu.edu (HELO mscs.mu.edu) (134.48.24.7) by studsys.mscs.mu.edu with SMTP; 14 Mar 2000 14:28:53 -0000 Message-ID: <38CE4C73.506C1591 [at] mscs [dot] mu.edu> Date: Tue, 14 Mar 2000 08:28:04 -0600 From: George Corliss Organization: Marquette University X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jens Maurer CC: reliable_computing [at] interval [dot] louisiana.edu Subject: Re: New C++ Library for Interval Arithmetic References: <38CA3004.90B342FA [at] menuett [dot] rhein-main.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Jens Maurer wrote: > Originally, I only intended the package to assess rounding errors > in lengthy computations. Since then, I've learned that there > are other application domains where interval arithmetic is useful, > so I've provided some utility functions for set-like operations, > affine transforms etc. as well. Much work has been done in this area for 40 years, and many sophisticated algorithms exist. There is a major conference this fall in Karlsruhe, see http://www.scan2000.de/ > What is the current preference among the numeric computing community > regarding behavior on out-of-range argument values? I've read I would say the interval community is not of a single mind on this. For the view that there are NO exceptional conditions, see www.mscs.mu.edu/~globsol/walster-papers.html, especially
The Extended Real Interval System,
G. William (Bill) Walster,
extended_intervals.ps (Postscript - 295 Kb) 29 April 1998
Figure 1, page 8 (Postscript - 130 Kb)
Figures, pages 38 - 42. (Postscript - 188 Kb)
Abstract: Three extended real interval systems are defined and distinguished by their implementation complexity and result sharpness. The three systems are closed with respect to interval arithmetic and the enclosure of functions and relations, notwithstanding domain restrictions or the presence of singularities.
Interval Extensions of Real Functions with Finite Domains,
G. William (Bill) Walster,
domain.ps (Postscript - 84 Kb) 28 April 1998.
Abstract: Alternatives are considered for constructing interval enclosures of real functions with finite domains.

See also Interval compilers and programming environments This and many other questions posed to this mailing list are edited and collected into an Interval FAQ at www.mscs.mu.edu/~georgec/IFAQ Dr. George F. Corliss Dept. Math, Stat, Comp Sci Marquette University P.O. Box 1881 Milwaukee, WI 53201-1881 USA georgec [at] mscs [dot] mu.edu; George.Corliss [at] Marquette [dot] edu http://www.mscs.mu.edu/~georgec/ Office: 414-288-6599; Dept: 288-7375; Fax: 288-5472 From owner-reliable_computing [at] interval [dot] usl.edu Tue Mar 14 09:44:44 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id JAA17613 for reliable_computing-outgoing; Tue, 14 Mar 2000 09:44:43 -0600 (CST) Received: from automatix.informatik.uni-wuerzburg.de (root [at] wi2x40 [dot] informatik.uni-wuerzburg.de [132.187.10.40]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id JAA17608 for ; Tue, 14 Mar 2000 09:44:40 -0600 (CST) Received: from informatik.uni-wuerzburg.de (hystrix [132.187.10.44]) by automatix.informatik.uni-wuerzburg.de (8.8.8/8.8.8) with ESMTP id QAA02649; Tue, 14 Mar 2000 16:44:34 +0100 Message-ID: <38CE5E62.E1ABB7F9 [at] informatik [dot] uni-wuerzburg.de> Date: Tue, 14 Mar 2000 16:44:34 +0100 From: "J.Wolff v. Gudenberg" X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-SMP i686) X-Accept-Language: en MIME-Version: 1.0 To: Jens Maurer CC: reliable_computing [at] interval [dot] louisiana.edu Subject: Re: New C++ Library for Interval Arithmetic References: <38CA3004.90B342FA [at] menuett [dot] rhein-main.de> <38CE4C73.506C1591 [at] mscs [dot] mu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk We have prepared a very similar C++ library for interval arithmetic. It will be published in about 4-6 weeks. It implements all the extensions described in B. Walster's papers cited below. For more information see http://www.imada.sdu.dk/~kornerup/RNC4/papers/p03.ps J Wolff v Gudenberg George Corliss wrote: > > Jens Maurer wrote: > > > Originally, I only intended the package to assess rounding errors > > in lengthy computations. Since then, I've learned that there > > are other application domains where interval arithmetic is useful, > > so I've provided some utility functions for set-like operations, > > affine transforms etc. as well. > Much work has been done in this area for 40 years, and > many sophisticated algorithms exist. There is a major > conference this fall in Karlsruhe, see > http://www.scan2000.de/ > > > What is the current preference among the numeric computing community > > regarding behavior on out-of-range argument values? I've read > > I would say the interval community is not of a single mind on this. > For the view that there are NO exceptional conditions, see > www.mscs.mu.edu/~globsol/walster-papers.html, especially > >

>
The Extended Real Interval System, >
G. William (Bill) Walster, >
"http://www.mscs.mu.edu/~globsol/Papers/extended_intervals.ps" > >extended_intervals.ps > (Postscript - 295 Kb) 29 April 1998 >
>Figure 1, page 8 > (Postscript - 130 Kb) >
"http://www.mscs.mu.edu/~globsol/Papers/ext_int_pg38-41.ps" > >Figures, pages 38 - 42. > (Postscript - 188 Kb) >
> Abstract: Three extended real interval systems are defined and > distinguished by their implementation complexity and result sharpness. > The three systems are closed with respect to interval arithmetic and the > enclosure of functions and relations, notwithstanding domain > restrictions > or the presence of singularities. >
> >
Interval Extensions of Real Functions with Finite Domains, >
G. William (Bill) Walster, >
"http://www.mscs.mu.edu/~globsol/Papers/domain.ps">domain.ps > (Postscript - 84 Kb) 28 April 1998. >
> Abstract: Alternatives are considered for constructing interval > enclosures of real functions with finite domains. >
> >
> >

> See also Interval compilers and programming > "http://www.mscs.mu.edu/~georgec/IFAQ/environments.html">environments > > This and many other questions posed to this mailing list > are edited and collected into an Interval FAQ at > www.mscs.mu.edu/~georgec/IFAQ > > Dr. George F. Corliss > Dept. Math, Stat, Comp Sci > Marquette University > P.O. Box 1881 > Milwaukee, WI 53201-1881 USA > georgec [at] mscs [dot] mu.edu; George.Corliss [at] Marquette [dot] edu > http://www.mscs.mu.edu/~georgec/ > Office: 414-288-6599; Dept: 288-7375; Fax: 288-5472 -- __o \<, ___________________()/ ()__________________ Prof. Dr. J. Wolff v. Gudenberg Lehrstuhl fuer Informatik II wolff [at] informatik [dot] uni-wuerzburg.de Universitaet Wuerzburg Tel. 0931 / 888-6602 Am Hubland Fax. 0931 / 888-6603 D-97074 Wuerzburg URL http://www-info2.informatik.uni-wuerzburg.de/staff/wvg --------------------------------------------- From owner-reliable_computing [at] interval [dot] usl.edu Tue Mar 14 12:25:36 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id MAA18281 for reliable_computing-outgoing; Tue, 14 Mar 2000 12:25:36 -0600 (CST) Received: from relay.rhein-main.de (root [at] hermes [dot] rhein-main.de [195.37.8.6]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id MAA18276 for ; Tue, 14 Mar 2000 12:25:30 -0600 (CST) Received: from menuett.rhein-main.de (menuett.rhein-main.de [195.37.9.79]) by relay.rhein-main.de (8.9.3/8.9.3) with ESMTP id TAA10528; Tue, 14 Mar 2000 19:18:19 +0100 Message-ID: <38CE8358.FA5AF25F [at] menuett [dot] rhein-main.de> Date: Tue, 14 Mar 2000 19:22:16 +0100 From: Jens Maurer X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.3.51 i686) X-Accept-Language: en MIME-Version: 1.0 To: George Corliss CC: reliable_computing [at] interval [dot] louisiana.edu Subject: Re: New C++ Library for Interval Arithmetic References: <38CA3004.90B342FA [at] menuett [dot] rhein-main.de> <38CE4C73.506C1591 [at] mscs [dot] mu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Thank you very much for the helpful comments and documentation pointers. Thanks to your comments and after reading some of the papers, I know that my implementation is lacking. However, I feel that the important issue is the interface; after the interface is agreed upon, the implementation can be repaired easily. With a common interface where all C++ interval packages agree, the implementation becomes interchangeable. This allows for - common and peer-reviewed quality tests - common and peer-reviewed performance tests - common application software - formal standardization - vendor-provided optimized implementations I understand that Dmitri Chiriaev and William Walster did exactly that for a FORTRAN extension. There are several interval packages in existence, which all have different interfaces. This not only concerns function names, but also semantics. Let me highlight a few differences which hamper re-use of application software with different interval packages: - Allowing for different base types (float, double, even a non-builtin rational type) may sound far-fetched for most interval arithmetic application domains. However, there is no mathematical reason to forbid them, and they can be useful. For example, if the usual 64 bits of a "double" (53 bits mantissa) are not enough for some computations, there may arise the necessity to employ an extended-precision real class from some other source. It would be a pity if one had to re-implement interval arithmetics just to use that "better" real class. - We could specify that the FPU rounding mode is undefined after some interval arithmetic operation, or that it will not be altered, i.e. rounding mode changes are always local to an operation. The latter specification is useful if you mix interval and point arithmetic, for example. From a software design perspective, I think it is inacceptable to have an indeterminate rounding mode after some interval arithmetic operation, rendering all future built-in point operations invalid. - Behaviour on illegal operations such as sqrt(-1): Throw an exception, or do your best and continue (see the specification by Dmitri Chiriaev and William Walster). From a C++ software design perspective, I think it is inacceptable to just terminate the program, but on the other hand, continuing might be inappropriate as well. That's where C++ exceptions come in handy. - Behaviour of overloaded operator< : There is the choice of certainly-less-than, possibly-less-than and subset-of. - From a software design perspective, the use of macros (instead of template parameters) is not desirable. I shall check out the performance disadvantage for templates claimed by Juergen Wolff von Gudenberg in the paper advertised in his mail. Frankly, I have a hard time believing it. I understand that the decision in some of these items depends on the application domain, and thus the item should be a configuration option for the interval class. It seems important to me to identify the resulting space of configuration options. (I'm off to Malta for two weeks, but I will read my mail after I'm back.) Jens Maurer. From owner-reliable_computing [at] interval [dot] usl.edu Tue Mar 14 16:48:45 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id QAA18990 for reliable_computing-outgoing; Tue, 14 Mar 2000 16:48:45 -0600 (CST) Received: from marnier.ucs.usl.edu (root@ucs-gw.usl.edu [130.70.40.2]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id QAA18985 for ; Tue, 14 Mar 2000 16:48:25 -0600 (CST) Received: from u8174 (rbk5287 [at] goedel [dot] usl.edu [130.70.49.203]) by marnier.ucs.usl.edu (8.9.1/8.9.1/ucs-mx-host_1.3) with SMTP id QAA16384; Tue, 14 Mar 2000 16:47:56 -0600 (CST) Message-Id: <2.2.32.20000314225128.0074e188 [at] pop [dot] usl.edu> X-Sender: rbk5287 [at] pop [dot] usl.edu X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 14 Mar 2000 16:51:28 -0600 To: Jens Maurer , George Corliss From: "R. Baker Kearfott" Subject: Re: New C++ Library for Interval Arithmetic Cc: reliable_computing [at] interval [dot] louisiana.edu Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Jens, Please see my interpolated comments. R. Baker Kearfott At 07:22 PM 3/14/00 +0100, Jens Maurer wrote: > >Thank you very much for the helpful comments and documentation >pointers. > >Thanks to your comments and after reading some of the papers, I >know that my implementation is lacking. However, I feel that the >important issue is the interface; after the interface is agreed >upon, the implementation can be repaired easily. > >With a common interface where all C++ interval packages agree, >the implementation becomes interchangeable. This allows for > - common and peer-reviewed quality tests > - common and peer-reviewed performance tests > - common application software > - formal standardization > - vendor-provided optimized implementations > Yes, this is a laudable goal. >I understand that Dmitri Chiriaev and William Walster did exactly >that for a FORTRAN extension. > We almost convinced the Fortran committee of requiring an intrinsic interval type in the standard. As a member of those committees (US X3J3 and international WG5), I organized input to the committee for two years. For about half of this time, an interval data type was a stated requirement for Fortran 2000. In the end, some disagreements within the interval community coupled with resistance on the part of some vendors to a technology they perceived as different, untested and with uncertain demand, killed the requirement. I have archives from a mailing list for discussion of the proposed standard. There are also other documents associated with the standardization effort. The Chiriaev / Walster (and others) implementation within Sun's Fortran compiler benefits from the standardization effort, but goes beyond it in several ways. Most importantly, Walster et al have put effort into considering intervals resulting from operations such as [1,2] / [-1,1] or SQRT([-1,1]) to develop an exception-free system (using infinities for end points). Precursors to the standardization effort are Walster's early library INTLIB, a library for an intrinsic Fortran data type for the Minnesota M77 compiler for CYBER 175 machines, and my Fortran 90 module INTERVAL_ARITHMETIC (ACM TOMS Algorithm 763). (My module uses the FORTRAN 77 module INTLIB, although it is unrelated to Walster's work; I was unaware that Bill had named his library INTLIB when I developed my INTLIB.) Wolfgang Walter II has also been a player in the standardization process for intervals, especially as head of the German delegation to the international committee. He also developed a module that partially implements the proposed standard of the time. I am hoping that we will all examine Sun's Fortran compiler. We may or may not agree with precise details, but, in any case, it represents a milestone from which we can start, if we perceive we need to go further. We should send our comments, suggestions, and criticism either here or to a support mailing list at sun-interval-fortran-questions [at] interval [dot] louisiana.edu >There are several interval packages in existence, which all have >different interfaces. This not only concerns function names, >but also semantics. Let me highlight a few differences which >hamper re-use of application software with different interval >packages: > > - Allowing for different base types (float, double, even a non-builtin >rational type) may sound far-fetched for most interval arithmetic >application domains. However, there is no mathematical reason to forbid >them, and they can be useful. For example, if the usual 64 bits of a >"double" (53 bits mantissa) are not enough for some computations, there >may arise the necessity to employ an extended-precision real class from >some other source. It would be a pity if one had to re-implement >interval arithmetics just to use that "better" real class. > Yes, I agree with the above. Also, I presently don't see any strong objections with allowing different base types. > - We could specify that the FPU rounding mode is undefined after >some interval arithmetic operation, or that it will not be altered, >i.e. rounding mode changes are always local to an operation. The >latter specification is useful if you mix interval and point >arithmetic, for example. From a software design perspective, I think >it is inacceptable to have an indeterminate rounding mode after >some interval arithmetic operation, rendering all future built-in >point operations invalid. > Yes, specifying "undefined" allows some wiggle-room. In particular, different computer architectures switch rounding modes in different ways. Interval arithmetic can be efficiently implemented with just a single rounding mode (either "round-down" or "round-up"); that, I think, is an efficient option for most architectures. Otherwise, the best architecture for doing a sequence of unrelated computations interspersed with floating-point computations appears to be associating the rounding mode with the operation itself, rather than with a flag that is switched in the FPU. If the architecture is unknown, specifying that the rounding mode is "undefined" after an operation lets the interval operations be efficient, but may cause inefficiencies later due to having to change the rounding mode back to a desired value. > - Behaviour on illegal operations such as sqrt(-1): Throw an exception, >or do your best and continue (see the specification by Dmitri Chiriaev >and William Walster). From a C++ software design perspective, I think >it is inacceptable to just terminate the program, but on the other >hand, continuing might be inappropriate as well. That's where C++ >exceptions come in handy. > The above has been the subject of some controversy. My perception is that, in some contexts, you will want to throw an exception, and, in others, you will want to continue. Fortran does not have user-defined exceptions. The reasons, as I understand them, include efficiency. Fortran is a very good array-processing language, and there are major questions about what to do if an exception occurs in a component while an array operation is executing on an advanced-architecture machine. > - Behaviour of overloaded operator< : There is the choice of >certainly-less-than, possibly-less-than and subset-of. > My reading is that the most commonly used meaning is "certainly less than", although others may disagree :-) In my view, the important thing is that non-interval-experts using interval arithmetic understand the distinction. > - From a software design perspective, the use of macros (instead of >template parameters) is not desirable. I shall check out the >performance disadvantage for templates claimed by Juergen Wolff >von Gudenberg in the paper advertised in his mail. Frankly, I have >a hard time believing it. > Can we race J{\"u}rgen's package and yours under similar conditions? By the way, in developing template-like features in Fortran 200x, a consideration of the standardization committee was "avoiding performance hits as you see in C++". >I understand that the decision in some of these items depends on >the application domain, and thus the item should be a configuration >option for the interval class. It seems important to me to identify >the resulting space of configuration options. > Yes, I fully agree with the above. >(I'm off to Malta for two weeks, but I will read my mail after I'm >back.) Best wishes. Also, if this turns out to be a provocative topic, I hope your mailbox has enough space :-) > >Jens Maurer. > > --------------------------------------------------------------- R. Baker Kearfott, rbk [at] louisiana [dot] edu (337) 482-5346 (fax) (337) 482-5270 (work) (337) 981-9744 (home) URL: http://interval.louisiana.edu/kearfott.html Department of Mathematics, University of Louisiana at Lafayette Box 4-1010, Lafayette, LA 70504-1010, USA --------------------------------------------------------------- From owner-reliable_computing [at] interval [dot] usl.edu Tue Mar 14 17:47:46 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id RAA19466 for reliable_computing-outgoing; Tue, 14 Mar 2000 17:47:46 -0600 (CST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id RAA19461 for ; Tue, 14 Mar 2000 17:47:42 -0600 (CST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA12963; Tue, 14 Mar 2000 15:46:34 -0800 (PST) Received: from ha-sims.eng.sun.com (phys-thestorka.Eng.Sun.COM [129.146.1.231]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA05381; Tue, 14 Mar 2000 15:46:33 -0800 (PST) Received: from gww (gww.Eng.Sun.COM [129.146.78.116]) by ha-sims.eng.sun.com (Sun Internet Mail Server sims.4.0.1999.06.13.00.20) with SMTP id <0FRF00M7QRDK80@ha-sims.eng.sun.com>; Tue, 14 Mar 2000 15:46:32 -0800 (PST) Date: Tue, 14 Mar 2000 15:46:33 -0800 (PST) From: William Walster Subject: Re: New C++ Library for Interval Arithmetic To: jmaurer [at] menuett [dot] rhein-main.de, georgec [at] mscs [dot] mu.edu, rbk [at] louisiana [dot] edu Cc: reliable_computing [at] interval [dot] louisiana.edu Reply-to: William Walster Message-id: <0FRF00M7RRDK80@ha-sims.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4 SunOS 5.7 sun4m sparc Content-type: TEXT/plain; charset=us-ascii Content-MD5: r9EIGs7beV9X6qUrbrvLrw== Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk >Date: Tue, 14 Mar 2000 16:51:28 -0600 >From: "R. Baker Kearfott" >Subject: Re: New C++ Library for Interval Arithmetic >X-Sender: rbk5287 [at] pop [dot] usl.edu >To: Jens Maurer , George Corliss >Cc: reliable_computing [at] interval [dot] louisiana.edu >MIME-version: 1.0 > >Jens, > >Please see my interpolated comments. > >R. Baker Kearfott > >At 07:22 PM 3/14/00 +0100, Jens Maurer wrote: >> >>Thank you very much for the helpful comments and documentation >>pointers. >> >>Thanks to your comments and after reading some of the papers, I >>know that my implementation is lacking. However, I feel that the >>important issue is the interface; after the interface is agreed >>upon, the implementation can be repaired easily. >> >>With a common interface where all C++ interval packages agree, >>the implementation becomes interchangeable. This allows for >> - common and peer-reviewed quality tests >> - common and peer-reviewed performance tests >> - common application software >> - formal standardization >> - vendor-provided optimized implementations >> > >Yes, this is a laudable goal. > >>I understand that Dmitri Chiriaev and William Walster did exactly >>that for a FORTRAN extension. >> > >We almost convinced the Fortran committee of requiring an >intrinsic interval type in the standard. As a member of those >committees (US X3J3 and international WG5), I organized input >to the committee for two years. For about half of this time, >an interval data type was a stated requirement for Fortran 2000. >In the end, some disagreements within the interval community >coupled with resistance on the part of some vendors to a >technology they perceived as different, untested and with uncertain >demand, killed the requirement. I have archives from a mailing >list for discussion of the proposed standard. There are also >other documents associated with the standardization effort. > >The Chiriaev / Walster (and others) implementation within Sun's >Fortran compiler benefits from the standardization effort, but >goes beyond it in several ways. Most importantly, Walster et al >have put effort into considering intervals resulting from >operations such as [1,2] / [-1,1] or SQRT([-1,1]) to develop >an exception-free system (using infinities for end points). > >Precursors to the standardization effort are Walster's early >library INTLIB, a library for an intrinsic Fortran data type >for the Minnesota M77 compiler for CYBER 175 machines, and >my Fortran 90 module INTERVAL_ARITHMETIC (ACM TOMS Algorithm 763). >(My module uses the FORTRAN 77 module INTLIB, although it is >unrelated to Walster's work; I was unaware that Bill had named >his library INTLIB when I developed my INTLIB.) > >Wolfgang Walter II has also been a player in the standardization >process for intervals, especially as head of the German delegation >to the international committee. He also developed a module that >partially implements the proposed standard of the time. > >I am hoping that we will all examine Sun's Fortran compiler. We >may or may not agree with precise details, but, in any case, it >represents a milestone from which we can start, if we perceive >we need to go further. We should send our comments, suggestions, >and criticism either here or to a support mailing list at > >sun-interval-fortran-questions [at] interval [dot] louisiana.edu For sure, our soon to be released compiler has benefitted from the helpful work, comments and suggestions of many people, including Baker and those he listed, above. We hope the above mailing list will be actively used as a forum for getting questions answered and to express positive and negative comments. > >>There are several interval packages in existence, which all have >>different interfaces. This not only concerns function names, >>but also semantics. Let me highlight a few differences which >>hamper re-use of application software with different interval >>packages: >> >> - Allowing for different base types (float, double, even a non-builtin >>rational type) may sound far-fetched for most interval arithmetic >>application domains. However, there is no mathematical reason to forbid >>them, and they can be useful. For example, if the usual 64 bits of a >>"double" (53 bits mantissa) are not enough for some computations, there >>may arise the necessity to employ an extended-precision real class from >>some other source. It would be a pity if one had to re-implement >>interval arithmetics just to use that "better" real class. >> > >Yes, I agree with the above. Also, I presently don't see any >strong objections with allowing different base types. > >> - We could specify that the FPU rounding mode is undefined after >>some interval arithmetic operation, or that it will not be altered, >>i.e. rounding mode changes are always local to an operation. The >>latter specification is useful if you mix interval and point >>arithmetic, for example. From a software design perspective, I think >>it is inacceptable to have an indeterminate rounding mode after >>some interval arithmetic operation, rendering all future built-in >>point operations invalid. >> > >Yes, specifying "undefined" allows some wiggle-room. In particular, >different computer architectures switch rounding modes in different >ways. Interval arithmetic can be efficiently implemented with >just a single rounding mode (either "round-down" or "round-up"); >that, I think, is an efficient option for most architectures. Otherwise, >the best architecture for doing a sequence of unrelated computations >interspersed with floating-point computations appears to be >associating the rounding mode with the operation itself, rather >than with a flag that is switched in the FPU. > >If the architecture >is unknown, specifying that the rounding mode is "undefined" after >an operation lets the interval operations be efficient, but may >cause inefficiencies later due to having to change the rounding >mode back to a desired value. In our f95 implementation we guarantee that intervals do not produce any side effects on non-interval code. In particular, we "logically" restore the rounding mode after every interval operation. > >> - Behaviour on illegal operations such as sqrt(-1): Throw an exception, >>or do your best and continue (see the specification by Dmitri Chiriaev >>and William Walster). From a C++ software design perspective, I think >>it is inacceptable to just terminate the program, but on the other >>hand, continuing might be inappropriate as well. That's where C++ >>exceptions come in handy. >> > >The above has been the subject of some controversy. My perception >is that, in some contexts, you will want to throw an exception, >and, in others, you will want to continue. > >Fortran does not have >user-defined exceptions. The reasons, as I understand them, >include efficiency. Fortran is a very good array-processing language, >and there are major questions about what to do if an exception >occurs in a component while an array operation is executing on >an advanced-architecture machine. The system we have implemented in f95 is set-based. The result of an operation or function evaluated at a point that is outside the closure of its domain is the empty set, or empty interval. Depending on the context, an empty result of an arithmetic operation or function evaluation may or may not indicate that an error has been made. An exception-like feature is needed to provide a test for expression continuity, which is an assumption for the interval Newton algorithm and the Brouwer fixed-point theorem. This will only be needed in special circumstances and therefore needs to be invokable only when required. > >> - Behaviour of overloaded operator< : There is the choice of >>certainly-less-than, possibly-less-than and subset-of. >> > >My reading is that the most commonly used meaning is >"certainly less than", although others may disagree :-) In my >view, the important thing is that non-interval-experts using >interval arithmetic understand the distinction. The most important practical application for this syntactic sugar I have uncovered is to make it easy to construct "complete" sets of relational statements. This is important to avoid hiding an empty result that could be the indication of an error condition. Otherwise, depending on the application, one or the other sense of relational operator may be what makes the most sense in the particular context. > >> - From a software design perspective, the use of macros (instead of >>template parameters) is not desirable. I shall check out the >>performance disadvantage for templates claimed by Juergen Wolff >>von Gudenberg in the paper advertised in his mail. Frankly, I have >>a hard time believing it. >> > >Can we race J{\"u}rgen's package and yours under similar conditions? > >By the way, in developing template-like features in Fortran 200x, >a consideration of the standardization committee was "avoiding >performance hits as you see in C++". > >>I understand that the decision in some of these items depends on >>the application domain, and thus the item should be a configuration >>option for the interval class. It seems important to me to identify >>the resulting space of configuration options. >> > >Yes, I fully agree with the above. > >>(I'm off to Malta for two weeks, but I will read my mail after I'm >>back.) > >Best wishes. Also, if this turns out to be a provocative topic, I >hope your mailbox has enough space :-) > >> >>Jens Maurer. >> >> >--------------------------------------------------------------- >R. Baker Kearfott, rbk [at] louisiana [dot] edu (337) 482-5346 (fax) >(337) 482-5270 (work) (337) 981-9744 (home) >URL: http://interval.louisiana.edu/kearfott.html >Department of Mathematics, University of Louisiana at Lafayette >Box 4-1010, Lafayette, LA 70504-1010, USA >--------------------------------------------------------------- > From owner-reliable_computing [at] interval [dot] usl.edu Thu Mar 16 14:25:36 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id OAA24609 for reliable_computing-outgoing; Thu, 16 Mar 2000 14:25:36 -0600 (CST) Received: from cs.utep.edu (mail.cs.utep.edu [129.108.5.3]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id OAA24604 for ; Thu, 16 Mar 2000 14:25:17 -0600 (CST) Received: from earth (earth [129.108.5.21]) by cs.utep.edu (8.9.3+Sun/8.9.1) with SMTP id NAA28842; Thu, 16 Mar 2000 13:24:54 -0700 (MST) Message-Id: <200003162024.NAA28842 [at] cs [dot] utep.edu> Date: Thu, 16 Mar 2000 13:24:55 -0700 (MST) From: Vladik Kreinovich Reply-To: Vladik Kreinovich Subject: Submitting Abstracts to scan2000/Interval2000 To: reliable_computing [at] interval [dot] usl.edu, interval [at] cs [dot] utep.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: rleg6A4Al0zeVL2rzXgq2w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4 SunOS 5.7 sun4u sparc Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk FYI. Apologies if you received multiple copies. ------------- Begin Forwarded Message ------------- To: list [at] scan2000 [dot] de Subject: Submitting Abstracts to scan2000/Interval2000 Date: Thu, 16 Mar 2000 18:21:57 +0100 please notice that we have postponed the deadline for the submission of abstracts to the scan2000/Interval2000 conference from March 31, 2000 to >>> April 30, 2000 <<< Since we plan to provide an online 'book of abstracts' it would help us very much if you send your abstract electronically to mailto:abstracts [at] scan2000 [dot] de instead of sending a hardcopy which we would have to type. Our preferred format is LaTeX or plain (ASCII) text. However, you can also use MSWord. Please refer to http://www.scan2000.de/abstracts.html for examples and further informations. ... Axel Facius (scan/Interval OrgaTeam) ------------- End Forwarded Message ------------- From owner-reliable_computing [at] interval [dot] usl.edu Sat Mar 18 02:34:05 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id CAA27673 for reliable_computing-outgoing; Sat, 18 Mar 2000 02:34:05 -0600 (CST) Received: from into.nit.spb.ru (into.nit.spb.ru [212.193.6.225]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id CAA27668 for ; Sat, 18 Mar 2000 02:33:47 -0600 (CST) Received: from slava.UUCP (uucp@localhost) by into.nit.spb.ru (8.8.7/8.8.7) with UUCP id LAA21579 for reliable_computing [at] interval [dot] usl.edu; Sat, 18 Mar 2000 11:34:09 +0300 (MSK) (envelope-from slava.nit.spb.su!nest [at] slava [dot] nit.spb.su) Received: by slava.nit.spb.su (dMail for DOS v1.23, 15Jun94); Sat, 18 Mar 2000 11:25:52 +0300 To: reliable_computing [at] interval [dot] usl.edu Message-Id: Organization: Slava Nesterov Date: Sat, 18 Mar 2000 11:25:52 +0300 (MSK) Reply-To: nest [at] into [dot] nit.spb.su From: "Slava Nesterov" X-Mailer: dMail [Demos Mail for DOS v1.23] Subject: Reliable Computing, issue 3 , 2000 Lines: 37 Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Reliable Computing Volume 6, Issue 3, 2000 Special Issue on Applications to Control, Signals and Systems Guest Editors: J"urgen Garloff and 'Eric Walter Foreword 229-230 Composite Interval Control Systems: Some Strong Kharitonov-Like Properties Long Wang 231-246 Nonconvex Polygon Interval Arithmetic as a Tool for the Analysis and Design of Robust Control Systems Yuzo Ohta 247-279 Analysis of the Robustness of Predictive Controllers via Modal Intervals Josep Veh'i, Jos'e Rodellar, Miguel Sainz, Joaquim Armengol 281-301 Application of Bernstein Expansion to the Solution of Control Problems J"urgen Garloff 303-320 Interval Methods for Sinusoidal Parameter Estimation: A Comparative Analysis William W. Edmonson, Wen H. Lee, John M. M. Anderson 321-336 Robust Autonomous Robot Localization Using Interval Analysis Michel Kieffer, Luc Jaulin, 'Eric Walter, Dominique Meizel 337-361  From owner-reliable_computing [at] interval [dot] usl.edu Sun Mar 19 23:32:17 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id XAA00610 for reliable_computing-outgoing; Sun, 19 Mar 2000 23:32:17 -0600 (CST) Received: from bologna.vision.caltech.edu (bologna.vision.caltech.edu [131.215.163.1]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id XAA00605 for ; Sun, 19 Mar 2000 23:31:58 -0600 (CST) Received: from modena.vision.caltech.edu (modena.vision.caltech.edu [131.215.163.56]) by bologna.vision.caltech.edu (8.9.3/8.9.3) with ESMTP id VAA08832 for ; Sun, 19 Mar 2000 21:29:54 -0800 (PST) Received: (from arrigo@localhost) by modena.vision.caltech.edu (8.9.3+Sun/8.9.1) id VAA01224; Sun, 19 Mar 2000 21:31:30 -0800 (PST) Date: Sun, 19 Mar 2000 21:31:30 -0800 (PST) Message-Id: <200003200531.VAA01224 [at] modena [dot] vision.caltech.edu> X-Authentication-Warning: modena.vision.caltech.edu: arrigo set sender to arrigo [at] vision [dot] caltech.edu using -f From: Arrigo Benedetti To: reliable_computing [at] interval [dot] louisiana.edu Subject: Looking for multi-interval references and software Reply-to: arrigo [at] vision [dot] caltech.edu Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Dear interval researchers, I am looking for references to multi-interval arithmetic and associated software libraries. The only tool that I have found so far which supports multi-interval arithmetic is the Interval Solver and InC++ Libraries from Delisoft. Is anyone aware of freely available libraries implementing such arithmetic? The reason why I'm interested in multi-intervals is because I think that they could be useful to keep track of both the number of bits and the position of the decimal point in fixed points calculations found in digital signal processing algorithms. Any pointer to this kind of applications is also welcome. Best regards, -Arrigo Benedetti -- Dr. Arrigo Benedetti e-mail: arrigo [at] vision [dot] caltech.edu Caltech, MS 136-93 phone: (626) 395-3695 Pasadena, CA 91125 fax: (626) 795-8649 From owner-reliable_computing [at] interval [dot] usl.edu Mon Mar 20 04:42:17 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id EAA02024 for reliable_computing-outgoing; Mon, 20 Mar 2000 04:42:17 -0600 (CST) Received: from argo.bas.bg (root [at] argo [dot] bas.bg [195.96.224.7]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id EAA02019 for ; Mon, 20 Mar 2000 04:41:38 -0600 (CST) Received: from iph.bio.bas.bg (IDENT:0@bas-bio.lines.bas.bg [195.96.252.58]) by argo.bas.bg (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id MAA05292; Mon, 20 Mar 2000 12:40:34 +0200 X-Authentication-Warning: argo.bas.bg: Host IDENT:0@bas-bio.lines.bas.bg [195.96.252.58] claimed to be iph.bio.bas.bg Received: from biomath2.bio.bas.bg (biomath2.bio.bas.bg [195.96.247.143]) by iph.bio.bas.bg (8.9.3/8.9.3) with SMTP id MAA06007; Mon, 20 Mar 2000 12:41:51 +0200 Message-Id: <200003201041.MAA06007 [at] iph [dot] bio.bas.bg> Comments: Authenticated sender is From: "Evgenija Popova" Organization: Institute of Mathematics, BAS To: Arrigo Benedetti , reliable_computing [at] interval [dot] louisiana.edu Date: Mon, 20 Mar 2000 12:31:19 +0200 Subject: Re: Looking for multi-interval references and software Reply-to: epopova [at] iph [dot] bio.bas.bg Priority: normal X-mailer: Pegasus Mail for Windows (v2.32a) Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk The computer algebra system Mathematica supports multi-intervals and multi-precision interval arithmetic in the kernel. E. Popova ----------------------------------------------------------------------- Inst.of Mathematics & Informatics Phone: (+359 2) 979-3704 (office) Bulgarian Academy of Sciences (+359 2) 989-9408 (home) Acad. G. Bonchev str., Block 8 Fax: (+359 2) 971-3649 BG-1113 Sofia, Bulgaria E-mail: epopova [at] iph [dot] bio.bas.bg epopova [at] bas [dot] bg ----------------------------------------------------------------------- From owner-reliable_computing [at] interval [dot] usl.edu Mon Mar 20 09:24:57 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id JAA02569 for reliable_computing-outgoing; Mon, 20 Mar 2000 09:24:57 -0600 (CST) Received: from recife.di.ufpe.br (recife.di.ufpe.br [150.161.2.1]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id JAA02564 for ; Mon, 20 Mar 2000 09:24:31 -0600 (CST) Received: from limoeiro.diufpe (limoeiro [150.161.2.69]) by recife.di.ufpe.br (8.9.3+Sun/8.9.3) with ESMTP id MAA13849; Mon, 20 Mar 2000 12:23:37 -0300 (EST) Received: (from vk@localhost) by limoeiro.diufpe (8.9.1b+Sun/8.9.1) id MAA02480; Mon, 20 Mar 2000 12:23:37 -0300 (EST) Date: Mon, 20 Mar 2000 12:23:37 -0300 (EST) From: Vladik Kreinovich X-Sender: vk@limoeiro To: reliable_computing [at] interval [dot] usl.edu cc: Marcilia Andrade Campos , Antonio Carlos da Rocha Costa Subject: electronic journal: an idea Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Dear Friends, We need your advise and help. IDEA: LAUNCHING AN ELECTRONIC JOURNAL I am currently visiting with Marcilia Campos in Recife, Brazil. Marcilia, together with Rocha Costa and Gracaliz (two Brazilian researchers who are also currently visiting Recife), and with several other reseachers from Brazil, have an idea of starting an electronic journal on mathematics of computation, which will have a strong emphasis on interval computations and related issues. We discussed this idea with Ruy Queiroz, who is one of the founders of a very successful international electronic journal on logic IGPL. Ruy emphasized that the success of his journal was due to the fact that the very idea of the journal and all the changes and decisions were made by a strong consensus among the logic community, a community which strongly supported the journal and continues to support it now. Following Ruy's advise, we are therefore seeking advise and help from the interval community. In this following part of this message, I will describe how I understand the idea. We want the community's opinion on: * whether launching this journal as an international journal is a good idea at all (see details below), and * whether the specific implementation that we have in mind is the best or any other ideas will serve the community better. Please take into consideration that right now, I mainly act as a communicator, I did not participate in the launching of this journal, it was all done by the Brazilian team (Siegfried Rump also helped by submitting his paper to the preliminary Issue 0). This email was discussed by the current editors. I myself am staying here during my spring break, and I will be glad to help facilitate communications. First, the need for the journal as we see it. There are several main goals which this journal is intended to achieve. WHY SUCH A JOURNAL CAN BENEFIT THE INTERNATIONAL INTERVAL COMMUNITY Several of these goals are related to the success of Reliable Computing. We may be not yet a commercial success in the sense that the number of paying subscribers is still low, but to a large extent, we are a scientific success in the sense that we already have a lot of good papers published, accepted, and submitted to the journal. Due to this scientific success, there are two problems: * the lag between submitting and publishing a paper is growing, and * long survey papers have to wait even longer for a space. Similar problems caused Ruy and Dov Gabbay to launch the IGPL Bulletin several years ago, as a journal intended mainly for short communications and long surveys (in the style, e.g., of Bulletin of American Mathematical Society). We are therefore proposing that this electronic journal serve as a publication venue mainly for two types of papers: * Short communications of the results, which the authors want to publish fast. The word "fast" is where the community's support is important. We do not want to create a competitor for Reliable Computing. We are not yet at the stage where we can afford two good journals, even RC is still struggling financially. However, it may often be a good idea to first publish a short result, and then work on a longer version that will be published later in RC. This arrangement may sound unusual for mathematical community, but in Computer Science and Artificial Intelligence, a similar arrangement is normal: * first, a paper is submitted to one of the major conferences, where a short paper is refereed and published fast, and then * a longer paper is sent to the journal like Theoretical Computer Science or Artificial Intelligence. A similar arrangement exists: * in physics, where a publication, say, in Phys. Rev. Letters is usually followed by a slower but longer one, and * to some extent, in mathematics, where a short research report in Bulletin of AMS is often followed by a longer paper published elsewhere. One important sources of such short communications is conferences. We can ask the authors for 2-4 page extended abstracts, and make a selection based on refereeing these abstracts (like people in Computer Science do). Conference proceedings published before the conference will form one type of special issues. There can be other types, e.g., regional issues which highlight the results of one regional group. * The second type of papers are surveys. Again, since for the electronic journal, there is no limitation on the size, we can publish long surveys fast. The paper published in the electronic journal should be refereed, so it is a serious publication, and if this paper is later enlarged and sent to RC or any other journal, RC will get an additional advantage that the paper has already been improved: * by following the advise of the referees of the original paper, and * by the comments which the readers of the electronic journal paper will give to the authors. In addition to these two types of refereed papers, we can have other things in the electronic journal: * non-refereed papers which are published at the discretion of the editors as preliminary results for discussion; there should be a clearly marked section consisting of such papers; * information on on-going projects; * short descriptions of theses and dissertations (this is done in many fast-publication journals such as Bulletin of the European Association for Theoretical Computer Science); * announcements of upcoming conferences and other events of interest to the community. Ruy's experience shows that many people have trouble downloading papers posted in different formats, especially in the beginning, so it is very important to have a hardcopy version in addition to the electronic one. The hardcopy version shall be sent to those who request it for a nominal fee which covers the cost of printing the files, mailing the texts, etc. The hardcopy version will also serve the needs of the students who would like to show copies of their published papers to the places where they interview, etc. WHY THIS JOURNAL WOULD BENEFIT BRAZILIAN RESEARCH COMMUNITY The above were the reason why this journal may be of value to the international interval community. There are also several reasons why Brazilian people launch it in the first place. They are very enthusiastic about interval computations and related issues, and they believe that if Brazil will be the launching pad of this new electronic journal, it will boost interval research in Brazil the same way as launching the original Interval Computations journal boosted interval research in Russia. The 1996 conference did boost interval research in Brazil, and it is not a bad idea to add the additional boost. More specifically, * The journal will inevitably have a strong Brazilian participation, which will add visibility to Brazilian research. * The editors are planning several special issues, some of which will be devoted exclusively to Brazilian research. * The editors also plan to actively solicit papers from local people. This will highlight the Brazilian results for the international community, and hopefully also boost international collaboration (this is the reason why I am here: USA's National Science Foundation and its Brazilian counterpart have a joint research program, and collaboration with other countries is welcomed by the Brazilian research foundation, because there is a feeling that there is not enough collaboration right now). * Second, students and researchers will be encouraged to submit papers to the electronic journal. The good thing about Brazilian education is that every thesis or dissertation has to have an abstract in English, and many are written in English. * Third, researchers and students from all Brazilian universities (even those which are not subscribed to RC) will get some information about intervals (this works for other developing countries as well). PLEASE HAVE A LOOK The preliminary version of the first issue is posted on http://gmc.ucpel.tche.br/bejmc Warning: Some ps files do not seem to work well with Netscape, we are working on it. Also, we had an argument about whether links should be highlighted (right now they are not), we are undecided on which is the better way. Overall, however, most papers are readable, and we will appreciate any suggestions about the layout. TWO OPTIONS: INTERNATIONAL OR REGIONAL E-JOURNAL Overall, there are two main options: * If the community agrees that this is a good idea, we can make it an international electronic journal; in this case, the title should probably be changed to make everyone understand that this is a Brazil-published international journal. One possible change is to delete the word "Brazilian" from the title, and add a second title which is the same but Portuguese, thus making everyone understand that this is a Brazilian-published international journal. * On the other hand, if the general feeling of the community is that we are not yet ready for a truly international electronic journal, we can then launch a Brazilian journal, which will mainly take papers from Brazilian researchers but which will welcome papers from the international community as well. It may eventually grow into a truly international electronic journal when the conditions become ripe. Meanwhile, it will be one more English-language journal publishing results in interval computations. CONCLUSION: WE NEED YOUR ADVISE We need your suggestions and your advise. WHERE TO SEND REPLIES I am here until Friday, and Gracaliz and Rocha Costa are leaving Thursday, so if you send your replies before that, we will be able to react collectively and fast. I am using a new interface with which I am not very familiar (I guess it is a version of XWindows), so please send your replies to this email, and also, just in case, to my regular email address vladik [at] cs [dot] utep.edu, and to Marcilia at mac [at] di [dot] upfe.br. Yours sincerely Vladik From owner-reliable_computing [at] interval [dot] usl.edu Tue Mar 21 20:51:19 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id UAA08023 for reliable_computing-outgoing; Tue, 21 Mar 2000 20:51:19 -0600 (CST) Received: from kleene.math.wisc.edu (kleene.math.wisc.edu [144.92.166.90]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id UAA08018 for ; Tue, 21 Mar 2000 20:51:08 -0600 (CST) Received: from bing.math.wisc.edu (bing.math.wisc.edu [144.92.166.133]) by kleene.math.wisc.edu (8.9.3/8.9.3) with SMTP id UAA21173; Tue, 21 Mar 2000 20:43:18 -0600 (CST) Date: Tue, 21 Mar 2000 20:35:37 -0600 (CST) From: Hans Schneider To: NETS -- at-net , "Hershkowitz, Danny -- Hershkowitz Daniel" , Danny Hershkowitz , E-LETTER , "na.digest" , ipnet-digest [at] math [dot] msu.edu, wim@bell-labs.com, hjt [at] eos [dot] ncsu.edu, vkm [at] eedsp [dot] gatech.edu, reliable_computing [at] interval [dot] louisiana.edu Subject: LAA contents Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Dear Net Organizer: Please circulate the attached LAA contents over your net. Thanks hans ------------------------------------------------------------------------------ Hans Schneider hans [at] math [dot] wisc.edu. Department of Mathematics 608-262-1402 (Work) Van Vleck Hall 608-271-7252 (Home) 480 Lincoln Drive 608-263-8891 (Work FAX) University of Wisconsin-Madison 608-271-8477 (Home FAX) Madison WI 53706 USA http://www.math.wisc.edu/~hans (URL) ------------------------------------------------------------------------------ ContentsDirect from Elsevier Science ===================================== URL: http://www.elsevier.nl/locate/jnlnr/07738 Journal: Linear Algebra and Its Applications ISSN : 0024-3795 Volume : 307 Issue : 1-3 Date : 31-Mar-2000 pp 1-14 The positive definite completion problem relative to a subspace CR Johnson, RL Smith pp 15-33 The local exponent sets of primitive digraphs MINO Zhengke pp 35-46 Characteristic polynomials of graphs having a semifree action JAEUN Lee pp 47-67 Some remarks on quasi-equivalence of bases in Frechet spaces N Zobin pp 69-75 A norm bound for projections with complex weights EY Bobrovnikova, SA Vavasis pp 77-87 On lattice property of group induced cone orderings M Niezgoda pp 89-101 Stable subnorms M Goldberg pp 103-117 On the ultimate behavior of the sequence of consecutive powers of a matrix in the max-plus algebra B De Schutter pp 119-129 Strengthening the Gilbert-Varshamov bound A Barg, J Simonis pp 131-144 A matrix inequality and its statistical application J Jiang pp 145-150 Two-dimensional representations of the free group in two generators over an arbitrary field L Vaserstein pp 151-165 Principal pivot transforms: properties and applications M Tsatsomeros pp 167-182 Linear matrix period in max-plus algebra M Gavalec pp 183-192 Free product Z_3 * Z_3 of rotations with rational entries G Liu, LC Robertson pp 195-195 Author index ------- NOTE: ContentsDirect, which is automatically generated, lists the first author of each paper and the corresponding author (if different). From owner-reliable_computing [at] interval [dot] usl.edu Wed Mar 22 04:06:14 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id EAA08668 for reliable_computing-outgoing; Wed, 22 Mar 2000 04:06:14 -0600 (CST) Received: from mbox.diima.unisa.it (mbox.diima.unisa.it [193.205.163.4]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with SMTP id EAA08663 for ; Wed, 22 Mar 2000 04:05:57 -0600 (CST) Received: from pc2.diiie.unisa.it [193.205.164.124] (HELO pc1) by mbox.diima.unisa.it (AltaVista Mail V2.0/2.0 BL23 listener) id 0000_0074_38d8_99f0_1f54; Wed, 22 Mar 2000 11:01:20 +0100 Message-Id: <4.1.20000322105604.0093a8c0 [at] cesare [dot] diiie.unisa.it> X-Sender: spanish [at] cesare [dot] diiie.unisa.it X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 22 Mar 2000 11:04:57 +0100 To: reliable_computing [at] interval [dot] usl.edu From: "G.Spagnuolo" Subject: interval matrix exponential Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Dear researchers, I am searching for papers describing new approaches to the calculation of the exponential of an interval matrix. Namely I have A as an interval matrix (not diagonal) and I need to calculate exp(A). Of course, by using the classical approach of the Taylor expansion, even using a nested form, a great overestimation of the result can often be verified. On the other side, an interval extension of the Pade approach is quite difficult, I think. Have you any suggestion? Many thanks in advance. Regards. Giovanni -- Dr. Giovanni Spagnuolo, Ph.D. Assistant Professor Dipartimento di Ingegneria dell'Informazione ed Ingegneria Elettrica D.I.I.I.E. University of Salerno Via Ponte Don Melillo I-84084 Fisciano (SA) - ITALY Phone +39 089 964258 Fax +39 089 964218 www page: http://www.diiie.unisa.it/it/aree/el_tcn/persone/collab/gs/gs.htm NOTE: NEW E-MAIL ADDRESS --> spanish [at] ieee [dot] org <--- From owner-reliable_computing [at] interval [dot] usl.edu Wed Mar 22 04:35:02 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id EAA09028 for reliable_computing-outgoing; Wed, 22 Mar 2000 04:35:02 -0600 (CST) Received: from solon.mat.univie.ac.at (solon.mat.univie.ac.at [131.130.145.131]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id EAA09023 for ; Wed, 22 Mar 2000 04:34:58 -0600 (CST) Received: (from neum@localhost) by solon.mat.univie.ac.at (8.9.3/8.9.3) id LAA30678; Wed, 22 Mar 2000 11:34:55 +0100 (MET) Date: Wed, 22 Mar 2000 11:34:55 +0100 (MET) From: Arnold Neumaier Message-Id: <200003221034.LAA30678 [at] solon [dot] mat.univie.ac.at> To: reliable_computing [at] interval [dot] usl.edu, spanish [at] ieee [dot] org Subject: Re: interval matrix exponential Cc: neum [at] cma [dot] univie.ac.at Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk >>I am searching for papers describing new approaches to the calculation of the exponential of an interval matrix.<< You may find A. Neumaier, Global, rigorous and realistic bounds for the solution of dissipative differential equations. Part I: Theory, Computing 52 (1994), 315-336. http://solon.cma.univie.ac.at/~neum/papers.html#ode useful in this respect. (Specialize the general case to a constant coefficient differential equation.) Arnold Neumaier From owner-reliable_computing [at] interval [dot] usl.edu Wed Mar 22 06:59:48 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id GAA09464 for reliable_computing-outgoing; Wed, 22 Mar 2000 06:59:48 -0600 (CST) Received: from csc-sun.math.utah.edu (root@csc-sun.math.utah.edu [128.110.198.2]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id GAA09459 for ; Wed, 22 Mar 2000 06:59:45 -0600 (CST) Received: from suncore.math.utah.edu (suncore0.math.utah.edu [128.110.198.5]) by csc-sun.math.utah.edu (8.9.3/8.9.3) with ESMTP id FAA15780; Wed, 22 Mar 2000 05:59:41 -0700 (MST) Received: (from beebe@localhost) by suncore.math.utah.edu (8.9.3/8.9.3) id FAA01779; Wed, 22 Mar 2000 05:59:41 -0700 (MST) Date: Wed, 22 Mar 2000 05:59:41 -0700 (MST) From: "Nelson H. F. Beebe" To: "G.Spagnuolo" Cc: beebe [at] math [dot] utah.edu, reliable_computing [at] interval [dot] usl.edu X-US-Mail: "Center for Scientific Computing, Department of Mathematics, 322 INSCC, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: interval matrix exponential Message-ID: Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Giovanni Spagnuolo writes on Wed, 22 Mar 2000 11:04:57 +0100: >> I am searching for papers describing new approaches to the calculation of >> the exponential of an interval matrix. While this paper doesn't address interval arithmetic, if you weren't aware of it already, you might find it a useful guide into the older literature: @String{j-SIAM-REVIEW = "SIAM Review"} @Article{Moler:1978:NDW, author = "C. B. Moler and C. F. {Van Loan}", title = "Nineteen dubious ways to compute the exponential of a matrix", journal = j-SIAM-REVIEW, volume = "20", number = "4", pages = "801--836", month = oct, year = "1978", CODEN = "SIREAD", ISSN = "0036-1445", bibdate = "Fri Mar 21 15:55:27 MST 1997", acknowledgement = ack-nhfb, classcodes = "C4140 (Linear algebra)", corpsource = "Dept. of Math., Univ. of New Mexico, Albuquerque, NM, USA", keywords = "eig; matrix algebra; matrix exponential; matrix function; nla", treatment = "A Application; G General Review", } Here are two more from my files: @String{j-IEEE-TRANS-CIRCUITS-SYST = "IEEE Transactions on Circuits and Systems"} @Article{Oppenheimer:1988:AIAb, author = "E. P. Oppenheimer and Anthony N. Michel", title = "Application of interval analysis techniques to linear systems. {II}. The interval matrix exponential function", journal = j-IEEE-TRANS-CIRCUITS-SYST, volume = "35", number = "10", pages = "1230--1242", month = oct, year = "1988", CODEN = "ICSYBT", ISSN = "0098-4094", bibdate = "Thu Dec 14 17:19:38 MST 1995", abstract = "For pt.I see ibid., vol.35, no.9, p.1129-38 (1988). In part I the authors established new results for continuous and rational interval functions which are of interest in their own right. The authors use these results to study interval matrix exponential functions and to devise a method of constructing augmented partial sums which approximate interval matrix exponential functions as closely as desired. The authors introduce and study `scalar' and matrix interval exponential functions. These functions are represented as infinite power series and their properties are studied in terms of rational functions obtained from truncations. To determine optimal estimates of error bounds for the truncated series representation of the exponential matrix function, the authors establish appropriate results dealing with Householder norms. In order to reduce the conservativeness for interval arithmetic operations, they consider the nested form for interval polynomials and the centered form for interval arithmetic representations. They also discuss briefly machine bounding arithmetic in digital computers. Finally, the authors present an algorithm for the computation of the interval matrix exponential function which yields prespecified error bounds.", acknowledgement = ack-nhfb, affiliation = "Appl. Phys. Lab., Johns Hopkins Univ., Laurel, MD, USA", classification = "C1210 (General system theory); C4140 (Linear algebra); C4130 (Interpolation and function approximation)", keywords = "Interval analysis techniques; Linear systems; Interval matrix exponential function; Augmented partial sums; Infinite power series; Rational functions; Optimal estimates; Error bounds; Truncated series representation; Householder norms; Nested form; Interval polynomials; Centered form; Interval arithmetic representations; Machine bounding arithmetic; Digital computers", language = "English", pubcountry = "USA", thesaurus = "Linear systems; Matrix algebra; Polynomials", } @String{j-COMPUTING = "Computing"} @Article{Bochev:1989:SVN, author = "P. Bochev and S. Markov", title = "A self-validating numerical method for the matrix exponential", journal = j-COMPUTING, volume = "43", number = "1", pages = "59--72", month = "", year = "1989", CODEN = "CMPTA2", ISSN = "0010-485X", bibdate = "Thu Dec 14 17:20:22 MST 1995", abstract = "An algorithm is presented, which produces highly accurate and automatically verified bounds for the matrix exponential function. The computational approach involves iterative defect correction, interval analysis and advanced computer arithmetic. The algorithm presented is based on the `scaling and squaring' scheme, utilizing Pade approximations and safe error monitoring. A PASCAL-SC program is reported and numerical results are discussed.", acknowledgement = ack-nhfb, affiliation = "Inst. of Math., Bulgarian Acad. of Sci., Sofia, Bulgaria", classification = "B0290H (Linear algebra); C4140 (Linear algebra)", keywords = "Self-validating numerical method; Matrix exponential; Computational approach; Iterative defect correction; Interval analysis; Advanced computer arithmetic; Pade approximations; Safe error monitoring; PASCAL-SC program; Numerical results", language = "English", pubcountry = "Austria", thesaurus = "Iterative methods; Matrix algebra", } ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 585 1640, +1 801 581 4148 - - University of Utah Internet e-mail: beebe [at] math [dot] utah.edu - - Department of Mathematics, 322 INSCC beebe [at] acm [dot] org beebe [at] computer [dot] org - - 155 S 1400 E RM 233 beebe [at] ieee [dot] org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- From owner-reliable_computing [at] interval [dot] usl.edu Wed Mar 22 10:35:07 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id KAA09959 for reliable_computing-outgoing; Wed, 22 Mar 2000 10:35:07 -0600 (CST) Received: from recife.di.ufpe.br (recife.di.ufpe.br [150.161.2.1]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id KAA09954 for ; Wed, 22 Mar 2000 10:34:10 -0600 (CST) Received: from limoeiro.diufpe (limoeiro [150.161.2.69]) by recife.di.ufpe.br (8.9.3+Sun/8.9.3) with ESMTP id NAA10061; Wed, 22 Mar 2000 13:32:39 -0300 (EST) Received: (from vk@localhost) by limoeiro.diufpe (8.9.1b+Sun/8.9.1) id NAA12654; Wed, 22 Mar 2000 13:32:39 -0300 (EST) Date: Wed, 22 Mar 2000 13:32:38 -0300 (EST) From: Vladik Kreinovich X-Sender: vk@limoeiro To: reliable_computing [at] interval [dot] usl.edu cc: toom [at] bernoulli [dot] de.ufpe.br Subject: computing critical values Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Dear Friends, Andrei Toom, a researcher from the Federal University of Pernambuco, Brazil, asked me whether there are any applications of interval computations to computing critical values for mathematical models in statistical physics (e.g., percolation). Please answer him at toom [at] bernoulli [dot] de.ufpe.br. Thanks. Vladik From owner-reliable_computing [at] interval [dot] usl.edu Sun Mar 26 16:48:23 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id QAA00530 for reliable_computing-outgoing; Sun, 26 Mar 2000 16:48:23 -0600 (CST) Received: from cs.utep.edu (mail.cs.utep.edu [129.108.5.3]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id QAA00525 for ; Sun, 26 Mar 2000 16:48:19 -0600 (CST) Received: from earth (earth [129.108.5.21]) by cs.utep.edu (8.9.3+Sun/8.9.1) with SMTP id PAA12913 for ; Sun, 26 Mar 2000 15:48:15 -0700 (MST) Message-Id: <200003262248.PAA12913 [at] cs [dot] utep.edu> Date: Sun, 26 Mar 2000 15:48:15 -0700 (MST) From: Vladik Kreinovich Reply-To: Vladik Kreinovich Subject: from NA Digest To: reliable_computing [at] interval [dot] usl.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 3MkfqiE83trOivLN/GAQZQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4 SunOS 5.7 sun4u sparc Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk From: Paul Barton Date: Mon, 13 Mar 2000 14:56:30 -0500 Subject: DAEPACK Version 1.0 Announcement ANNOUNCING DAEPACK VERSION 1.0 The Massachusetts Institute of Technology is pleased to announce the availability of DAEPACK version 1.0 for academic and commercial uses licensing. DAEPACK is a symbolic and numeric library for general numerical calculations. What distinguishes DAEPACK from other software libraries for numerical computations is a set of symbolic components that operate directly on very general Fortran-90 code provided by the user. The symbolic components take as input a set of Fortran-90 source files defining a system of equations of interest and generate a new set of Fortran-90 subroutines and functions computing quantities such as analytical derivatives matrices, sparsity patterns, etc. The original Fortran-90 code may contain an arbitrary number of subroutine and function calls, common blocks, sophisticated solution strategies embedded within the model evaluation, etc. The information generated automatically by DAEPACK is exploited in a collection of state-of-the-art numerical algorithms for performing tasks such as solution of large sets of nonlinear equations, efficient numerical integration and parametric sensitivity calculation, hybrid discrete/continuous simulation, and others. In addition, this new information can be used with third party or custom numerical algorithms to provide information that would otherwise have to be generated by hand. Currently, the symbolic components generate: 1) General derivative matrices, J(x)S, where J(x) is the Jacobian matrix and S is and arbitrary conformable matrix. Setting S equal to the identity matrix yields the Jacobian matrix. Sparsity is exploited both in derivative computation and storage. 2) Sparsity patterns. 3) Discontinuity-locked models. 4) Interval extensions of the original system of equations. In all of the cases above, new code is generated that can be compiled and linked into other applications to provide the desired information. Currently, the numerical components provided with DAEPACK are: 1) Block solution of large sparse sets of nonlinear algebraic equations. The structural information of the system of equations obtained with the sparsity pattern code described above is used to permute the system into block lower triangular form where the overall system of equations is solved as a sequence of smaller blocks. Derivative code is generated in order to extract efficiently the submatrix of the Jacobian corresponding to the current block. 2) Efficient numerical integration and parametric sensitivity calculation exploiting the sparsity pattern and analytical derivatives generated automatically. 3) Hybrid discrete/continuous numerical integration and parametric sensitivity calculation using the sparsity pattern, analytical derivatives, and discontinuity-locked model generated automatically. 4) Intelligent model analysis based on the Dulmage-Mendelsohn decomposition, exploiting the sparsity pattern generated automatically. DAEPACK is available on the following platforms: Windows 9x, Windows NT, UNIX (HPUX and Sun Solaris), and Linux. The Windows versions of DAEPACK are provided with a graphical user interface that facilitates the automatic generation of code using the symbolic components. Future releases of DAEPACK will include a larger set of symbolic and numeric algorithms and a graphical environment for "numerical flowsheeting", the construction of numerical algorithms graphically. Furthermore, greater support for the automatic construction of CAPE-Open compliant components from legacy Fortran code will be provided. More information about DAEPACK can be found at the following website: http://yoric.mit.edu/daepack/daepack.html For additional information, including licensing, contact: John Tolsma Postdoctoral Associate Department of Chemical Engineering Massachusetts Institute of Technology 77 Massachusetts Avenue Room 66-365 Cambridge MA 02139 (phone) 617-253-5513 (fax) 617-258-5042 jtolsma [at] mit [dot] edu Paul I. Barton Associate Professor Department of Chemical Engineering Massachusetts Institute of Technology, 66-464 77 Massachusetts Avenue Cambridge MA 02139 From owner-reliable_computing [at] interval [dot] usl.edu Mon Mar 27 00:13:53 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id AAA01117 for reliable_computing-outgoing; Mon, 27 Mar 2000 00:13:52 -0600 (CST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id AAA01112 for ; Mon, 27 Mar 2000 00:13:49 -0600 (CST) From: banavar [at] us [dot] ibm.com Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id BAA75168; Mon, 27 Mar 2000 01:07:22 -0500 Received: from D51MTA03.pok.ibm.com (d51mta03.pok.ibm.com [9.117.200.31]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id AAA143108; Mon, 27 Mar 2000 00:58:32 -0500 Received: by D51MTA03.pok.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568AF.0020C506 ; Mon, 27 Mar 2000 00:57:55 -0500 X-Lotus-FromDomain: IBMUS To: ICDCS_99 [at] us [dot] ibm.com, dbworld [at] cs [dot] wisc.edu, distributed-ai-request [at] mailbase [dot] ac.uk, ecoop-info [at] ecoop [dot] org, podc-post [at] bellcore [dot] com, reliable_computing [at] interval [dot] usl.edu, distributed-ai-request [at] mailbase [dot] ac.uk Message-ID: <852568AF.0020C352.00 [at] D51MTA03 [dot] pok.ibm.com> Date: Sun, 26 Mar 2000 22:51:20 -0500 Subject: Middleware 2000: Final call for participation Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Colleagues, This conference is happening next week. It's promising to be a big success, with a large participation and several highlights (see below). We'll be delighted if you join us. -------- Guruduth Banavar Publicity Chair, Middleware 2000 Conference =============================================================== CALL FOR PARTICIPATION Middleware 2000 The International Conference on Distributed Systems Platforms and Open Distributed Processing April 4 - 8, 2000 Hudson Valley (near New York City) USA http://www.research.ibm.com/Middleware2000 The advance program is available on our web site. We invite you to register now to join us for this premier conference in April. Sponsored by IFIP TC6 WG6.1 and ACM Supported by Agilent Technologies and IBM CONFERENCE BACKGROUND --------------------- Middleware 2000 will be the premier conference on distributed systems platforms and open distributed processing in the opening year of the new millenium. The conference is a synthesis of the major conferences and workshops in this area into a single international event. Middleware 2000 follows in the footsteps of the extremely successful, inaugural Middleware '98 Conference held in the Lake District of the UK in September, 1998. The focus of Middleware 2000 is on the design, implementation, deployment and evaluation of distributed systems platforms and architectures for future networked environments. Of particular interest is the application of both new and existing architectures and platforms (such as RM-ODP, CORBA, RMI and DCOM) in environments which may include public and private networks, overlayed wired and wireless technologies, IPv6 and IP multicast, multimedia and real-time information and an increasing volume of WWW and Java traffic. SOME CONFERENCE HIGHLIGHTS -------------------------- Middleware 2000 is a single-track conference consisting of seven paper sessions, two keynote addresses, and a work-in-progress session. There will also be posters presented during breaks. 1) The seven paper sessions are on Messaging, Caching, Reflection, Indirection, Quality of Service, Transactions and Workflow, and Composition. The details of the paper program is at: http://www.research.ibm.com/Middleware2000/Program/program.html 2) We are offering four tutorials by leading practitioners: April 4 AM Tutorials: T1. "Scalability Issues in CORBA-based Systems" Steve Vinoski, IONA Technologies T2. "Designing with Patterns" John Vlissides, IBM TJ Watson Research Center April 4 PM Tutorials: T3. "Middleware for Programmable Networks" Andrew Campbell, Columbia University T4. "Applying Patterns for Concurrent and Distributed Components" Frank Buschman, Siemens ZT More information on the tutorials is at: http://www.research.ibm.com/Middleware2000/Tutorials/tutorials.html 3. We are organizing a workshop on Reflective Middleware (RM2000) that will be co-located with Middleware 2000. Information on the RM2000 workshop can be found at: http://www.comp.lancs.ac.uk/computing/RM2000/ 4. We will have two keynote addresses by visionaries in the field of middleware: Ken Birman, Professor at Cornell University, and Jim Waldo of Sun Microsystems. 5. We will have a work-in-progress paper session and multiple poster sessions. Information on the WiP papers and posters will be available at: http://www.research.ibm.com/Middleware2000 LOCATION AND ACTIVITIES ----------------------- The conference will be held at the beautiful Hudson River Valley. The IBM Palisades Conference Center is a state-of-the-art meeting center on 106 acres of land, just north of New York City. Check out the URL. http://www.research.ibm.com/Middleware2000/Location/location.html There will be social events as part of this year's conference, including a Welcome Reception where participants can meet the organizing team and other participants in an informal setting. We will also be providing luncheons and dinner to all attendees on all three days of the conference. Lunch will also be provided to people attending the workshop and to those attending the tutorials. Information on these activities will be available on the conference web page. REGISTRATION ------------ Don't delay and register today for Middleware 2000. It is THE conference to attend. With a great location, on a naturally rich Hudson Valley near culturally rich Manhattan, you can't ask for anything more. We look forward to seeing you there. -------------------------------------------------------------------- Important URL for registration: http://www.regmaster.com/midd2000.html ---------------------------------------------------------------------- From owner-reliable_computing [at] interval [dot] usl.edu Mon Mar 27 13:28:18 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id NAA02268 for reliable_computing-outgoing; Mon, 27 Mar 2000 13:28:18 -0600 (CST) Received: from d71.ucs.usl.edu (root [at] d71 [dot] ucs.usl.edu [130.70.115.71]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id NAA02263 for ; Mon, 27 Mar 2000 13:28:15 -0600 (CST) Received: from d71.ucs.usl.edu (rbk5287 [at] d71 [dot] ucs.usl.edu [130.70.115.71]) by d71.ucs.usl.edu (8.9.1/8.9.1/ucs-client_1.3) with SMTP id NAA04281 for ; Mon, 27 Mar 2000 13:28:14 -0600 (CST) Message-Id: <200003271928.NAA04281 [at] d71 [dot] ucs.usl.edu> Date: Mon, 27 Mar 2000 13:28:13 -0600 (CST) From: Kearfott Ralph B Reply-To: Kearfott Ralph B Subject: Intervals and Fortran To: reliable_computing [at] interval [dot] ull.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: U1dHn4Dtsf4i7JQWns5OwQ== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Friends, Even though I've been off the Fortran standardization committee for two years, I note that intervals still have a presence in the Fortran 2000 requirements. Please see items R4d and R4f in the requirements list below. (Also, please, if you have specific comments concerning interval arithmetic, please reply first to me or to this list, rather than John Reid.) Finally, I hope we will continue to educate non-experts concerning misconceptions, capabilities and limitations of interval computations. Best regards, Baker P.S. Support for IEEE arithmetic has been included in the standard separately from the enabling technology for interval arithmetic. ------------- Begin Forwarded Message ------------- Date: Mon, 27 Mar 2000 13:46:21 +0100 (BST) From: John Reid To: SC22WG5 [at] dkuug [dot] dk Subject: (SC22WG5.1727) Content of F2000 MIME-Version: 1.0 X-md5sum: 3667562d0ee17fc1c07417557f6f1aa4 X-md5sum-Origin: ex1.ncsa.uiuc.edu Dear WG5, To help our work in Oulu, I have constructed a revised version of N1259 (adopted in 1997). I have added reference keys, as used at the original meeting and by J3 subsequently, and reordered the items by key. I have made changes corresponding to resolutions at subsequent WG5 meetings. I believe it represents the current position of WG5 re the revision. I would be most grateful to hear of any mistakes I have made in constructing this. Best wishes, John. ....................... ISO/IEC JTC1/SC22/WG5 N1382 (draft) CONTENT OF FORTRAN 2000 1. Required Content of Fortran 2000 Following Resolutions at the Las Vegas (2/97), Vienna (7/97), Trollhattan (6/98) and Cadarache (6/99) meetings, WG5 has determined that Fortran 2000 shall contain the following items: Floating point exception handling TR 15580 Allocatable components TR 15581 R1 Derived type I/O N1322 R2 Asynchronous I/O (see N1189 item #52) R3 Procedure pointers (see N1189 item #43) R4d Enabling technology for interval arithmetic: Control of I/O rounding T9 in N1323 R4f Enabling technology for interval arithmetic: Constants for opaque types T9 in N1323 R5 Parameterized derived types (see N1189 item #14) R6a Inheritance (see N1189 item #88 and N1272) R6b Polymorphism (see N1189 item #88 and N1272) R7 Constructors/destructors (see N1189 item #89) R8 Internationalization N1320 R9 Interoperability with C N1321 Note that N1189 is the WG5 Repository of Requirements (Standing Document 5). It is the intention of WG5 that the revised standard shall be published in December 2004. WG5 requests the primary development body, should it deem necessary any amendments to the schedule, to include in the WG5 pre-meeting distribution proposals for modifications, together with detailed reasons for such recommendations (C5 in N1343). 2. Possible Additional Minor Technical Enhancements WG5 has also authorised J3 to work on the following minor technical enhancements for incorporation in Fortran 2000, subject to the proviso that any work carried out on them does not adversely affect any of the work required to address the major items listed above: B1 VOLATILE attribute (see N1269) B2 Allow PUBLIC entities of PRIVATE type (see N1189 item #75) B3 PUBLIC and PRIVATE derived type components (see N1267) B4 Stream I/O (see N1189 item #63) B5 Command-line arguments (M18a) (see N1189 item #20) B6 Access to status error messages (see N1268) B7 IEEE I/O rounding inquiry intrinsics (see N1271) M1 Increased statement length (see N1189 item #50, J3/96-138) M2 Intent for pointer arguments (see N1189 item #44, J3/96-098r1) M3 Generic rate_count in system_clock (see N1189 item #61, J3/96-116r1) M4 Specifying pointer lower bounds (see N1189 item #02, J3/96-154) M5 Extend max/min intrinsics to character (see N1189 item #64, J3/96-131r1) M6 Extended initialization expressions (see N1189 item #66, J3/96-165) M7 Mixed case syntax elements (see N1189 item #67, J3/96-055r1) M10 Named scratch files (see N1189 item #73, J3/96-169r1) M11 Passing specific/generic names (see N1189 item #59, J3/96-144) M15 Renaming defined operators (see N1189 item #41) M16 Derived type encapsulation (see J3/96-133) M17 Enhanced complex constants (see J3/96-132r1) R4a Enabling technology for interval arithmetic: Flexible operation control T9 in N1323 R4c Enabling technology for interval arithmetic: Control of operation rounding T9 in N1323 WG5 will review this list at every meeting in the light of information provided by J3 regarding the progress on the major items for Fortran 2000, and may reduce it if it feels that this will be necessary in order to meet the publication schedule. ------------- End Forwarded Message ------------- --------------------------------------------------------------- R. Baker Kearfott, rbk [at] louisiana [dot] edu (337) 482-5346 (fax) (337) 482-5270 (work) (337) 981-9744 (home) URL: http://interval.louisiana.edu/kearfott.html Department of Mathematics, University of Louisiana at Lafayette Box 4-1010, Lafayette, LA 70504-1010, USA --------------------------------------------------------------- From owner-reliable_computing [at] interval [dot] usl.edu Tue Mar 28 00:46:59 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id AAA03323 for reliable_computing-outgoing; Tue, 28 Mar 2000 00:46:58 -0600 (CST) Received: from unknown (atlanta-ip-2-50.dynamic.ziplink.net [209.206.59.50]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with SMTP id AAA03309; Tue, 28 Mar 2000 00:46:49 -0600 (CST) From: r2d2 [at] ureach [dot] com Subject: laser printer toner advertisement Date: Tue, 28 Mar 2000 10:48:04 Message-Id: <414.122700.326295@> Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk BENCHMARK SUPPLY 5334 LAKE VIEW CLUB ATLANTA GA 30338 ***LASER PRINTER TONER CARTRIDGES*** ***FAX AND COPIER TONER*** WE ACCEPT GOVERNMENT, SCHOOL & UNIVERSITY PURCHASE ORDERS JUST LEAVE YOUR PO # WITH CORRECT BILLING & SHIPPING ADDRESS CHECK OUT OUR NEW CARTRIDGE PRICES : APPLE LASER WRITER PRO 600 OR 16/600 $69 LASER WRITER SELECT 300,310.360 $69 LASER WRITER 300, 320 $54 LASER WRITER LS,NT,2NTX,2F,2G & 2SC $54 LASER WRITER 12/640 $79 HEWLETT PACKARD LASERJET SERIES 2,3 & 3D (95A) $49 LASERJET SERIES 2P AND 3P (75A) $54 LASERJET SERIES 3SI AND 4SI (91A) $75 LASERJET SERIES 4L AND 4P $49 LASERJET SERIES 4, 4M, 5, 5M, 4+ (98A) $59 LASERJET SERIES 4000 HIGH YIELD (27X) $99 LASERJET SERIES 4V $95 LASERJET SERIES 5SI , 8000 $95 LASERJET SERIES 5L AND 6L $49 LASERJET SERIES 5P, 5MP, 6P, 6MP $59 LASERJET SERIES 5000 (29A) $135 LASERJET SERIES 1100 (92A) $49 LASERJET SERIES 2100 (96A) $89 LASERJET SERIES 8100 (82X) $145 HP LASERFAX LASERFAX 500, 700, FX1, $59 LASERFAX 5000, 7000, FX2, $59 LASERFAX FX3 $69 LASERFAX FX4 $79 LEXMARK OPTRA 4019, 4029 HIGH YIELD $135 OPTRA R, 4039, 4049 HIGH YIELD $135 OPTRA S 4059 HIGH YIELD $135 OPTRA E $59 OPTRA N $115 EPSON EPL-7000, 8000 $105 EPL-1000, 1500 $105 CANON LBP-430 $49 LBP-460, 465 $59 LBP-8 II $54 LBP-LX $54 LBP-MX $95 LBP-AX $49 LBP-EX $59 LBP-SX $49 LBP-BX $95 LBP-PX $49 LBP-WX $95 LBP-VX $59 CANON FAX L700 THRU L790 FX1 $59 CANONFAX L5000 L70000 FX2 $59 CANON COPIERS PC 20, 25 ETC.... $89 PC 3, 6RE, 7, 11 (A30) $69 PC 320 THRU 780 (E40) $89 NEC SERIES 2 LASER MODEL 90,95 $105 PLEASE NOTE: 1) ALL OUR CARTRIDGES ARE GENUINE OEM CARTRIDGES. 2) WE DO NOT SEND OUT CATALOGS OR PRICE LISTS 3) WE DO NOT FAX QUOTES OR PRICE LISTS. 4) WE DO NOT SELL TO RESELLERS OR BUY FROM DISTRIBUTERS 5) WE DO NOT CARRY: BROTHER-MINOLTA-KYOSERA-PANASONIC PRODUCTS 6) WE DO NOT CARRY: XEROX-FUJITSU-OKIDATA OR SHARP PRODUCTS 7) WE DO NOT CARRY ANY COLOR PRINTER SUPPLIES 8) WE DO NOT CARRY DESKJET/INKJET OR BUBBLEJET SUPPLIES 9) WE DO NOT BUY FROM OR SELL TO RECYCLERS OR REMANUFACTURERS ****OUR ORDER LINE IS 770-399-0953 **** ****OUR CUSTOMER SERVICE LINE IS 800-586-0540**** ****OUR E-MAIL REMOVAL AND COMPLAINT LINE IS 888-494-8597**** ****PLACE YOUR ORDER AS FOLLOWS**** : BY PHONE 770-399-0953 BY FAX: 770-698-9700 BY MAIL: BENCHMARK PRINT SUPPLY 7540 BRIDGEGATE COURT , ATLANTA GA 30350 MAKE SURE YOU INCLUDE THE FOLLOWING INFORMATION IN YOUR ORDER: 1) YOUR PHONE NUMBER 2) COMPANY NAME 3) SHIPPING ADDRESS 4) YOUR NAME 5) ITEMS NEEDED WITH QUANTITIES 6) METHOD OF PAYMENT. (COD OR CREDIT CARD) 7) CREDIT CARD NUMBER WITH EXPIRATION DATE 1) WE SHIP UPS GROUND. ADD $4.5 FOR SHIPPING AND HANDLING. 2) COD CHECK ORDERS ADD $3.5 TO YOUR SHIPPING COST. 2) WE ACCEPT ALL MAJOR CREDIT CARD OR "COD" ORDERS. 3) OUR STANDARD MERCHANDISE REFUND POLICY IS NET 30 DAYS 4) OUR STANDARD MERCHANDISE REPLCAMENT POLICY IS NET 90 DAYS. NOTE NUMBER (1): PLEASE DO NOT CALL OUR ORDER LINE TO REMOVE YOUR E-MAIL ADDRESS OR COMPLAIN. OUR ORDER LINE IS NOT SETUP TO FORWARD YOUR E-MAIL ADDRESS REMOVAL REQUESTS OR PROCESS YOUR COMPLAINTS..IT WOULD BE A WASTED PHONE CALL.YOUR ADDRESS WOULD NOT BE REMOVED AND YOUR COMPLAINTS WOULD NOT BE HANDLED.PLEASE CALL OUR TOLL FREE E-MAIL REMOVAL AND COMPLAINT LINE TO DO THAT. NOTE NUMBER (2): OUR E-MAIL RETURN ADDRESS IS NOT SETUP TO ANSWER ANY QUESTIONS YOU MIGHT HAVE REGARDING OUR PRODUCTS. OUR E-MAIL RETURN ADDRESS IS ALSO NOT SETUP TO TAKE ANY ORDERS AT THIS TIME. PLEASE CALL THE ORDER LINE TO PLACE YOUR ORDER OR HAVE ANY QUESTIONS ANSWERED. OTHERWISE PLEASE CALL OUR CUSTOMER SERCICE LINE. From owner-reliable_computing [at] interval [dot] usl.edu Tue Mar 28 06:23:22 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id GAA04778 for reliable_computing-outgoing; Tue, 28 Mar 2000 06:23:22 -0600 (CST) Received: from pamela.lss.supelec.fr (IDENT:root [at] pamela [dot] lss.supelec.fr [160.228.200.4]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id GAA04773 for ; Tue, 28 Mar 2000 06:23:13 -0600 (CST) Received: from pcisabelle (dhcp95.lss.supelec.fr [160.228.200.195]) by pamela.lss.supelec.fr (8.9.3/jtpda-5.3.2) with SMTP id OAA16024 for ; Tue, 28 Mar 2000 14:24:28 +0200 Message-Id: <200003281224.OAA16024 [at] pamela [dot] lss.supelec.fr> X-Sender: braems [at] mailhost [dot] lss.supelec.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 28 Mar 2000 14:21:37 +0200 To: reliable_computing [at] interval [dot] usl.edu From: Isabelle Braems Subject: computation of volumes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Dear interval researchers, I am a first year PHD student in reliable modelization and estimation in a bounded error context. To evaluate the reliability of a datum, I need to compute volumes of sets defined by nonlinear inequalities. Could you please send me any references about the use of IA to compute such volumes? Many thanks in advance, Isabelle Braems From owner-reliable_computing [at] interval [dot] usl.edu Tue Mar 28 07:55:51 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id HAA05200 for reliable_computing-outgoing; Tue, 28 Mar 2000 07:55:51 -0600 (CST) Received: from solon.mat.univie.ac.at (solon.mat.univie.ac.at [131.130.145.131]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id HAA05195 for ; Tue, 28 Mar 2000 07:55:48 -0600 (CST) Received: (from neum@localhost) by solon.mat.univie.ac.at (8.9.3/8.9.3) id PAA18183; Tue, 28 Mar 2000 15:22:28 +0200 (MET DST) Date: Tue, 28 Mar 2000 15:22:28 +0200 (MET DST) From: Arnold Neumaier Message-Id: <200003281322.PAA18183 [at] solon [dot] mat.univie.ac.at> To: braems [at] lss [dot] supelec.fr, reliable_computing [at] interval [dot] usl.edu Subject: Re: computation of volumes Cc: neum [at] cma [dot] univie.ac.at Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk >>I need to compute volumes of sets defined by nonlinear inequalities.<< You'd have to do bisection on a box covering the region of interest, spitting recursively until the function evaluations (using centered forms) show that a box is completely inside or outside the set, or until the box is so small that you can ignore it. Then you add up the volumes of the subboxes. This will be feasible in 2 or 3 dimensions but very expensive in high dimensions since in effect you trace out the n-1 dimensional surface by covering it with the undiscarded boxes. Arnold Neumaier http://solon.cma.univie.ac.at/~neum/ From owner-reliable_computing [at] interval [dot] usl.edu Tue Mar 28 13:33:50 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id NAA06061 for reliable_computing-outgoing; Tue, 28 Mar 2000 13:33:50 -0600 (CST) Received: from cs.utep.edu (mail.cs.utep.edu [129.108.5.3]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id NAA06056 for ; Tue, 28 Mar 2000 13:33:38 -0600 (CST) Received: from earth (earth [129.108.5.21]) by cs.utep.edu (8.9.3+Sun/8.9.1) with SMTP id MAA27568 for ; Tue, 28 Mar 2000 12:33:11 -0700 (MST) Message-Id: <200003281933.MAA27568 [at] cs [dot] utep.edu> Date: Tue, 28 Mar 2000 12:33:12 -0700 (MST) From: Vladik Kreinovich Reply-To: Vladik Kreinovich Subject: an article in Notices AMS To: reliable_computing [at] interval [dot] usl.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8P/PBdoV9caLwE1K5PnqPQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4 SunOS 5.7 sun4u sparc Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk Thomas C. Hales has published a popular article in April issue of Notices of the American Math. Society in which he describes, among other things, the main ideas of his proof of the double bubble problem. He talks a lot about how computers helped in his proof; he does not specifically mention interval computations, but his papers do explicitly metion his use of intervals. From owner-reliable_computing [at] interval [dot] usl.edu Wed Mar 29 17:54:25 2000 Received: (from root@localhost) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) id RAA09023 for reliable_computing-outgoing; Wed, 29 Mar 2000 17:54:25 -0600 (CST) Received: from wombat.cs.rmit.edu.au (wombat.cs.rmit.edu.au [131.170.24.41]) by interval.usl.edu (8.9.1/8.9.1/interval-math-majordomo-1.0) with ESMTP id RAA09018 for ; Wed, 29 Mar 2000 17:54:16 -0600 (CST) Received: from goanna.cs.rmit.edu.au (zahirt [at] goanna [dot] cs.rmit.edu.au [131.170.24.40]) by wombat.cs.rmit.edu.au (8.9.3/8.9.3/cshub) with ESMTP id JAA26201; Thu, 30 Mar 2000 09:54:07 +1000 (EST) Received: (from zahirt@localhost) by goanna.cs.rmit.edu.au (8.9.3/8.9.3/csnode) id JAA18435; Thu, 30 Mar 2000 09:54:04 +1000 (EST) Message-Id: <200003292354.JAA18435 [at] goanna [dot] cs.rmit.edu.au> Subject: CFP for Int. Symposium on Distributed Objects and Applications To: ICDCS_99 [at] us [dot] ibm.com, distributed-ai-request [at] mailbase [dot] ac.uk, podc-post [at] bellcore [dot] com, reliable_computing [at] interval [dot] usl.edu, distributed-ai-request [at] mailbase [dot] ac.uk Date: Thu, 30 Mar 2000 09:54:03 +1000 (EST) From: "Zahir Tari" Cc: zahirt [at] goanna [dot] cs.rmit.edu.au (Zahir Tari) X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-reliable_computing [at] interval [dot] usl.edu Precedence: bulk C A L L F O R P A P E R S ============================= ___ __ __ __ __ | | | | | | / | || | International Symposium on | | | | |--| | || | DISTRIBUTED OBJECTS AND APPLICATIONS _|_| |__| | | |__||__| Antwerp, Belgium, September 21-23, 2000 http://www.cs.rmit.edu.au/conf/doa/2000/ Are you building applications using distributed objects (DO)? Are you doing research in fundamental technology, methodology or new tools for DO? Are you using some of the existing distributed object systems? Consider contributing a practice report or a research paper to this innovative event, and to present, discuss and obtain feedback for your ideas among other practitioners and researchers active in the same area. During DOA'2000 Symposium we want attendees to be able to evaluate existing ORB middleware products; to analyze, and propose solutions to major limitations of existing products; and to indicate promising future research directions for distributed objects. We are particularly interested in the evaluation of existing distributed object systems and how they are used to design and to implement large scale industrial distributed applications. We are seeking theoretical as well as practical papers addressing innovative issues related to distributed objects. IMPORTANT DATES Electronic submission: May 1st, 2000 Notification of acceptance: June 10th, 2000 Camera-ready copies: June 30th, 2000 Symposium: September 21-23, 2000 TOPICS OF INTEREST o Distributed and mobile agents o Design patterns for distributed object design o Database services, in particular persistency, transaction, query and replication services o Integration of distributed object and Web technologies o Integration with database systems and interfaces o Methodologies to develop distributed object applications o Reintegration of legacy systems in DO environments o Design of CORBA, COM- and Java-based broker applications o Multimedia distributed objects o Multicast protocols for distributed objects o Object caching o Reliability, fault-tolerance and recovery o Real-time ORB middleware o Reports on Best Practice o Security o Specification and enforcement of quality of service o Standardization of distributed objects o ...