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 <reliable_computing [at] interval [dot] usl.edu>; 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 <georgec [at] mscs [dot] mu.edu>
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 <FengX [at] Marquette [dot] edu>
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 <reliable_computing [at] interval [dot] usl.edu>; 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" <hu [at] happy [dot] dt.uh.edu>
Message-Id: <10003010934.ZM28861 [at] happy [dot] dt.uh.edu>
Date: Wed, 1 Mar 2000 09:34:10 -0800
In-Reply-To: George Corliss <georgec [at] mscs [dot] mu.edu>
        "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 <FengX [at] Marquette [dot] edu>, 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 <reliable_computing [at] interval [dot] usl.edu>; 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 <reliable_computing [at] interval [dot] usl.edu>; 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 <reliable_computing [at] interval [dot] usl.edu>; Fri, 3 Mar 2000 15:17:56 -0300 (EST)
Date: Fri, 3 Mar 2000 15:17:56 -0300 (EST)
From: Regivan Hugo Nunes Santiago <regivan [at] dimap [dot] ufrn.br>
X-Sender: regivan@baltazar
To: reliable_computing [at] interval [dot] usl.edu
Subject: Scan 2000 and INTERVAL'2000
Message-ID: <Pine.GSO.3.96.1000303151434.3575A-100000@baltazar>
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 <reliable_computing [at] interval [dot] usl.edu>; 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 <fayad [at] cse [dot] unl.edu>
To: Undisclosed recipients: ;
Subject: Enterprise Frameworks - CFPs  
Message-ID: <Pine.SGI.4.05.10003041538530.950526-100000 [at] cse [dot] unl.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.SGI.4.05.10003022302302.683368 [at] cse [dot] unl.edu>
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 <reliable_computing [at] interval [dot] usl.edu>; 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 <axel.facius [at] math [dot] uni-karlsruhe.de>
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 <regivan [at] dimap [dot] ufrn.br>
Subject: Re: Scan 2000 and INTERVAL'2000
References: <Pine.GSO.3.96.1000303151434.3575A-100000@baltazar>
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 <reliable_computing [at] interval [dot] usl.edu>; 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 <reliable_computing [at] interval [dot] usl.edu>; 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 <doris [at] cs [dot] tu-berlin.de>
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 <reliable_computing [at] interval [dot] usl.edu>; 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 <asap [at] EECS [dot] Lehigh.EDU>
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 <reliable_computing [at] interval [dot] usl.edu>; 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 <dmk [at] engmail [dot] newcastle.edu.au>
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 <reliable_computing [at] interval [dot] usl.edu>; 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 <Birgit.Westermann [at] unibas [dot] ch>
Subject: Remove from mailing list
To: ASAP User <asap [at] EECS [dot] Lehigh.EDU>
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 <reliable_computing [at] interval [dot] usl.edu>; 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 <asap-announce [at] eecs [dot] lehigh.edu>; 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 <hartenst [at] rhrk [dot] uni-kl.de>
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 <Oliver.Diessel [at] unisa [dot] edu.au>, Yang <lyang [at] stfx [dot] ca>,
        Postula <adam [at] csee [dot] uq.edu.au>, Lisper <bjorn.lisper [at] mdh [dot] se>,
        Vernalde <vernalde [at] imec [dot] be>, becker <becker [at] mes [dot] tu-darmstadt.de>,
        kurdahi <kurdahi [at] ece [dot] uci.edu>, wnajjar <wnajjar [at] ece [dot] uci.edu>,
        latifi <latifi [at] ee [dot] unlv.edu>, gaudiot <gaudiot [at] usc [dot] edu>,
        wl <wl [at] doc [dot] ic.ac.uk>,
        "catherine.dezan" <catherine.dezan@univ-brest.fr>,
        Brebner <gordon [at] dcs [dot] edinburgh.ac.uk>, lombardi <lombardi [at] cs [dot] tamu.edu>,
        bohm <bohm [at] cs [dot] colostate.edu>,
        asap-announce <asap-announce [at] EECS [dot] Lehigh.EDU>,
        Liste BM-List1 <BM-List1 [at] cs [dot] ucdavis.edu>
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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<p><tt>please, excuse multiple copies</tt>
<br><tt>please, distribute</tt>
<br>&nbsp;
<br>&nbsp;
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2nd Call for Papers</tt>
<br>&nbsp;
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
FPL 2000</tt>
<br>&nbsp;
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
The 10th International Conference on</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Field Programmable Logic and Applications</tt>
<br>&nbsp;
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
28 - 30 August 2000</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Villach, Austria</tt>
<br>&nbsp;
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>>>&nbsp; Paper deadline: 17 March 2000&nbsp; &lt;&lt;&lt;</tt>
<br>&nbsp;
<br>&nbsp;
<p><tt>Growing Conference (growth 1999: 55%)&nbsp;&nbsp; -&nbsp;&nbsp;
Extended Scope</tt>
<br><tt>Prominent Professional Keynote Speakers</tt>
<p><tt>Future SoC - System on a Chip: impossible without Reconfigurable</tt>
<br><tt>Subsystems</tt>
<p><tt>The conference proceedings will be published by Springer Verlag</tt>
<br><tt>See:&nbsp;&nbsp; <a href="http://link.springer.de/series/lncs/">http://link.springer.de/series/lncs/</a></tt>
<p><tt>Topics to be covered include, but are not limited to:</tt>
<p><tt>&nbsp;&nbsp; Reconfigurable Hardware and Systems:</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; Fine grain - Coarse grain - Reconfigurable
Computing</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; Adaptive&nbsp; -&nbsp; Customizable&nbsp;
-&nbsp; Embedded&nbsp; -&nbsp; fault-tolerant</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; Architectures&nbsp; -&nbsp; Technologies&nbsp;
-&nbsp; Low Power&nbsp; -&nbsp; Dynamically Rec.</tt>
<p><tt>&nbsp;&nbsp; Applications:</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; Routing&nbsp; -&nbsp;&nbsp; Networking&nbsp;
-&nbsp; Wireless&nbsp; -&nbsp; Evolvable</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; Real-world&nbsp; -&nbsp; Scientific&nbsp;
-&nbsp; Rapid-prototyping&nbsp; -&nbsp; Others</tt>
<p><tt>&nbsp;&nbsp; CAD, Compilation, Testing and Verification:</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; Design Flow&nbsp; -&nbsp; Tools&nbsp;
-&nbsp; Higher Level Synthesis</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; Interconnect&nbsp; -&nbsp; Parameter Estimation&nbsp;
-&nbsp; Benchmarks</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; Testing and Verification of Dynamically
Reconfigurable Apps</tt>
<p><tt>&nbsp;&nbsp; Surveys, Tutorials, Future, History, and Education:</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; Roadmaps to Technology, Application and
Design</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; Teaching Reconfigurables &amp; Evolvables&nbsp;
-&nbsp; Curricular Impact</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; Student Projects&nbsp; -&nbsp; Industry
/ University Programs&nbsp; - Publicity</tt>
<p><tt>&nbsp;&nbsp; Evolvable Hardware and Evolutionary Compilation Methods:</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; Evolvable Hardware (EH) -&nbsp; Co-Evolution</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; Tools and methodologies&nbsp; -&nbsp;
Genetic Programming</tt>
<p><tt>&nbsp;&nbsp; Emerging and Other RL/RC-related Methodologies:</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; State machines -&nbsp; Cellular Automata</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; Biologically inspired - Brain inspired</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; fludic reconfigurable logic and applications</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; Molecular Biology Applications</tt>
<p><tt>For details on topic areas and conference location see:</tt>
<br><tt><a href="http://xputers.informatik.uni-kl.de/FPL/FPL2000/detailed_fpl.html">http://xputers.informatik.uni-kl.de/FPL/FPL2000/detailed_fpl.html</a></tt>
<p><tt>Authors are invited to submit PDF of their paper (10 pages maximum)</tt>
<br><tt>by date March 17, 2000 via E-mail to <a href="mailto:hartenst [at] rhrk [dot] uni-kl.de">mailto:hartenst [at] rhrk [dot] uni-kl.de</a></tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
and: <a href="mailto:hoffmant [at] rhrk [dot] uni-kl.de">mailto:hoffmant [at] rhrk [dot] uni-kl.de</a></tt>
<br><tt>For guidelines see&nbsp;&nbsp;&nbsp; <a href="http://www.springer.de/comp/lncs/authors.html">http://www.springer.de/comp/lncs/authors.html</a></tt>
<br><tt>Questions please, address to:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="mailto:hoffmant [at] rhrk [dot] uni-kl.de">mailto:hoffmant [at] rhrk [dot] uni-kl.de</a></tt>
<p><tt>Download Call for Papers and Registration Form:&nbsp; PLEASE, DISTRIBUTE
:</tt>
<br><tt>PDF: <a href="http://xputers.informatik.uni-kl.de/FPL/fpl2000/CfP_FPL2000.pdf">http://xputers.informatik.uni-kl.de/FPL/fpl2000/CfP_FPL2000.pdf</a></tt>
<br><tt>ps:&nbsp; <a href="http://xputers.informatik.uni-kl.de/FPL/fpl2000/CfP_FPL2000.ps">http://xputers.informatik.uni-kl.de/FPL/fpl2000/CfP_FPL2000.ps</a></tt>
<p><tt>Reiner Hartenstein</tt>
<br><tt>Program Chair FPL-2000</tt></html>

