From ownerreliable_computing [at] interval [dot] usl.edu Wed Sep 1 15:13:09 1999
Received: (from daemon@localhost)
by interval.usl.edu (8.9.1/8.9.1/ucsmxhost_1.2) id PAA24838
for reliable_computingoutgoing; Wed, 1 Sep 1999 15:13:09 0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by interval.usl.edu (8.9.1/8.9.1/ucsmxhost_1.2) with ESMTP id PAA24833
for ; Wed, 1 Sep 1999 15:13:07 0500 (CDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA22266
for ; Wed, 1 Sep 1999 13:13:06 0700 (PDT)
Received: from hasims.eng.sun.com (physthestorka.Eng.Sun.COM [129.146.1.231])
by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA17621
for ; Wed, 1 Sep 1999 13:13:05 0700 (PDT)
Received: from gww (gww.Eng.Sun.COM [129.146.78.116])
by hasims.eng.sun.com (Sun Internet Mail Server sims.4.0.1999.06.13.00.20)
with SMTP id <0FHE00E60DHSHU@hasims.eng.sun.com> for
reliable_computing [at] interval [dot] usl.edu; Wed, 1 Sep 1999 13:13:05 0700 (PDT)
Date: Wed, 01 Sep 1999 13:13:05 0700 (PDT)
From: William Walster
Subject: Intervals mentioned in CNN.com story
To: reliable_computing [at] interval [dot] usl.edu
Replyto: William Walster
Messageid: <0FHE00E61DHSHU@hasims.eng.sun.com>
MIMEversion: 1.0
XMailer: dtmail 1.3.0 @(#)CDE Version 1.3.4 SunOS 5.7 sun4m sparc
Contenttype: TEXT/plain; charset=usascii
ContentMD5: boHYxPy1K9xNOh0D6+UweQ==
Sender: ownerreliable_computing [at] interval [dot] usl.edu
Precedence: bulk
See:
http://www.cnn.com/TECH/computing/9909/01/java.grande.idg/index.html
From ownerreliable_computing [at] interval [dot] usl.edu Fri Sep 3 02:28:17 1999
Received: (from daemon@localhost)
by interval.usl.edu (8.9.1/8.9.1/ucsmxhost_1.2) id CAA26295
for reliable_computingoutgoing; Fri, 3 Sep 1999 02:28:17 0500 (CDT)
Received: from mail.cs.uu.nl (vmailer [at] sunset [dot] cs.uu.nl [131.211.80.32])
by interval.usl.edu (8.9.1/8.9.1/ucsmxhost_1.2) with ESMTP id CAA26290
for ; Fri, 3 Sep 1999 02:28:06 0500 (CDT)
Received: from visby.cs.uu.nl (visby.cs.uu.nl [131.211.80.151])
by mail.cs.uu.nl (Postfix) with SMTP
id 150C34537; Fri, 3 Sep 1999 09:27:50 +0200 (MET DST)
MessageId:
XSender: johanj [at] pop [dot] cs.uu.nl
XMailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Thu, 02 Sep 1999 22:47:07 +0200
To: fsdm [at] it [dot] uq.edu.au, softverf [at] leopard [dot] cs.byu.edu,
formalmethods [at] cs [dot] uidaho.edu, types [at] cs [dot] indiana.edu,
logic [at] cs [dot] cornell.edu, logic [at] theory [dot] lcs.mit.edu, eatcsit [at] cs [dot] unibo.it,
mop [at] cs [dot] uu.nl, isabelleusers [at] cl [dot] cam.ac.uk, infohol [at] leopard [dot] cs.byu.edu,
theoremprovers [at] mc [dot] lcs.mit.edu, clics [at] doc [dot] ic.ac.uk, qed [at] mcs [dot] anl.gov,
ccl [at] dfki [dot] unisb.de, tapsoft [at] dcs [dot] ed.ac.uk, proglang [at] diku [dot] dk,
theorynt [at] listserv [dot] nodak.edu, flprog [at] informatik [dot] unimuenchen.de,
reliable_computing [at] interval [dot] usl.edu, uitp [at] dcs [dot] gla.ac.uk,
facs [at] lboro [dot] ac.uk, coqclub [at] pauillac [dot] inria.fr, siksleden [at] cs [dot] ruu.nl,
asci [at] twi [dot] tudelft.nl, ozsllist [at] fwi [dot] uva.nl, protagonist [at] cs [dot] kun.nl,
theorya [at] vm1 [dot] nodak.edu, calculemusig [at] dist [dot] unige.it,
logicml [at] logic [dot] jaist.ac.jp, theoremprovers [at] ai [dot] mit.edu, ftp [at] logic [dot] at,
omannounce [at] lars [dot] math.FSU.EDU, rewriting@enslyon.fr
From: Johan Jeuring
Subject: Workshop on Generic Programming 2000, call for papers
MimeVersion: 1.0
ContentType: text/plain; charset="usascii"
Sender: ownerreliable_computing [at] interval [dot] usl.edu
Precedence: bulk
Workshop on Generic Programming
http://www.cs.uu.nl/~johanj/wgp2000/wgp2000cfp.html
6th July 2000
Ponte de Lima, Portugal
Call for papers
Generic programming is about making programs more adaptable by making them
more general. Generic programs often embody nontraditional kinds of
polymorphism; ordinary programs are obtained from them by suitably
instantiating their parameters. In contrast with normal programs, the
parameters of a generic programs are often quite rich in structure. For
example they may be other programs, types or type constructors, kinds, or
even programming paradigms.
This workshop follows on the 5th Mathematics of Program Construction
conference.
This is the second workshop on generic programming, the first workshop on
generic programming (proceedings) was held on Marstrand, Sweden, in 1998.
Submission
Papers (preferably short, no more than 15 pages) should be submitted in
Postscript format by email to reach Johan Jeuring by March 20, 2000.
Accepted papers will be published in the proceedings of the workshop, which
will appear as a technical report at Utrecht University.
Submission deadline: 20 March
Notification: 30 April
Final version due: 20 May
Workshop: 6 July
Topics
Generic programming techniques have always been of interest, both to
practitioners and theoreticians, but have rarely been a specific focus of
research, until recently. In the last couple of years we have seen:
* several language extensions for generic programming
(PolyP,DrIFT,FML,AOOP,FiSH);
* lots of examples of generic programming (generalized tries,
unification, data compression, XML applications) ;
* programming calculi for generic programming.
We solicit papers on these topics. The list of topics is not exclusive:
papers on other topics related to generic programming are also welcome.
Programme Committee
Gianna Belle (Genova, Italy)
Patrik Jansson (Chalmers, Sweden)
Ralf Hinze (Bonn, Germany)
Graham Hutton (Nottingham, Great Britain)
Johan Jeuring (Utrecht, The Netherlands, chair)
Colin Runciman (York, Great Britain)
Fritz Ruehr (Willamette, USA)
Tim Sheard (OGI, USA)
Doaitse Swierstra (Utrecht, The Netherlands)
Address
Johan Jeuring
Department of Computer Science
Utrecht University
P.O.Box 80.089
NL3508 TB Utrecht
The Netherlands
email: johanj [at] cs [dot] uu.nl
url: http://www.cs.uu.nl/~johanj/
From ownerreliable_computing [at] interval [dot] usl.edu Sat Sep 4 04:38:40 1999
Received: by interval.usl.edu (8.9.1/8.9.1/ucsmxhost_1.2) id EAA00612
for reliable_computingoutgoing; Sat, 4 Sep 1999 04:38:40 0500 (CDT)
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/ucsmxhost_1.2) with ESMTP id EAA00607
for ; Sat, 4 Sep 1999 04:38:34 0500 (CDT)
Received: from iph.bio.bas.bg (IDENT:root@basbio.lines.bas.bg [195.96.252.58])
by argo.bas.bg (8.9.1/8.9.2) with ESMTP id MAA09894
for ; Sat, 4 Sep 1999 12:38:29 +0300
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 MAA02491
for ; Sat, 4 Sep 1999 12:37:40 +0300
MessageId: <199909040937.MAA02491 [at] iph [dot] bio.bas.bg>
Comments: Authenticated sender is
From: "Svetoslav Markov"
Organization: Institute of Mathematics, BAS
To: reliable_computing [at] interval [dot] usl.edu
Date: Sat, 4 Sep 1999 12:40:18 +0200
Subject: workshop in Sozopol, registr. deadline Sept 10, 1999
Replyto: smarkov [at] iph [dot] bio.bas.bg
Priority: normal
Xmailer: Pegasus Mail for Windows (v2.23)
Sender: ownerreliable_computing [at] interval [dot] usl.edu
Precedence: bulk
WORKSHOP
Reliable Computations and Interval Algebra
Sozopol (Black Sea, near Burgas)
2729.09.1999
Organized by:

Section "Biomathematics and Scientific Computations" of the
Union of Mathematicians in Bulgaria;
Institute of Mathematics and Informatics at Bulgarian Academy of
Sciences.
Objective:

Present/discuss current research and trends in the fields of
Reliable Computations and Interval Algebra.
A tentative list of topics includes but is not limited to:
 Numerical Methods for Result Verification;
 Interval Algebra and Analysis;
 Computer Algebra Methods;
 Reliability of Numerical Software;
 Applied Case Studies: biology, engineering etc.
There will be some "informal/interactive" discussions on:
 Reliability of numerical software;
 Interaction between computer algebra and interval methods;
 Theoretical aspects related to spaces for numerical computations;
 Reliable computations related to enzyme kinetic.
Initial List of Speakers:

Yilmaz Akyildiz (Bosphorous Univ., Turkey)
JeanLuc Lamotte (Univ. P. M. Currie, Paris IV, France)
Svetoslav Markov (Bulgarian Academy of Sciences)
Robert Mullen (Case Western Reserve Univ., Ohio, USA)
Evgenija Popova (Bulgarian Academy of Sciences)
Juergen Wolff von Gudenberg (Univ. of Wuerzburg, Germany)
Workshop Language: English

Publications:

Abstracts in a specialized journal.
Post conference publishing of full papers as Special Issue of International
Journal
Registration Fee:

50 USD includes: local arrangements, meeting at the airport Sofia or Burgas,
booklet of abstracts, snacks, social program.
Deadline for abstracts and electronic registration:
September 10, 1999.
More Information at:

http://www.math.bas.bg/~bio/RC&IA'99
email:epopova [at] argo [dot] bas.bg

 +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +
Svetoslav Markov
Section "Biomathematics", Inst. of phone: +35929793704, +3592707460,
Mathematics and Computer Sci., fax: +35929713649,
Bulgarian Academy of Sciences, email: smarkov [at] iph [dot] bio.bas.bg
"Acad. G. Bonchev" st., block 8,
BG1113 Sofia, BULGARIA
home address: 11 Mizia, 1124 Sofia, tel. +3592444651
 +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +
From ownerreliable_computing [at] interval [dot] usl.edu Tue Sep 7 20:34:33 1999
Received: by interval.usl.edu (8.9.1/8.9.1/ucsmxhost_1.2) id UAA00278
for reliable_computingoutgoing; Tue, 7 Sep 1999 20:34:33 0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by interval.usl.edu (8.9.1/8.9.1/ucsmxhost_1.2) with ESMTP id UAA00273
for ; Tue, 7 Sep 1999 20:34:30 0500 (CDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA14061
for ; Tue, 7 Sep 1999 18:34:26 0700 (PDT)
Received: from hasims.eng.sun.com (physthestorka.Eng.Sun.COM [129.146.1.231])
by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA05907
for ; Tue, 7 Sep 1999 18:34:25 0700 (PDT)
Received: from gww (gww.Eng.Sun.COM [129.146.78.116])
by hasims.eng.sun.com (Sun Internet Mail Server sims.4.0.1999.06.13.00.20)
with SMTP id <0FHP00LCTWDCOV@hasims.eng.sun.com> for
reliable_computing [at] interval [dot] usl.edu; Tue, 7 Sep 1999 18:34:25 0700 (PDT)
Date: Tue, 07 Sep 1999 18:33:46 0700 (PDT)
From: William Walster
Subject: Early Access for Sun f95 with Intervals
To: reliable_computing [at] interval [dot] usl.edu
Replyto: William Walster
Messageid: <0FHP00LCUWDCOV@hasims.eng.sun.com>
MIMEversion: 1.0
XMailer: dtmail 1.3.0 @(#)CDE Version 1.3.4 SunOS 5.7 sun4m sparc
Contenttype: TEXT/plain; charset=usascii
ContentMD5: vV3Jf/0b1RtVlZ+t1bzYAA==
Sender: ownerreliable_computing [at] interval [dot] usl.edu
Precedence: bulk
Dear members of the Interval Community:
We are approaching our early access period (beta testing) for Fortran 95
compiler with intervals. This will be the first commercially available
compiler from a major computer company that supports interval data types. We,
the members of the interval community, have an important role to play in
helping to make sure support for intervals is a commercial success for the
interval community and for Sun.
It will be extremely helpful if as much existing interval code as possible is
ported onto the f95 compiler. This should be a relatively easy and we hope,
pleasant task. Posting these codes and libraries to the Internet will
provide new users with existing routines to use and from which they can clone
their own extensions. If these codes, test cases, and documentation can be
posted to the Internet, we will be able to incorporate them into our
application test suites. If documentation is available only in published
books or manuscripts, pointers to them will be fine. This will be a good
opportunity for the excellent work done at Professor Kulisch's institute and
by many others to get wide exposure.
Individuals or groups interested in participating should send me email with a
point of contact and coordinates. I will pass them on to the people who are
running the EA program. Additional EA details will be made available as soon
as possible. Please use the subject of this email for ease of filtering.
Please let me know if you are any other suggestions that will help make this
interval product rollout successful, both for the interval community and for
Sun.
Thanks in advance for your help and support,
Bill
G. William (Bill) Walster, Ph.D.
Software Engineering Manager
Interval Technology and Russian Projects
Sun Microsystems, Inc.
901 San Antonio Road, MS UMPK16304
Palo Alto, CA 943034900
(650) 7869004 Direct
(650) 7869551 Fax
bill.walster [at] eng [dot] sun.com
P.S. We are working on a few demos for SC99 in Portland Oregon in
November. If you have or know of eyecatching ideas for demos,
please forward. Thanks.
 End Forwarded Message 
 End Forwarded Message 
From ownerreliable_computing [at] interval [dot] usl.edu Fri Sep 10 04:36:24 1999
Received: by interval.usl.edu (8.9.1/8.9.1/ucsmxhost_1.2) id EAA02614
for reliable_computingoutgoing; Fri, 10 Sep 1999 04:36:24 0500 (CDT)
Received: from nbsp.nsk.su (omega.nbsp.nsk.su [212.20.33.242])
by interval.usl.edu (8.9.1/8.9.1/ucsmxhost_1.2) with SMTP id EAA02609
for ; Fri, 10 Sep 1999 04:36:11 0500 (CDT)
Received: from nbsp.nsk.su (novo0) by nbsp.nsk.su (5.x/SMISVR4)
id AA08775; Fri, 10 Sep 1999 16:35:18 +0700
Received: from novo54.nbsp.nsk.su by nbsp.nsk.su (SMI8.6/SMISVR4)
id QAA26310; Fri, 10 Sep 1999 16:35:58 +0700
Received: by novo54.nbsp.nsk.su (SMI8.6/SMISVR4)
id QAA13870; Fri, 10 Sep 1999 16:34:19 +0700
Date: Fri, 10 Sep 1999 16:34:19 +0700
From: ml [at] nbsp [dot] nsk.su (Mikhail Yu. Loenko)
MessageId: <199909100934.QAA13870 [at] novo54 [dot] nbsp.nsk.su>
To: reliable_computing [at] interval [dot] usl.edu
Subject: elementary functions with directed roundings
XSunCharset: USASCII
Sender: ownerreliable_computing [at] interval [dot] usl.edu
Precedence: bulk
Hi,
I'm a Ph.D. student of the Novosibirsk State University. In my program I have
to evaluate interval elementary functions many times. So, I need to use efficient
and robust algorithms for such evaluations. Could you please give references to
papers or free source codes of algorithms for evaluation of elementary functions
with directed roundings. Any help will be appreciated.
Thanks,
Mikhail Loenko.
From ownerreliable_computing [at] interval [dot] usl.edu Wed Sep 15 09:41:30 1999
Received: by interval.usl.edu (8.9.1/8.9.1/ucsmxhost_1.2) id JAA02725
for reliable_computingoutgoing; Wed, 15 Sep 1999 09:41:30 0500 (CDT)
Received: from marnier.ucs.usl.edu (root@ucsgw.usl.edu [130.70.40.2])
by interval.usl.edu (8.9.1/8.9.1/ucsmxhost_1.2) with ESMTP id JAA02720
for ; Wed, 15 Sep 1999 09:41:27 0500 (CDT)
Received: from u8174 (rbk5287.usl.edu [130.70.64.43])
by marnier.ucs.usl.edu (8.9.1/8.9.1/ucsmxhost_1.3) with SMTP id JAA29820
for ; Wed, 15 Sep 1999 09:41:24 0500 (CDT)
MessageId: <2.2.32.19990915144152.006f4ec8 [at] pop [dot] usl.edu>
XSender: rbk5287 [at] pop [dot] usl.edu
XMailer: Windows Eudora Pro Version 2.2 (32)
MimeVersion: 1.0
ContentType: text/plain; charset="usascii"
Date: Wed, 15 Sep 1999 09:41:52 0500
To: reliable_computing [at] interval [dot] usl.edu
From: "R. Baker Kearfott"
Subject: New preprint: verification of singular solutions
Sender: ownerreliable_computing [at] interval [dot] usl.edu
Precedence: bulk
Colleagues,
The preprint "Existence Verification for Singular Zeros of Nonlinear Systems,"
jointly done by my student Jianwei Dian, me, and Arnold Neumaier, is
now available in Postscript and TeX DVI form. You can find in on
my preprints page at
http://interval.usl.edu/preprints.html
(It is near the bottom. I recommend the text search feature of your
browser for locating specific items on my preprint page.)
You can also find it in compressed form on Prof. Neumaier's page at
http://solon.cma.univie.ac.at/~neum/papers.html
(Arnold's page is organized in reverse chronological order, I
believe.)
Best regards,
Baker
P.S. Note the name change of my university in the signature. For those
of you around in 1983 the last time a name change was tried, I
assure you that this time it is official, blessed by the
politicians :)

R. Baker Kearfott, rbk [at] usl [dot] edu (318) 4825346 (fax)
(318) 4825270 (work) (318) 9819744 (home)
URL: http://interval.usl.edu/kearfott.html
Department of Mathematics, University of Louisiana at Lafayette
Box 41010, Lafayette, LA 705041010, USA

From ownerreliable_computing [at] interval [dot] usl.edu Thu Sep 16 07:14:39 1999
Received: (from daemon@localhost)
by interval.usl.edu (8.9.1/8.9.1/ucsmxhost_1.2) id HAA03800
for reliable_computingoutgoing; Thu, 16 Sep 1999 07:14:39 0500 (CDT)
Received: (from rbk5287@localhost)
by interval.usl.edu (8.9.1/8.9.1/ucsmxhost_1.2) id HAA03794
for reliable_computing; Thu, 16 Sep 1999 07:14:36 0500 (CDT)
Date: Thu, 16 Sep 1999 07:14:36 0500 (CDT)
From: "Kearfott R. Baker"
MessageId: <199909161214.HAA03794 [at] interval [dot] usl.edu>
To: reliable_computing [at] interval [dot] usl.edu
Subject: FMOODS 2000 Preliminary Call for Papers
Sender: ownerreliable_computing [at] interval [dot] usl.edu
Precedence: bulk
Date: Wed, 15 Sep 1999 12:53:25 0700 (PDT)
From: Carolyn Talcott
To:
Subject: FMOODS 2000 Preliminary Call for Papers
Replyto: clt [at] cs [dot] stanford.edu
Preliminary Call for Papers
Fourth IFIP International conference
on
Formal Methods for Open Objectbased Distributed Systems
FMOODS'2000
Stanford California, USA, 4th6th September, 2000

Objectives
Objectbased Distributed Computing is being established as the most
pertinent basis for the support of large, heterogeneous computing and
telecommunications systems. Indeed, several important international
organisations, such as ITU, ISO, OMG, TINAC, etc. are defining similar
distributed objectbased frameworks as a foundation for open distributed
computing.
The advent of Open Objectbased Distributed Systems  OODS  brings new
challenges and opportunities for the use and development of formal methods.
New architectures and system models are emerging (e.g., the enterprise,
information, computational and engineering viewpoints of the ITUT/ISO/IEC
ODP Reference Model) which require formal notational support. Usual design
issues such as specification, verification, refinement, and testing need to
take into account new dimensions introduced by distribution and openness,
such as quality of service and dependability constraints, dynamic binding
and reconfiguration, consistency between multiple models and viewpoints,
etc. OODS is a challenging research context and a source of motivation for
semantical models of objectbased systems and notations, for the evolution
of standardised formal description techniques, for the application and
assessment of logic based approaches, for better understanding and
information modeling of business requirements, and for the further
development and use of Object Oriented methodologies and tools.
The objective of FMOODS is to provide an integrated forum for the
presentation of research in several related fields, and the exchange of
ideas and experiences in the topics concerned with the formal methods
support for Open Objectbased Distributed Systems.
Topics
Topics of interest include but are not limited to:
* formal models for objectbased distributed computing
* semantics of objectbased distributed systems and programming languages
* formal techniques in objectbased and objectoriented specification,
analysis and design
* refinement and transformation of specifications
* types, service types and subtyping
* interoperability and composability of distributed services
* objectbased coordination languages
* objectbased mobile languages
* efficient analysis techniques of specifications
* multiple viewpoint modelling and consistency between different models
* formal techniques in distributed systems verification and testing
* specification, verification and testing of quality of service constraints
* formal methods and object life cycle
* beyond IDL: semantics based specification patterns
* formal models for measuring the quality of objectoriented
requirement or design specifications
* formal aspects of distributed realtime multimedia systems
* applications to telecommunications and related areas
Sponsors  IFIP
Conference Organizers
Carolyn Talcott, General Chair
Stanford University
clt [at] cs [dot] stanford.edu
Sriram Sankar
Metamata Inc.
sriram.sankar [at] metamata [dot] com
Scott Smith (Pc cochair)
Johns Hopkins University
scott [at] cs [dot] jhu.edu
Nalini Venkatasubramanian
University of California, Irvine
nalini [at] ics [dot] uci.edu
Evaluation and Publication of Submitted Papers
Submitted manuscripts will be evaluated and selected for presentation in the
conference. The proceedings of FMOODS 2000 will be published by Kluwer
who are the publishers of IFIP events. The proceedings will be made
available at the conference.
Instructions to the Authors
Authors are invited to submit full original research papers, up to 16 pages
(including bibliography), 12 point, single spaced, including an informative
abstract, names and affiliations of all authors, and a list of keywords
facilitating the assignment of papers to referees.
Important Dates
1st March 2000 Submission deadline
30th April 2000 Notification of acceptance
23rd May 2000 Camera ready copy for participants proceedings due
Submission Procedure Information: to appear
 End Included Message 
From ownerreliable_computing [at] interval [dot] usl.edu Thu Sep 16 12:57:41 1999
Received: (from daemon@localhost)
by interval.usl.edu (8.9.1/8.9.1/ucsmxhost_1.2) id MAA04346
for reliable_computingoutgoing; Thu, 16 Sep 1999 12:57:41 0500 (CDT)
Received: from tik2.ethz.ch (komtik2.ethz.ch [129.132.66.10])
by interval.usl.edu (8.9.1/8.9.1/ucsmxhost_1.2) with ESMTP id MAA04341
for ; Thu, 16 Sep 1999 12:57:38 0500 (CDT)
Received: from tec34.ethz.ch (tec34 [129.132.119.34])
by tik2.ethz.ch (8.8.8/8.8.8) with ESMTP id TAA27423
for ; Thu, 16 Sep 1999 19:57:35 +0200 (MET DST)
From: Application Asm
Received: (from asm@localhost)
by tec34.ethz.ch (8.8.8/8.8.8) id TAA01215
for reliable_computing [at] interval [dot] usl.edu; Thu, 16 Sep 1999 19:57:35 +0200 (MET DST)
Date: Thu, 16 Sep 1999 19:57:35 +0200 (MET DST)
MessageId: <199909161757.TAA01215 [at] tec34 [dot] ethz.ch>
To: reliable_computing [at] interval [dot] usl.edu
Subject: call for papers: ASM2000, March 19th  24th
XSunCharset: ISO88591
Sender: ownerreliable_computing [at] interval [dot] usl.edu
Precedence: bulk
> We apologize if you received multiple copies of this message. <
___________________________________________________________________________
___________ ____________
___________ ASM2000 ____________
___________ http://www.tik.ee.ethz.ch/~asm/2000 ____________
___________ Monte Verita, Switzerland March 19th  24th 2000 ____________
___________________________________________________________________________
In March 2000, an Abstract State Machine (ASM) Workshop (a follow up of
earlier workshops, see http://www.tik.ee.ethz.ch/asm/workshops) will be
held in the conference center of the Swiss Federal Institute of Technology
at Monte Verita, Ticino, Switzerland, see http://www.csfmv.ethz.ch .
The ASM formalism was proposed together with the thesis that it is suitable
to model arbitrary algorithms on arbitrary abstraction levels. ASMs have
been used to analyze and specify various hardware and softwaresystems as
well as computer languages, see http://www.eecs.umich.edu/gasm .
The aim of the workshop is to bring together domainexperts using ASMs as
practical specification formalisms, and theoreticians using ASMs as formal
starting point for their investigations. In addition the workshop is a
forum on theoretical and practical topics that relate to ASMs in a broad
sense.
The technical program will consist of invited lectures, tutorials, presenta
tions of refereed papers, and software demonstrations. A significant part
of the time will be devoted to discussions.
Invited talks will be given by
Andreas Blass (Univ. of Michigan),
Egon Börger (Univ. of Pisa),
Gerhard Goos (Univ. of Karlsruhe),
Martin Odersky (EPFL Lausanne),
Wolfgang Reisig (Humbold Univ. Berlin), and
Natarajan Shankar (SRI International).
Both extended abstracts of work in progress and full papers are welcome.
Submissions of either kind must be unpublished and not submitted for
publication elsewhere. We intend to publish the accepted submissions
in the LNCS series. The use of the LNCS style files (available at
http://www.springer.de/comp/lncs/authors.html) is strongly recommended.
Submissions should be sent by November 20th, 1999 via email (postscript or
pdf) to the address asm [at] tik [dot] ee.ethz.ch
The workshop is sponsored by the Swiss Federal Institute of Technology,
Microsoft Research, and BlueCapital.
Yuri Gurevich, Microsoft Research, Redmond, Washington, USA
Philipp W. Kutter, Federal Institute of Technology, Zürich, Switzerland
Martin Odersky, Federal Institute of Technology, Lausanne, Switzerland
Lothar Thiele, Federal Institute of Technology, Zürich, Switzerland
___________________________________________________________________________
_________________________ ____________________________
_________________________ Important Dates ____________________________
___________________________________________________________________________
Submission of contributions : November 20th, 99
Notification of acceptance : January 10th, 00
Registration deadline : March 1st, 00
Submissions of final versions : March 1st, 00
Workshop : March 19th  March 24th, 00
ASM2000 is just before ETAPS'2000 (Berlin, March 25April 2,2000)
so that attendance to both events can be suitably combined.
__________________________________________________________________________
__________________________________________________________________________
___________________________________________________________________________
_________________________ ___________________________
_________________________ Program Committee ___________________________
___________________________________________________________________________
Andreas Blass (U. Michigan, USA)
Egon Börger (U. Pisa, I)
Uwe Glässer (HNI Paderborn, D)
Carla P. Gomes (Cornel U./Rome Labs, USA)
Georg Gottlob (TU Wien, A)
Erich Grädel (U. Aachen, D)
Irene Guessarian (LIAFA/U. Paris 6, F)
Yuri Gurevich (cochair, Microsoft Research, USA)
Jim Huggins (Kettering U., USA)
Stefan Jähnichen (GMD FIRST Berlin, D)
Hans Langmaack (U. Kiehl, D.)
Larry Moss (Indiana U., USA)
Peter Mosses (BRIKS, DK)
Martin Odersky (cochair, EPFL Lausanne, CH)
Alfonso Pierantonio (U. L'Aquila, I)
Arnd PoetzschHeffter (FernUni Hagen, D)
Dean Rosenzweig (U. of Zagreb, HR)
Elvinia Riccobene (U. Catania, I)
Harald Ruess (SRI International, USA)
Daniel Schweizer (UBS Zuerich, CH)
Anatol Slissenko (U. Paris 12, F)
Lothar Thiele (cochair, ETH Zuerich, CH)
Richard Waldinger (SRI International, USA),
Sasha Zamulin (Russian Akad. Science, RU)
Wolf Zimmermann (U. Karlsruhe, D)
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
_________________________ ___________________________
_________________________ Tutorials ___________________________
__________________________________________________________________________
Tutorials include tooldemonstrations and handson experience with the
used tools. Infrastructure includes 12 SUNworkstations.
Uwe Glaesser, Giuseppe del Castillo
"Specifying Concurrent Systems with ASMs"
The ASMworkbench is introduced and used for experiments with
concurrent systems.
Harald Ruess, ... , Natarajan Shankar
"Verifying ASMs with PVS"
The basic features of the PVS proof development system are
introduced and demonstrated.
Matthias Anlauff, Philipp Kutter, Alfonso Pierantonio
"Developing Domain Specific Languages"
The GemMex system is used to prototype and visualize small
domain specific languages with ASM semantics.
Further tool demos and experiments can be done during the workshop.
__________________________________________________________________________
__________________________________________________________________________
From ownerreliable_computing [at] interval [dot] usl.edu Tue Sep 21 04:18:33 1999
Received: (from daemon@localhost)
by interval.usl.edu (8.9.1/8.9.1/ucsmxhost_1.2) id EAA08400
for reliable_computingoutgoing; Tue, 21 Sep 1999 04:18:33 0500 (CDT)
Received: from nbsp.nsk.su (omega.nbsp.nsk.su [212.20.33.242])
by interval.usl.edu (8.9.1/8.9.1/ucsmxhost_1.2) with SMTP id EAA08395
for ; Tue, 21 Sep 1999 04:18:24 0500 (CDT)
Received: from nbsp.nsk.su (novo0) by nbsp.nsk.su (5.x/SMISVR4)
id AA01803; Tue, 21 Sep 1999 16:16:44 +0700
Received: from novo54.nbsp.nsk.su by nbsp.nsk.su (SMI8.6/SMISVR4)
id QAA28239; Tue, 21 Sep 1999 16:17:34 +0700
Received: by novo54.nbsp.nsk.su (SMI8.6/SMISVR4)
id QAA00606; Tue, 21 Sep 1999 16:15:46 +0700
Date: Tue, 21 Sep 1999 16:15:46 +0700
From: ml [at] nbsp [dot] nsk.su (Mikhail Yu. Loenko)
MessageId: <199909210915.QAA00606 [at] novo54 [dot] nbsp.nsk.su>
To: reliable_computing [at] interval [dot] usl.edu
Subject: Re: elementary functions with directed roundings
XSunCharset: USASCII
Sender: ownerreliable_computing [at] interval [dot] usl.edu
Precedence: bulk
Thank you very much.
 Hi,

 I'm a Ph.D. student of the Novosibirsk State University. In my program I have
 to evaluate interval elementary functions many times. So, I need to use efficient
 and robust algorithms for such evaluations. Could you please give references to
 papers or free source codes of algorithms for evaluation of elementary functions
 with directed roundings. Any help will be appreciated.

 Thanks,
 Mikhail Loenko.

>From bill.walster [at] eng [dot] sun.com Fri Sep 10 21:48 NSK 1999
ReturnPath:
Date: Fri, 10 Sep 1999 07:47:48 0700 (PDT)
From: William Walster
Subject: f95 early access
To: ml [at] nbsp [dot] nsk.su
Cc: bill.walster [at] eng [dot] sun.com
Mikhail,
Are you interested in getting early access to our f95 compiler with
interval support?
If so, please send your coordinates and I will add you to the list.
Thanks,
Bill
>From bizzarri [at] dibe [dot] unige.it Mon Sep 13 13:55 NSK 1999
ReturnPath:
Date: Mon, 13 Sep 1999 08:58:40 +0200
From: Federico Bizzarri
XAcceptLanguage: en
To: "Mikhail Yu. Loenko"
Subject: Re: elementary functions with directed roundings
"Mikhail Yu. Loenko" wrote:
> Hi,
>
> I'm a Ph.D. student of the Novosibirsk State University. In my program I have
> to evaluate interval elementary functions many times. So, I need to use efficient
> and robust algorithms for such evaluations. Could you please give references to
> papers or free source codes of algorithms for evaluation of elementary functions
> with directed roundings. Any help will be appreciated.
>
> Thanks,
> Mikhail Loenko.
I worked successfully with the two C++ libraries (PROFIL and BIAS) that you can find
reading the "intervallers home page":
http://cs.utep.edu/intervalcomp/
At that location you can find a lot of software to evaluate interval functions with
direct roundings.
Good luck,
Federico

Dr. Federico Bizzarri, Ph.D. student
Biophysical and Electronic Engineering Department
University of Genoa
Via Opera Pia 11a Work: +390103532276
Genova, Italy, I16145 Fax: +390103532290
>From rump@tuharburg.de Mon Sep 13 16:47 NSK 1999
ReturnPath:
From: "Siegfried M. Rump"
To: "'Mikhail Yu. Loenko'"
Subject: AW: elementary functions with directed roundings
Date: Mon, 13 Sep 1999 11:40:30 +200
We have verified interval standard functions within INTLAB,
an interval toolbox under Matlab V5+. You find free source
code for nonprofit use on our home page http://www.ti3.tuharburg.de/
best regards, S.M. Rump

Von: Mikhail Yu. Loenko[SMTP:ml [at] nbsp [dot] nsk.su]
Gesendet: Freitag, 10. September 1999 11:34
An: reliable_computing [at] interval [dot] usl.edu
Betreff: elementary functions with directed roundings
Hi,
I'm a Ph.D. student of the Novosibirsk State University. In my program I have
to evaluate interval elementary functions many times. So, I need to use efficient
and robust algorithms for such evaluations. Could you please give references to
papers or free source codes of algorithms for evaluation of elementary functions
with directed roundings. Any help will be appreciated.
Thanks,
Mikhail Loenko.
>From JeanMichel.Muller@enslyon.fr Mon Sep 13 21:34 NSK 1999
ReturnPath:
Date: Mon, 13 Sep 1999 16:44:01 +0200
From: JeanMichel Muller
XAcceptLanguage: en
To: "Mikhail Yu. Loenko"
Subject: Re: elementary functions with directed roundings
Hello,
You might have a look on a recent paper I have coauthored, that you can
download on the web:
http://www.enslyon.fr/~jmmuller/Nov98.pdf
There is also some information o n my home page:
http://www.enslyon.fr/~jmmuller/
Regards
JeanMichel Muller
"Mikhail Yu. Loenko" wrote:
>
> Hi,
>
> I'm a Ph.D. student of the Novosibirsk State University. In my program I have
> to evaluate interval elementary functions many times. So, I need to use efficient
> and robust algorithms for such evaluations. Could you please give references to
> papers or free source codes of algorithms for evaluation of elementary functions
> with directed roundings. Any help will be appreciated.
>
> Thanks,
> Mikhail Loenko.

JeanMichel Muller, CNRSLIP, projet CNRS/INRIA/ENSL ARENAIRE
Ecole Normale Sup. de Lyon, 46 Allee d'Italie, 69364 Lyon Cedex 07
FRANCE
Tel. (+33) 4 72728229 Secr. (+33) 4 72728037 Fax. (+33) 4 72728080
Email: JeanMichel.Muller@enslyon.fr, j.muller [at] computer [dot] org
http://www.enslyon.fr/~jmmuller
>From hormigo [at] ac [dot] uma.es Tue Sep 14 17:38 NSK 1999
ReturnPath:
Date: Tue, 14 Sep 1999 11:33:04 +0000
From: "Fco. Javier Hormigo Aguilar"
To: "Mikhail Yu. Loenko"
Subject: Re: elementary functions with directed roundings
Hi,
I send to you some references about interval elementary functions. I 'm
sorry because I don't have software about it but I think you can find it
in the Interval Computation page:
http://cs.utep.edu/intervalcomp/main.html
I'm working in specific hardware to compute interval elementary
functions. I will really apreciate if you can tell me what elementary
functions do you need to compute and waht kind of problems you try to
solve, since I'm looking for aplications for my work. I'll send to you
also some references of my papers.
Thanks,
Javier Hormigo
@article{Braune88,
AUTHOR = "K. Braune",
TITLE = "Standard Functions for Real and Complex Point and Interval
Arguments with Dynamic Accuracy",
JOURNAL = "Computing, Suppl.",
YEAR = "1988",
PAGES = "159184",
VOLUME = "",
NUMBER = "6" ,
MONTH = ""}
@article{Kearfott,
AUTHOR = "B. Kearfott and M. Dawande and K. Du and C. Hu",
TITLE = "A Portable {FORTRAN} 77 Elementary Function Library",
JOURNAL = "Interval Computations",
YEAR = "1992",
PAGES = "96105",
VOLUME = "3",
NUMBER = "" ,
MONTH = ""}
@article{Priest97,
AUTHOR = "Douglas M. Priest",
TITLE = "Fast TableDriven Algorithms for Interval Elementary
Functions",
JOURNAL = "Proc. 13th Symposium on Computer Arithmetic",
YEAR = "1997",
PAGES = "168174",
VOLUME = "",
NUMBER = "" ,
MONTH = ""}
my papers
@article{arith14,
AUTHOR = "Javier Hormigo and Julio Villalba and Emilo L. Zapata",
TITLE = "Interval sine and Cosine Functions Computation Based on
VariablePrecision {CORDIC} Algorithm ",
JOURNAL = "Proc. 14th {IEEE} Symposium on Computer
Arithmetic(ARITH14)",
YEAR = "1999",
PAGES = "186193",
VOLUME = "",
NUMBER = "" ,
MONTH = "April"}
@article{euromicro99 ,
AUTHOR = "Javier Hormigo, Julio Villalba, and Emilio L. Zapata",
TITLE = "Arithmetic Unit for the Computation of Interval Elementary
Functions",
JOURNAL = "25th EUROMICRO CONFERENCE WORKSHOP on DIGITAL SYSTEM DESIGN
",
YEAR = "Milan, Italy,1999",
PAGES = "",
VOLUME = "",
NUMBER = "" ,
MONTH = "September 8  10"}
From ownerreliable_computing [at] interval [dot] usl.edu Tue Sep 21 09:10:31 1999
Received: (from daemon@localhost)
by interval.usl.edu (8.9.1/8.9.1/ucsmxhost_1.2) id JAA08980
for reliable_computingoutgoing; Tue, 21 Sep 1999 09:10:31 0500 (CDT)
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/ucsmxhost_1.2) with ESMTP id JAA08975
for ; Tue, 21 Sep 1999 09:10:28 0500 (CDT)
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 QAA02312
for ; Tue, 21 Sep 1999 16:10:17 +0200 (METDST)
XNUPopCharset: IBM 8Bit
Date: Tue, 21 Sep 99 16:07:31 CET
From: "Jiri Rohn"
ReplyTo: rohn [at] uivt [dot] cas.cz
MessageId: <58056.rohn [at] uivt [dot] cas.cz>
To: reliable_computing [at] interval [dot] usl.edu
Subject: SV issue: last call
Sender: ownerreliable_computing [at] interval [dot] usl.edu
Precedence: bulk
Dear colleagues,
We wish to remind you that the deadline for submitting papers for the
special Linear Algebra and Its Applications issue on selfvalidating methods
is SEPTEMBER 30, 1999.
You may submit three hard copies (no submission through email) to anyone
of the special guest editors listed below.
Yours
Jiri Rohn
Faculty of Mathematics and Physics
Charles University
Malostranske nam. 25
118 00 Prague
Czech Republic
email: rohn [at] uivt [dot] cas.cz
Siegfried M. Rump
Inst. f. Computer Science III
Technical University HamburgHarburg
Schwarzenbergstrasse 95
21071 Hamburg
Germany
email: rump@tuharburg.de
Tetsuro Yamamoto
Department of Mathematics
Faculty of Science
Ehime University
Matsuyama 790
Japan
email: yamamoto [at] dpc [dot] ehimeu.ac.jp
From ownerreliable_computing [at] interval [dot] usl.edu Wed Sep 22 21:16:19 1999
Received: by interval.usl.edu (8.9.1/8.9.1/ucsmxhost_1.2) id VAA10657
for reliable_computingoutgoing; Wed, 22 Sep 1999 21:16:19 0500 (CDT)
Received: from marnier.ucs.usl.edu (root@ucsgw.usl.edu [130.70.40.2])
by interval.usl.edu (8.9.1/8.9.1/ucsmxhost_1.2) with ESMTP id VAA10652
for ; Wed, 22 Sep 1999 21:16:15 0500 (CDT)
Received: from u8174 (goedel.usl.edu [130.70.49.203])
by marnier.ucs.usl.edu (8.9.1/8.9.1/ucsmxhost_1.3) with SMTP id VAA24194;
Wed, 22 Sep 1999 21:16:13 0500 (CDT)
MessageId: <2.2.32.19990923021644.006da7f0 [at] pop [dot] usl.edu>
XSender: rbk5287 [at] pop [dot] usl.edu
XMailer: Windows Eudora Pro Version 2.2 (32)
MimeVersion: 1.0
ContentType: text/plain; charset="usascii"
Date: Wed, 22 Sep 1999 21:16:44 0500
To: reliable_computing [at] interval [dot] usl.edu
From: "R. Baker Kearfott"
Subject: List to be down next week
Cc: jpd [at] usl [dot] edu
Sender: ownerreliable_computing [at] interval [dot] usl.edu
Precedence: bulk
Colleagues,
This mailing list will not be available Tuesday and Wednesday of
next week (September 28 and September 29).
The world wide web site (with GlobSol, my preprints, etc.) and the
interval FTP site will also be affected.
Messages sent during this time or undelivered before this time
should not be lost, but there are no guarantees.
James Dugal, the system administrator for interval.usl.edu,
will be replacing the disk drives on interval.usl.edu with
highercapacity ones and loading a Y2Kcompliant version of
Solaris. Work will start some time after 9:00 AM Central
Daylight Time (14:00 GMT), and may or may not take all of both
days.
Best regards,
Baker

R. Baker Kearfott, rbk [at] usl [dot] edu (318) 4825346 (fax)
(318) 4825270 (work) (318) 9819744 (home)
URL: http://interval.usl.edu/kearfott.html
Department of Mathematics, University of Louisiana at Lafayette
Box 41010, Lafayette, LA 705041010, USA

From ownerreliable_computing [at] interval [dot] usl.edu Fri Sep 24 16:35:47 1999
Received: (from daemon@localhost)
by interval.usl.edu (8.9.1/8.9.1/ucsmxhost_1.2) id QAA12478
for reliable_computingoutgoing; Fri, 24 Sep 1999 16:35:47 0500 (CDT)
Received: from mscs.mu.edu (studsys.mscs.mu.edu [134.48.4.15])
by interval.usl.edu (8.9.1/8.9.1/ucsmxhost_1.2) with SMTP id QAA12473
for ; Fri, 24 Sep 1999 16:35:43 0500 (CDT)
MessageId: <199909242135.QAA12473 [at] interval [dot] usl.edu>
Received: (qmail 11519 invoked from network); 24 Sep 1999 21:35:34 0000
Received: from boris.mscs.mu.edu (HELO boris) (134.48.4.4)
by studsys.mscs.mu.edu with SMTP; 24 Sep 1999 21:35:34 0000
Date: Fri, 24 Sep 1999 16:35:34 0500 (CDT)
From: "Dr. George F. Corliss MU MSCS"
ReplyTo: "Dr. George F. Corliss MU MSCS"
Subject: Re: Accreditation of Codes
To: ivandv [at] mailhost [dot] cs.clemson.edu
Cc: steve [at] cs [dot] clemson.edu, georgec [at] mscs [dot] mu.edu,
reliable_computing [at] interval [dot] usl.edu
MIMEVersion: 1.0
ContentType: TEXT/plain; charset=ISO88591
ContentMD5: VWzV7F9TTIuZqkJPsL1uHg==
XMailer: dtmail 1.3.0 @(#)CDE Version 1.3.4 SunOS 5.7 sun4u sparc
ContentTransferEncoding: 8bit
XMIMEAutoconverted: from QUOTEDPRINTABLE to 8bit by interval.usl.edu id QAA12474
Sender: ownerreliable_computing [at] interval [dot] usl.edu
Precedence: bulk
Steve,
I've been a lurker in this group for a couple years. This
thread brings me out.
> I have been trying to tack down this term "accreditation" without much
> success. So I've decided to try something concrete. I've decided to
> ask what it would take to certify that a root finder was, well, worthy
> of a certificate.
One promising tool for numerical problems such as rootfinding
is interval arithmetic for "selfvalidating" algorithms. (The
interval community's use of "validation" is related, but different
from that of this community.)
We wish to distinguish between asserting that
1. the program does what it is supposed to do, and
2. the problem (e.g. rootfinding) does what IT is supposed to do.
#1 is the expertise of this group.
#2 must rely on mathematical theory
What we have some hope of "accreditation" is an assertion
that our rootfinding program will either
1. Return an interval enclosing a root (or a set of intervals
enclosing all roots),
2. Return the assertion that the function has no root in
a specified interval, or
3. Is unable to do either 1. or 2., perhaps with partial
results.
We would "certify" that the program never lies. That should be
a feasible task for an interval rootfinding program. Yes, I can
write a correct, but useless, program always returning #3.
Codes can compete based on their domain of applicability.
Interval arithmetic on a computer uses IEEE directed rounding
to compute an interval guaranteed (subject to #1) to enclose
all rounding errors in arithmetic. Algorithms are used that
also enclose all truncation errors.
Theorem. If
1. f is continuous on an interval [a, b]
2. f(a) and f(b) have strictly opposite signs
then there is a root c in a < c < b.
In addition, if f' exists and is of one sign,
then the root c is unique.
Assuming our program works correctly (#1), we can check the
continuity of f, knowing it is a composition of continuous
functions, with the possible exception of a few cases we can
check such as /0, sqrt (), asin(>1), IF, etc.
We can evaluate f(a) and f(b) in interval arithmetic, using
directed rounding so we get intervals [f(a)] and [f(b)]
guaranteed to enclose the true values. [f(a)] and [f(b)]
may be wider than necessary, and various programming tricks
can attempt tighter enclosures, but the guaranteed enclosure
must hold. If both [f(a)] and [f(b)] are disjoint from zero,
we have _proven_ the existence of a root. If zero belongs to
either [f(a)] or [f(b)], we can
1. Give up and return "I don't know"
2. Try again with a multiple precision interval arithmetic
3. Try the rootfinding validation on a wider interval.
Once we have proven the existence of a root, we usually
compute a tighter enclosure by some fixed point iteration,
e.g. interval Newton. We appeal to a fixed point theorem,
e.g. Banach, and show we have a contractive map. In practical
codes, the proof of existence and the tightening are combined.
Similar interval algoriths are used for linear and
nonlinear systems, optimization, differential equations, etc.
This is a nonrigorous summary of an active area of research.
My point to this community is that by adding enclosures of
rounding and truncation errors, we have a powerful tool for
verifying rigorously on a computer that a numerical problem
satisfies the hypotheses of an appropriate mathematical
theorem. It would seem to present enormous potential for
collaborative research between the interval and the v&v
communities.
References:
R. E. Moore, Interval Analysis, Prentice Hall, Englewood
Cliffs, N.J., 1966.
R. E. Moore, Methods and Applications of Interval Analysis,
SIAM, Philadelphia, Penn., 1979.
G. Alefeld and J. Herzberger, Einführung in die Intervallrechnung,
SpringerVerlag, Heidelberg, 1974. Introduction to Interval
Computations, Academic Press, New York, 1983.
A. Neumaier, Interval Methods for Systems of Equations, Cambridge
University Press, Cambridge, 1990.
E. R. Hansen, Global Optimization Using Interval Analysis, Marcel
Dekker, New York, 1992.
Interval computations listserv:
reliable_computing [at] interval [dot] usl.edu
Interval computations web site:
http://cs.utep.edu/intervalcomp/main.html
George F. Corliss
Dept. Math, Stat, Comp Sci
Marquette University
P.O. Box 1881
Milwaukee, WI 532011881 USA
georgec [at] mscs [dot] mu.edu; George.Corliss [at] Marquette [dot] edu
http://www.mscs.mu.edu/~georgec/
Office: 4142886599; Dept: 2887375; Fax: 2885472
>
> About the only thing I can think of is to have some really nasty test
> functions and then say something was "certified" if it could find some
> percentage of the the roots at some given level of accuracy.
>
> Is this just testing? would I have to have community agreement that
> these functions were worse than any likely to be met in practice?
> should I institute a search for more uglies or just be ready to update
> the test programs?
>
> steve
>
> Appendix:
> As a serious test case, consider this polynomial sent to me from a
> numerical analysis news group:
>
> All roots in [3, 3]. In Fortran:
>
> x**70+10*x**6953*x**68840*x**67+556*x**66+33094*x**65+34984*x**64810448*
> x**631710413*x**62+13762598*x**61+41118204*x**60170674342*x**59669408301*
> x**58+1575702246*x**57+8139304421*x**5610665563706*x**5577502451611*x**54+
> 48034398976*x**53+594109876080*x**5271251547216*x**513731024648889*x**50
> 1001178053674*x**49+19413444795813*x**48+11446048979968*x**4784277052106156*
> x**4673543361870794*x**45+306297652383302*x**44+349025891130844*x**43
> 932078784132483*x**421315351237260886*x**41+2366040737135922*x**40+
> 4054845874713330*x**394964744498283827*x**3810369987468767286*x**37+
> 8453136340643513*x**36+22145393335883690*x**3511223789393426556*x**34
> 39564934181149558*x**33+10446958631762445*x**32+59043676220027924*x**31
> 3854845422485012*x**3073250566923653846*x**297616116768206834*x**28+
> 74930173627345276*x**27+19101242458794555*x**2662402855648467230*x**25
> 24841364734316544*x**24+41498191901443534*x**23+22686040707821384*x**22
> 21354816776113940*x**2115461896367433292*x**20+8022431870339006*x**19+
> 7937894514378461*x**181902246979654422*x**173024034551607022*x**16+
> 111526490121324*x**15+823748712357945*x**14+103340846739642*x**13
> 149083766521312*x**1241589180373690*x**11+15031165664405*x**10+7511739940974*
> x**9281713434883*x**8656009832886*x**790445245735*x**6+16964659584*x**5+
> 6022975080*x**4+598960824*x**3+16371852*x**2388080*x
>
> Probably can't be done without multiprecision.
From ownerreliable_computing [at] interval [dot] usl.edu Wed Sep 29 18:47:19 1999
Received: (from root@localhost)
by interval.usl.edu (8.9.1/8.9.1/intervalmathmajordomo1.0) id SAA00873
for reliable_computingoutgoing; Wed, 29 Sep 1999 18:47:19 0500 (CDT)
Received: from mscs.mu.edu (studsys.mscs.mu.edu [134.48.4.15])
by interval.usl.edu (8.9.1/8.9.1/intervalmathmajordomo1.0) with SMTP id SAA00868
for ; Wed, 29 Sep 1999 18:47:15 0500 (CDT)
MessageId: <199909292347.SAA00868 [at] interval [dot] usl.edu>
Received: (qmail 28243 invoked from network); 29 Sep 1999 16:40:33 0000
Received: from boris.mscs.mu.edu (HELO boris) (134.48.4.4)
by studsys.mscs.mu.edu with SMTP; 29 Sep 1999 16:40:33 0000
Date: Wed, 29 Sep 1999 11:40:33 0500 (CDT)
From: "Dr. George F. Corliss MU MSCS"
ReplyTo: "Dr. George F. Corliss MU MSCS"
Subject: Re: Accreditation of Codes
To: steve [at] cs [dot] clemson.edu
Cc: georgec [at] mscs [dot] mu.edu, rbk [at] usl [dot] edu, ivandv [at] mailhost [dot] cs.clemson.edu,
reliable_computing [at] interval [dot] usl.edu
MIMEVersion: 1.0
ContentType: TEXT/plain; charset=usascii
ContentMD5: O4XmmfLFTFoeCdhAkaYF6Q==
XMailer: dtmail 1.3.0 @(#)CDE Version 1.3.4 SunOS 5.7 sun4u sparc
Sender: ownerreliable_computing [at] interval [dot] usl.edu
Precedence: bulk
Steve,
> Just by breezing through your note, it appears you use "validation" as
> we use verification. A much different problem. Please elucidate.
The interval community is not as careful about its use of
those words as you are. Our loss. We tend to use "validation"
and "verification" interchangably. In the early 80's, I wrote
software we called SVALAQ  SelfValidating Adaptive Quadrature.
What we thought we meant was that, assuming IEEE arithmetic
works as specified (I see I'd better read your paper on that),
and assuming there are no logic errors in our program (which is
what I understand the domain of "validation" in your community),
we either
1. Returned in interval [c, d] in which a definite integral lies, or
2. "We cannot do #1"
We interval folks believe we are talking about real machines,
assuming IEEE arithmetic works. We may at times be less than
rigorous in considering underflow, overflow, NaNs, and the like.
Again, it sounds like I should read your paper and have my
world shaken :)
> I think this is close, but again does not talk about real
> computing. Here's a simple example: suppose the physicist lies down
> the following formula, f = sin((n\pi+s)x)+a  ((xb)+c), and then she
> declares that the "science" is in the root, and the observations for x
> with a given set of n,s,a,b,c is \mu\pm\sigma. You now turn loose your
> favorite algorithm and get m and m isn't close to \mu. Now what?
Interval arithmetic is worst case. We make no assertions about
one value in our result interval being more accurate or likely
than any other. If the result interval [mu_low, mu_high] encloses
numbers for which the universe is both expanding and numbers for
which it is contracting, our conclusion is that we do not know
the answer, but at least we KNOW that we don't know.
> > We would "certify" that the program never lies. That should be
> > a feasible task for an interval rootfinding program. Yes, I can
> > write a correct, but useless, program always returning #3.
> > Codes can compete based on their domain of applicability.
>
> Well, for one thing, the problem I gave you is horridly conditioned
> around a small root. Now, you physicist doesn't know this and then
> solves it using whatever. And misses completely. Now what.
For a sufficiently ill conditioned problem, either my interval
algorithm will break down, and I'll admit defeat, or else I will
return a wide interval. The wide interval encloses answers I might
have gotten with floating point arithmetic, and its width is a
warning that I do not know the answer with any accuracy.
> Ah, there's the 'correct word': you verify. The problem is that
> verification may not carry over to the machine. See my discussion in
> May/June "Computing in Science and Engineering."
The mathematical theorem "proves", "asserts", "guarantees",
or whatever other word mathematicians use. Our interval
algorithms verify the hypotheses of the theorem. Subject to
not yet having read your paper, we think that our arithmetic
on real machines correctly takes rounding and truncation into
account, so we think we are verifying those hypotheses on
real machines.
Fundamentally, where I think our two communities can add value
is in the program validation (in what I think is our sense of
the word) of the programs we write to verify theorems on
practical problems. We enclose the answers, and you assert
that we do what we claim. I gather from your comments that
we both have ample room for further advances.
>
> Glad to have you monitoring us. I hope you'll continue to contribute
> to this discussion. The basic problem, as I see it, is that as
> numerical analysts we understand the perfect world. But as Fetzer pointed
> out in his famous "Program Verification: the very idea" there is a
> point (I call it the Fetzer point) at which proof is meaningless
> because the machine isn't bound by it.
Kulisch has been campaigning for 2530 years for computer
arithmetic implementations that rigorously obey a set of axioms.
However, even he did not pay close attention to underflow,
overflow, NaN, and similar exceptional conditions. That is
where there appears fruitful ground for cooperation.
George F. Corliss
Dept. Math, Stat, Comp Sci
Marquette University
P.O. Box 1881
Milwaukee, WI 532011881 USA
georgec [at] mscs [dot] mu.edu; George.Corliss [at] Marquette [dot] edu
http://www.mscs.mu.edu/~georgec/
Office: 4142886599; Dept: 2887375; Fax: 2885472
From ownerreliable_computing [at] interval [dot] usl.edu Thu Sep 30 06:59:16 1999
Received: (from root@localhost)
by interval.usl.edu (8.9.1/8.9.1/intervalmathmajordomo1.0) id GAA05195
for reliable_computingoutgoing; Thu, 30 Sep 1999 06:59:16 0500 (CDT)
Received: from d22.ucs.usl.edu (root [at] d22 [dot] ucs.usl.edu [130.70.113.22])
by interval.usl.edu (8.9.1/8.9.1/intervalmathmajordomo1.0) with ESMTP id GAA05190
for ; Thu, 30 Sep 1999 06:59:13 0500 (CDT)
Received: from d22.ucs.usl.edu (rbk5287 [at] d22 [dot] ucs.usl.edu [130.70.113.22])
by d22.ucs.usl.edu (8.9.1/8.9.1/ucsclient_1.3) with SMTP id GAA06998
for ; Thu, 30 Sep 1999 06:59:12 0500 (CDT)
MessageId: <199909301159.GAA06998 [at] d22 [dot] ucs.usl.edu>
Date: Thu, 30 Sep 1999 06:59:12 0500 (CDT)
From: Kearfott Ralph B
ReplyTo: Kearfott Ralph B
Subject: Test message: please discard
To: reliable_computing [at] interval [dot] usl.edu
MIMEVersion: 1.0
ContentType: TEXT/plain; charset=usascii
ContentMD5: ruVPsuBJfKevPFzf04zG6A==
XMailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc
Sender: ownerreliable_computing [at] interval [dot] usl.edu
Precedence: bulk
This is a test message. interval.louisiana.edu's disk space has
been upgraded.
R. Baker Kearfott, rbk [at] usl [dot] edu (318) 2315346 (fax)
(318) 2315270 (work) (318) 9819744 (home)
From ownerreliable_computing [at] interval [dot] usl.edu Thu Sep 30 18:17:15 1999
Received: (from root@localhost)
by interval.usl.edu (8.9.1/8.9.1/intervalmathmajordomo1.0) id SAA00677
for reliable_computingoutgoing; Thu, 30 Sep 1999 18:17:14 0500 (CDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by interval.usl.edu (8.9.1/8.9.1/intervalmathmajordomo1.0) with ESMTP id SAA00672
for ; Thu, 30 Sep 1999 18:17:11 0500 (CDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA26843;
Thu, 30 Sep 1999 16:17:00 0700 (PDT)
Received: from hasims.eng.sun.com (physthestorka.Eng.Sun.COM [129.146.1.231])
by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA12077;
Thu, 30 Sep 1999 16:17:00 0700 (PDT)
Received: from gww (gww.Eng.Sun.COM [129.146.78.116])
by hasims.eng.sun.com (Sun Internet Mail Server sims.4.0.1999.06.13.00.20)
with SMTP id <0FIW00FJWBCAB8@hasims.eng.sun.com>; Thu,
30 Sep 1999 16:16:58 0700 (PDT)
Date: Thu, 30 Sep 1999 16:16:58 0700 (PDT)
From: William Walster
Subject: Re: Accreditation of Codes
To: ivandv [at] mailhost [dot] cs.clemson.edu, steve [at] cs [dot] clemson.edu,
reliable_computing [at] interval [dot] usl.edu, rbk [at] usl [dot] edu
Replyto: William Walster
Messageid: <0FIW00FJXBCAB8@hasims.eng.sun.com>
MIMEversion: 1.0
XMailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4m sparc
Contenttype: TEXT/plain; charset=usascii
ContentMD5: /NhqMQX9Y9hkaIzl3WM0Aw==
Sender: ownerreliable_computing [at] interval [dot] usl.edu
Precedence: bulk
Sorry,
But I must make some comments regarding this thread:
1) It is important to distinguish between various contributors
to the width of an interval result:
a) width in input data, ie. measurement error
b) modeling errors, for which interval bounds may
be included
c) interactions of the above with the condition or
inherent stability of the problem
d) numerical instability resulting from rounding errors
and catestrophic cancellation in an algorithm
e) interval dependence
To the extent that a, b, and c are responsible for width of results,
this is what you want to see. It is telling you that given the information
with which you have to work, this is the best you can do regarding bounds
on the answer you are computing.
To the extend that d and e are dominating the width of the answer, cleaning
up the algorithm and/or using a more sophisticated approach may be required.
We, in the interval community work hard to make sure that a, b, and c and
*not* d and e are the primary sources of interval width. Nevertheless,
as George and Baker have pointed out, whenever an interval result is
bounded away from some critical value, this constitutes a numerical
proof, given, of course that implementation errors and unknown modeling
errors do not exist.
As for quality of implementation, because interval "containment" is
such a strong requirement, and because width is so visible, my
expectation is that you will see much higher quality in interval
implementations than have traditionally been the case in the
point world.
Regards,
Bill Walster
>Date: Wed, 29 Sep 1999 09:48:00 0500
>From: "R. Baker Kearfott"
>Subject: Re: Accreditation of Codes
>XSender: rbk5287 [at] pop [dot] usl.edu
>To: ivandv [at] mailhost [dot] cs.clemson.edu, steve [at] cs [dot] clemson.edu,
reliable_computing [at] interval [dot] usl.edu
>MIMEversion: 1.0
>
>At 10:26 AM 9/29/99 0400, Steve Stevenson wrote:
>>R. Baker Kearfott writes:
>
>> > > > What we have some hope of "accreditation" is an assertion
>> > > > that our rootfinding program will either
>> > > > 1. Return an interval enclosing a root (or a set of intervals
>> > > > enclosing all roots),
>> > > > 2. Return the assertion that the function has no root in
>> > > > a specified interval, or
>> > > > 3. Is unable to do either 1. or 2., perhaps with partial
>> > > > results.
>> > >
>> > >I think this is close, but again does not talk about real
>> > >computing. Here's a simple example: suppose the physicist lies down
>> > >the following formula, f = sin((n\pi+s)x)+a  ((xb)+c), and then she
>> > >declares that the "science" is in the root, and the observations for x
>> > >with a given set of n,s,a,b,c is \mu\pm\sigma. You now turn loose your
>> > >favorite algorithm and get m and m isn't close to \mu. Now what?
>> > >
>> >
>> > Steve, I don't understand your issue with George's comment. The
>> > interval computations, properly set up, would give a large interval
>> > that contains $\mu$, rather than give an $m$ that is not close
>> > to $\mu$.
>>
>>Baker:
>>
>>Of course, this is not what the physicist wants or needs. In fact,
>>think of it this way. Consider something like the Hubble constant: a
>>number above which one thing happens and below which something else
>>happens. Presumedly, the computation contains both outcomes. Which do
>>I pick?
>
>Yes, that would be a problem. Certainly, interval computations can
>fail in the sense that they can give an interval that is too large
>to provide the information sought. But they cannot ``lie" in the
>sense that they give an interval that doesn't contain the true
>result (unless the model is wrong). Also, in many cases with
>real problems (in fact, in an increasing number in the past few
>years), interval computations HAVE yielded physical insight. In
>your hypothetical example, they could in principle yield, say,
>fairly wide bounds on the Hubble constant, but such that the upper
>bound is below the threshold of an expanding universe. If the
>model were properly set up, that would guarantee that the universe
>would eventually collapse in on itself.
>
>>
>> > Of course, if an incorrect model is used, an incorrect
>> > result would be obtained, and interval arithmetic cannot help with
>> > that. However, if uncertainties in the model can be quantified,
>> > then interval computations can be used to translate the model
>> > uncertainties into uncertainties in the answer.
>> >
>> > In fact, that's part of the point of interval computations: to get
>> > finite , "real" machines and simplified models of "realworld"
>> > phenomena to enclose the actual "real" quantities or behavior with
>> > mathematical rigor.
>> >
>> > Or did I miss your point?
>>
>>I don't think you missed my point about the computation. My question
>>is, "How do I interpret your answer?" You give me an interval, but
>>what is the most probable value of the root? Certainly you don't
>>intend that  information theoretically speaking  every point in
>>that interval has an equiprobable chance of being the root.
>>
>
>That's true, interval arithmetic does not distinguish between
>different points in the interval in the sense of a nonuniform
>statistical distribution. (That is, an arithmetic interval corresponds
>to a uniform distribution.) However, in validating (i.e. in producing
>rigorous error bounds) on a root that is already known approximately,
>tight intervals, on the order of the roundoff error achievable with
>point arithmetic, are often obtainable.
>
>>You do miss the philosophical point that mathematical rigor does not
>>carry over to real machines. For example, look at how poorly and
>>unevenly IEEE 754 is acutally implemented (See my CiSE article).
>>
>
>Ah, yes. We can have a standard, but that doesn't guarantee that
>it's universally, completely, or correctly implemented :(
>
>Best regards,
>
>Baker
>
>
>
>R. Baker Kearfott, rbk [at] usl [dot] edu (318) 4825346 (fax)
>(318) 4825270 (work) (318) 9819744 (home)
>URL: http://interval.usl.edu/kearfott.html
>Department of Mathematics, University of Louisiana at Lafayette
>Box 41010, Lafayette, LA 705041010, USA
>
>
>
>
>=======================================================================
>See http://www.cs.clemson.edu/~steve/ivandv for detailed information on
>submitting and "unsubscribing". Problems to ivandvowner [at] cs [dot] clemson.edu
>