--------------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 <reliable_computing [at] interval [dot] usl.edu>; 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
 <forte-pstv-2000-lists [at] mail [dot] iat.cnr.it>; Wed, 08 Mar 2000 17:19:16 +0100
Date: Wed, 08 Mar 2000 17:13:44 +0100
From: Tommaso Bolognesi <t.bolognesi [at] IEI [dot] PI.CNR.IT>
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: <l03130300b4ec2c831f4a@[146.48.84.49]>
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 <reliable_computing [at] interval [dot] usl.edu>; 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: <FB5C241B1298D111AB6E00805FFE7E16024D8130 [at] exc04crdge [dot] crd.ge.com>
From: "Puckette, Charles M (CRD)" <puckette [at] crd [dot] ge.com>
To: "'Birgit Westermann'" <Birgit.Westermann [at] unibas [dot] ch>,
        ASAP User
	 <asap [at] EECS [dot] Lehigh.EDU>
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 <reliable_computing [at] interval [dot] louisiana.edu>; 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 <reliable_computing [at] interval [dot] louisiana.edu>; 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 <reliable_computing [at] interval [dot] louisiana.edu>; 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" <ssh [at] nbsp [dot] nsk.su>
Reply-To: "Sergey P. Shary" <ssh [at] nbsp [dot] nsk.su>
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 <reliable_computing [at] interval [dot] louisiana.edu>; 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 <neum [at] cma [dot] univie.ac.at>
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 <reliable_computing [at] interval [dot] louisiana.edu>; 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 <reliable_computing [at] interval [dot] louisiana.edu>; 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 <reliable_computing [at] interval [dot] louisiana.edu>; Thu, 9 Mar 2000 15:23:43 +0200
Message-Id: <200003091323.PAA29131 [at] iph [dot] bio.bas.bg>
Comments: Authenticated sender is <smarkov [at] iph [dot] bio.bas.bg>
From: "Svetoslav Markov" <smarkov [at] iph [dot] bio.bas.bg>
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 <reliable_computing [at] interval [dot] louisiana.edu>; 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 <reliable_computing [at] interval [dot] louisiana.edu>; 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 <rbk5287 [at] louisiana [dot] edu>
Reply-To: Kearfott Ralph B <rbk5287 [at] louisiana [dot] edu>
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" <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
---------------------------------------------------------------


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 <reliable_computing [at] interval [dot] louisiana.edu>; 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 <G2B0M5WD>; Thu, 9 Mar 2000 16:05:09 -0500
Message-ID: <03E3E0690542D211A1490000F80836F402879920 [at] zcard00f [dot] ca.nortel.com>
From: "Bill Older" <wolder [at] nortelnetworks [dot] com>
To: Kearfott Ralph B <rbk5287 [at] louisiana [dot] edu>,
        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" <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
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2651.65">
<TITLE>RE: &quot;Symmetric&quot; intervals</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>The notion of a symmetric interval is extremely important</FONT>
<BR><FONT SIZE=2>because of its &quot;algebraic&quot; properties ( symmetric intervals</FONT>
<BR><FONT SIZE=2>being the analogue of an ideal), so I personally find</FONT>
<BR><FONT SIZE=2>&quot;zero-symmetric&quot; unduly cumbersome.&nbsp; And wouldn't</FONT>
<BR><FONT SIZE=2>&quot;symmetric matrix of symmetric intervals&quot; be perfectly clear,</FONT>
<BR><FONT SIZE=2>even though &quot;symmetric interval matrix&quot; is clearly ambiguous?</FONT>
</P>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Kearfott Ralph B [<A HREF="mailto:rbk5287 [at] louisiana [dot] edu">mailto:rbk5287 [at] louisiana [dot] edu</A>]</FONT>
<BR><FONT SIZE=2>Sent: Thursday, March 09, 2000 10:08 AM</FONT>
<BR><FONT SIZE=2>To: reliable_computing [at] interval [dot] louisiana.edu</FONT>
<BR><FONT SIZE=2>Subject: Re: &quot;Symmetric&quot; intervals</FONT>
</P>
<BR>

<P><FONT SIZE=2>I agree with Sergey that it would be good to use different terms</FONT>
<BR><FONT SIZE=2>for &quot;symmetric interval matrices&quot; and for intervals that are symmetric</FONT>
<BR><FONT SIZE=2>with respect to zero.&nbsp; I also support </FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp; &quot;zero-symmetric&quot; </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>for intervals that are symmetric with respect to zero, since the </FONT>
<BR><FONT SIZE=2>term is both</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; * suggestive and, apparently, </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; * consistent with an established term from convex analysis.&nbsp; </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>(Lamentably, I'm not personally familiar with &quot;t-symmetric&quot;, but I'll </FONT>
<BR><FONT SIZE=2>trust Svetoslav.) </FONT>
</P>

<P><FONT SIZE=2>Hopefully such a new use will become&nbsp; established in our literature.</FONT>
</P>

<P><FONT SIZE=2>Best regards,</FONT>
</P>

<P><FONT SIZE=2>Baker</FONT>
</P>

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

<P><FONT SIZE=2>---------------------------------------------------------------</FONT>
<BR><FONT SIZE=2>R. Baker Kearfott,&nbsp;&nbsp;&nbsp; rbk [at] louisiana [dot] edu&nbsp;&nbsp; (337) 482-5346 (fax)</FONT>
<BR><FONT SIZE=2>(337) 482-5270 (work)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (337) 981-9744 (home)</FONT>
<BR><FONT SIZE=2>URL: <A HREF="http://interval.louisiana.edu/kearfott.html" TARGET="_blank">http://interval.louisiana.edu/kearfott.html</A></FONT>
<BR><FONT SIZE=2>Department of Mathematics, University of Louisiana at Lafayette</FONT>
<BR><FONT SIZE=2>Box 4-1010, Lafayette, LA 70504-1010, USA</FONT>
<BR><FONT SIZE=2>---------------------------------------------------------------</FONT>
</P>

</BODY>
</HTML>
------_=_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 <reliable_computing [at] interval [dot] louisiana.edu>; 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 <smarkov [at] iph [dot] bio.bas.bg>
From: "Svetoslav Markov" <smarkov [at] iph [dot] bio.bas.bg>
Organization: Institute of Mathematics, BAS
To: Kearfott Ralph B <rbk5287 [at] louisiana [dot] edu>
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 <reliable_computing [at] interval [dot] usl.edu>; 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" <rohn [at] uivt [dot] cas.cz>
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 <reliable_computing [at] interval [dot] usl.edu>; 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 <neum [at] cma [dot] univie.ac.at>
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 <reliable_computing [at] interval [dot] louisiana.edu>; 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" <ssh [at] nbsp [dot] nsk.su>
Reply-To: "Sergey P. Shary" <ssh [at] nbsp [dot] nsk.su>
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 <reliable_computing [at] interval [dot] louisiana.edu>; 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 <neum [at] cma [dot] univie.ac.at>
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 <reliable_computing [at] interval [dot] louisiana.edu>; 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" <ssh [at] nbsp [dot] nsk.su>
Reply-To: "Sergey P. Shary" <ssh [at] nbsp [dot] nsk.su>
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 <reliable_computing [at] interval [dot] louisiana.edu>; 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" <ssh [at] nbsp [dot] nsk.su>
Reply-To: "Sergey P. Shary" <ssh [at] nbsp [dot] nsk.su>
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 <reliable_computing [at] interval [dot] louisiana.edu>; 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 <neum [at] cma [dot] univie.ac.at>
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 <reliable_computing [at] interval [dot] louisiana.edu>; 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 <smarkov [at] iph [dot] bio.bas.bg>
From: "Svetoslav Markov" <smarkov [at] iph [dot] bio.bas.bg>
Organization: Institute of Mathematics, BAS
To: "Bill Older" <wolder [at] nortelnetworks [dot] com>
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" <wolder [at] nortelnetworks [dot] com>
> To:            Kearfott Ralph B <rbk5287 [at] louisiana [dot] edu>,
>                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 <reliable_computing [at] interval [dot] louisiana.edu>; 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 <reliable_computing [at] interval [dot] louisiana.edu>; 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 <jmaurer [at] menuett [dot] rhein-main.de>
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 <reliable_computing [at] interval [dot] louisiana.edu>; 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 <jsiek [at] lsc [dot] nd.edu> 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 <jmaurer [at] menuett [dot] rhein-main.de>
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 <jsiek [at] lsc [dot] nd.edu>
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 <reliable_computing [at] interval [dot] usl.edu>; 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: <AAn8souGMG [at] slava [dot] nit.spb.su>
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" <nest [at] slava [dot] nit.spb.su>
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 <reliable_computing [at] interval [dot] louisiana.edu>; 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 <reliable_computing [at] interval [dot] louisiana.edu>; 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 <reliable_computing [at] interval [dot] louisiana.edu>; Sun, 12 Mar 2000 14:04:40 +0200
Message-Id: <200003121204.OAA07087 [at] iph [dot] bio.bas.bg>
Comments: Authenticated sender is <smarkov [at] iph [dot] bio.bas.bg>
From: "Svetoslav Markov" <smarkov [at] iph [dot] bio.bas.bg>
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 <reliable_computing [at] interval [dot] louisiana.edu>; 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 <georgec [at] mscs [dot] mu.edu>
Organization: Marquette University
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jens Maurer <jmaurer [at] menuett [dot] rhein-main.de>
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

<dl>
<dt><i>The Extended Real Interval System,</i>
<dd>G. William (Bill) Walster,
<dd><a href =
"http://www.mscs.mu.edu/~globsol/Papers/extended_intervals.ps"
    >extended_intervals.ps</a>
(Postscript - 295 Kb) 29 April 1998
<dd><a href = "http://www.mscs.mu.edu/~globsol/Papers/ext_int_fig1.ps"
    >Figure 1, page 8</a>
(Postscript - 130 Kb)
<dd><a href =
"http://www.mscs.mu.edu/~globsol/Papers/ext_int_pg38-41.ps"
    >Figures, pages 38 - 42.</a>
(Postscript - 188 Kb)
<blockquote>
<b>Abstract:</b> 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.
</blockquote>


<dt><i>Interval Extensions of Real Functions with Finite Domains,</i>
<dd>G. William (Bill) Walster,
<dd><a href =
"http://www.mscs.mu.edu/~globsol/Papers/domain.ps">domain.ps</a>
(Postscript - 84 Kb) 28 April 1998.
<blockquote>
<b>Abstract:</b> Alternatives are considered for constructing interval
enclosures of real functions with finite domains.
</blockquote>

</dl>

<p>
See also <b>Interval compilers and programming
<a href =
"http://www.mscs.mu.edu/~georgec/IFAQ/environments.html">environments</a></b>


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 <reliable_computing [at] interval [dot] louisiana.edu>; 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" <wolff [at] informatik [dot] uni-wuerzburg.de>
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 <jmaurer [at] menuett [dot] rhein-main.de>
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
> 
> <dl>
> <dt><i>The Extended Real Interval System,</i>
> <dd>G. William (Bill) Walster,
> <dd><a href =
> "http://www.mscs.mu.edu/~globsol/Papers/extended_intervals.ps"
>     >extended_intervals.ps</a>
> (Postscript - 295 Kb) 29 April 1998
> <dd><a href = "http://www.mscs.mu.edu/~globsol/Papers/ext_int_fig1.ps"
>     >Figure 1, page 8</a>
> (Postscript - 130 Kb)
> <dd><a href =
> "http://www.mscs.mu.edu/~globsol/Papers/ext_int_pg38-41.ps"
>     >Figures, pages 38 - 42.</a>
> (Postscript - 188 Kb)
> <blockquote>
> <b>Abstract:</b> 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.
> </blockquote>
> 
> <dt><i>Interval Extensions of Real Functions with Finite Domains,</i>
> <dd>G. William (Bill) Walster,
> <dd><a href =
> "http://www.mscs.mu.edu/~globsol/Papers/domain.ps">domain.ps</a>
> (Postscript - 84 Kb) 28 April 1998.
> <blockquote>
> <b>Abstract:</b> Alternatives are considered for constructing interval
> enclosures of real functions with finite domains.
> </blockquote>
> 
> </dl>
> 
> <p>
> See also <b>Interval compilers and programming
> <a href =
> "http://www.mscs.mu.edu/~georgec/IFAQ/environments.html">environments</a></b>
> 
> 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 <reliable_computing [at] interval [dot] louisiana.edu>; 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 <jmaurer [at] menuett [dot] rhein-main.de>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.3.51 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: George Corliss <georgec [at] mscs [dot] mu.edu>
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 <reliable_computing [at] interval [dot] louisiana.edu>; 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 <jmaurer [at] menuett [dot] rhein-main.de>,
        George Corliss <georgec [at] mscs [dot] mu.edu>
From: "R. Baker Kearfott" <rbk [at] louisiana [dot] edu>
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 <reliable_computing [at] interval [dot] louisiana.edu>; 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 <bill.walster [at] eng [dot] sun.com>
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 <bill.walster [at] eng [dot] sun.com>
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" <rbk [at] louisiana [dot] edu>
  >Subject: Re: New C++ Library for Interval Arithmetic
  >X-Sender: rbk5287 [at] pop [dot] usl.edu
  >To: Jens Maurer <jmaurer [at] menuett [dot] rhein-main.de>, George Corliss <georgec [at] mscs [dot] mu.edu>
  >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