From ownerreliable_computing Tue Dec 2 11:44:15 1997
Received: by interval.usl.edu id AA07217
(5.65c/IDA1.4.4 for reliable_computingoutgoing); Tue, 2 Dec 1997 03:49:21 0600
Received: from cesare (cesare.diiie.unisa.it) by interval.usl.edu with SMTP id AA07211
(5.65c/IDA1.4.4 for ); Tue, 2 Dec 1997 03:49:11 0600
Received: by cesare; (5.57/1.1.8.2/22May951218PM)
id AA10676; Sat, 1 Nov 97 10:45:10 0600
MessageId: <3483D86E.3DF0 [at] diiie [dot] unisa.it>
Date: Tue, 02 Dec 1997 10:44:15 +0100
From: Giovanni Spagnuolo
ReplyTo: spanish [at] diiie [dot] unisa.it
XMailer: Mozilla 3.01Gold (Win95; I)
MimeVersion: 1.0
To: reliable_computing [at] interval [dot] usl.edu, interval [at] cs [dot] utep.edu
Subject: interval equations systems
ContentType: text/plain; charset=usascii
ContentTransferEncoding: 7bit
Sender: ownerreliable_computing
Precedence: bulk
Dear intervalers,
I'm looking for some documentation about solving systems of nonlinear
interval equations of the kind F(X,P)=0, with P interval parameters and
X interval unknowns.
Any suggestion?
Thanks in advance
Giovanni Spagnuolo
Ph.D. student
Dipartimento di Ingegneria Informatica ed Ingegneria Elettrica
Universita' di Salerno  Italy
Email: spanish [at] diiie [dot] unisa.it
From ownerreliable_computing Tue Dec 2 12:50:25 1997
Received: by interval.usl.edu id AA07645
(5.65c/IDA1.4.4 for reliable_computingoutgoing); Tue, 2 Dec 1997 04:51:17 0600
Received: from Pap.UniVie.AC.AT (apap4.pap.univie.ac.at) by interval.usl.edu with SMTP id AA07639
(5.65c/IDA1.4.4 for ); Tue, 2 Dec 1997 04:51:07 0600
Received: from homer.cma.univie.ac.at by Pap.UniVie.AC.AT (PMDF V5.04 #10670)
id <01IQP48HWUJ48WWS6I [at] Pap [dot] UniVie.AC.AT>; Tue, 02 Dec 1997 11:50:36 +0100 (MET)
Received: by homer.cma.univie.ac.at (5.65v3.2/1.1.10.5/19Mar971148AM)
id AA31582; Tue, 02 Dec 1997 11:50:25 +0100
Date: Tue, 02 Dec 1997 11:50:25 +0100
From: Arnold Neumaier
Subject: Re: interval equations systems
To: interval [at] cs [dot] utep.edu, reliable_computing [at] interval [dot] usl.edu,
spanish [at] diiie [dot] unisa.it
Cc: neum [at] homer [dot] cma.univie.ac.at
MessageId: <9712021050.AA31582 [at] homer [dot] cma.univie.ac.at>
ContentTransferEncoding: 7BIT
Sender: ownerreliable_computing
Precedence: bulk
Giovanni Spagnuolo wrote:
>>I'm looking for some documentation about solving systems of nonlinear
interval equations of the kind F(X,P)=0, with P interval parameters and
X interval unknowns.<<
If the interval parameter vector is sufficiently narrow,
the methods in Section 5.5 of my book
A. Neumaier
Interval Methods for Systems of Equations
Encyclopedia of Mathematics and its Applications 37,
Cambridge Univ. Press, Cambridge 1990
xvi + 255 pp.
ISBN052133196X
are applicable. For wider intervals, one possiblity is to combine these
methods with a branch and bound technique. But I think no one has
explored this.
Arnold Neumaier
From ownerreliable_computing Tue Dec 2 13:50:53 1997
Received: by interval.usl.edu id AA08063
(5.65c/IDA1.4.4 for reliable_computingoutgoing); Tue, 2 Dec 1997 05:53:12 0600
Received: from iamk4526.mathematik.unikarlsruhe.de by interval.usl.edu with SMTP id AA08057
(5.65c/IDA1.4.4 for ); Tue, 2 Dec 1997 05:53:02 0600
Received: (from ae58@localhost) by iamk4526.mathematik.unikarlsruhe.de (8.6.10/8.6.10) id MAA02350; Tue, 2 Dec 1997 12:50:54 +0100
Date: Tue, 2 Dec 1997 12:50:53 +0100 (MET)
From: Stefan Dietrich
XSender: ae58 [at] iamk4526 [dot] mathematik.unikarlsruhe.de
To: interval [at] cs [dot] utep.edu, reliable_computing [at] interval [dot] usl.edu,
Giovanni Spagnuolo
Subject: Re: interval equations systems
MessageId:
MimeVersion: 1.0
ContentType: TEXT/PLAIN; charset=USASCII
Sender: ownerreliable_computing
Precedence: bulk
Giovanni Spagnuolo wrote:
>>I'm looking for some documentation about solving systems of nonlinear
interval equations of the kind F(X,P)=0, with P interval parameters and
X interval unknowns.<<
In chapter 13 of the book
R. Hammer, M. Hocks, U. Kulisch, D. Ratz
Numerical Toolbox for Verified Computing I: Basic Numerical Problems
 Theory, Algorithms, and PascalXSC Programs
Springer, Berlin, 1993
the problem of finding the solution vectors of a system of nonlinear
equations is considered. A method for finding "all" solutions of a
nonlinear system of equations f(x)=0 for a continuously differentiable
function f: IR^n > IR^n in a given interval vector is described.
That method computes close bounds for the solution vectors, and it
delivers information about existence and uniqueness of the computed
solutions. The presented method is a variant of the interval Gauss
Seidel method based on the method of Hansen and Sengupta, and a
modification of Ratz.
More details (theory, algorithms, programs) can be found at:
http://www.unikarlsruhe.de/~iam/html/literatur/toolbox.html
Best regards,
Stefan Dietrich

Dipl.Math. Stefan Dietrich Tel.: +49 / (0)721 / 9 37 54 86
Institut fuer Angewandte Mathematik Fax : +49 / (0)721 / 38 59 79
Universitaet Karlsruhe (TH), Kaiserstr. 12, Postfach 6980, D76128 Karlsruhe
Email: Stefan.Dietrich [at] math [dot] unikarlsruhe.de
WWW : http://www.unikarlsruhe.de/~Stefan.Dietrich/

From ownerreliable_computing Wed Dec 3 22:11:31 1997
Received: by interval.usl.edu id AA08994
(5.65c/IDA1.4.4 for reliable_computingoutgoing); Wed, 3 Dec 1997 14:09:08 0600
Received: from cesit1.unifi.it by interval.usl.edu with SMTP id AA08988
(5.65c/IDA1.4.4 for ); Wed, 3 Dec 1997 14:08:19 0600
Received: from aguirre.dsi.unifi.it by CESIT1.UNIFI.IT (PMDF V5.04 #3688)
id <01IQR1XMK6ZK000M92 [at] CESIT1 [dot] UNIFI.IT> for
reliable_computing [at] interval [dot] usl.edu; Wed, 03 Dec 1997 21:06:53 +0100 (MET)
Received: by aguirre.dsi.unifi.it (4.1/SMI4.1) id AA22224; Wed,
03 Dec 1997 21:11:31 +0100
Date: Wed, 03 Dec 1997 21:11:31 +0100
From: csmr98 [at] dsi [dot] unifi.it
Subject: Conf. Prog.: CSMR98+REF98: Maintenance & Reengineering in Florence
To: reliable_computing [at] interval [dot] usl.edu
MessageId: <9712032011.AA22224 [at] aguirre [dot] dsi.UNIFI.IT>
MimeVersion: 1.0
ContentType: TEXT/PLAIN
ContentTransferEncoding: QUOTEDPRINTABLE
Sender: ownerreliable_computing
Precedence: bulk
Dear colleague:
Here is the prliminary program of this combined conference:
2nd EUROMICRO WORKING CONFERENCE on SOFTWARE MAINTENANCE AND REENGINE=
ERING=20
and
6th REENGINEERING FORUM
that will be help in Florence, Italy, 811 March 1998.
Since their timeline for producing the preliminary program is=20
different we start with the diffusion of preliminary program
without the papers of REF. =20
Please accept our apologies if you receive multiple copies of this ca=
ll.
Please post forward to all your interested colleagues.
Please visit our www page: http://www.dsi.unifi.it/~nesi/csmr98.html
thank you=20
=

Preliminary Program
2nd EUROMICRO CONFERENCE on SOFTWARE=20
MAINTENANCE AND REENGINEERING
and
6th REENGINEERING FORUM
March 811, 1998, Florence, Italy
Sponsored by: Euromicro, REF, IEEE (TSE)
In cooperation with: CESVIT
Patroned by: Univ.Firenze, AIIA, DSI, AICA, TABOO,...
Please visit our www site:=20
http://www.dsi.unifi.it/~nesi/csmr98.html
contact: csmr98 [at] aguirre [dot] ing.unifi.it
Proceeding printed by: IEEE Press for the conference time.
Preliminary Program
=20
Keynote Speakers:=20
* Continuous Engineering for Industrial Scale Software Systems.
Prof. H. Weber, FraunhoferInstitut fuer Software und Systemtech=
nik ISST,=20
Germany =20
=20
Session: Tool Architecture
* Architecture and Functions of a Commercial Software Reengineering
Workbench (H.M. Sneed D)=20
* Control Flow Normalization for COBOL/CICS Legacy System (Chris=
=20
Verhoef, Alex Sellink, Mark van cen Brand  University of=20
Amsterdam  NL)=20
* Other REF papers will be inserted=20
Session: Data Reengineering
* A Generic Approach for Data Reverse Engineering Taking into=20
Acoount Application Domain Knoledge (Sonia Ayachi Ghannouchi 
ENSI (National School for Computer Studies)  Tunisie)=20
* A strategy for reducing the effort for database schema=20
maintenance (Donatella Castelli  Istituto di Elaborazione
dell'Informazione  I)=20
* Other REF papers will be inserted=20
Session: Business Information Technology
* An Organizational Framework for MassCustomized Business
Application (Petra Ludwig, Thomas Kaufmann, Harald Liessmann =
=20
Bavarian Research Center for KnowledgeBased Systems  D)=20
* Other REF papers will be inserted=20
Session: Year 2000 Problem
* Variable Classification Technique for Software Maintenance and=
=20
Application to The Year 2000 Problem (Keiko Kawabe, Akihiko=20
Matsuo, Sanya Uehara  Fujitsu Laboratories Ltd. JP  Akira=20
Ogawa  Fujitsu Ltd.  JP)=20
* Other REF papers will be inserted=20
Session: Program Understanding
* On Constructing a Tool to Verify Programs for Processors Built=
=20
in Machines (Tomoya Ohta, Norihiro Matsumara, Yukihiro Itoh=
=20
Shizuoka university  JP)=20
* Other REF papers will be inserted=20
Session: Reuse and Object Oriented Techniques
* A DependenceBased Representation for Concurrent ObjectOriented
Software Maintenance (Jianjun Zhao  Fukouka Institute of=20
Technology  Jingde Cheng, Kazuo Ushijima JP)=20
* OOA Metrics for the Unified Modeling Language (Michele Marchesi=
=20
 Universita' di Cagliari  I)=20
* Protection Reconfiguration for Reusable Software (Christian=20
Damsgaarg Jensen  Universite Joseph Fourier  F)=20
Session: System Assessment
* Towards Mature Measurement Program (Frank Niessink, Hans van=20
Vliet  Universiteit Amsterdam NL)=20
* A Tool for Process and Product Assessment of C++ Applications=
=20
(F.Fioravanti, P.Nesi, S. Perlini  Univ Florence  I)=20
* Software Testability Measurement derived from Data Flow Analysis=
=20
(PuLin Yeh, JinCherng Lin Tatung Institute of Technology =
=20
Taiwan)=20
Session: Software Architecture
* Assessing Architectural Complexity (Rick Kazman  Carnege Mellon=
=20
University  USA  Marcus Burth  University of Mannheim  D)=
=20
* Architecture recovery for Software Evolution (Juan C. Duenas,=
=20
William Lopes, Juan A. de la Puente  Universidad Politecnica=
=20
de Madrid  E)=20
* Other REF papers will be inserted=20
Session: Requirements and Specification Evolution
* Requirements Evolution in the Midst of Environmental Change A=
=20
Managed Approach (Wing Lam  University of Hertfordshire  UK)=
=20
* A Method for Assessing Legacy Systems for Evolution (Jane Ransom,
Ian Sommerville, Ian Warren  Lancaster University  UK)=20
* System Specification Reengineering Using the SpecView Tool=20
(Tereza G. Kirner, Rogeria C. Gratao  Federal University of
Sao Carlos  BR)=20
* A Tool Supporting the ReDesign of Legacy Applications (Katja
Cremer  RWTH Aachen D)=20
Session: Maintenance Effort
* Modeling Maintenance Effort by means of Dynamic System=20
(F.Calzolari, G. Antoniol, P. Tonella  IRST  I)=20
* Improving Defect Removal Effectiveness for Software Development=
=20
(Hareton K. N. Leung  The Honk Kong Polytechnic University)=20
* The ExtractTransformRewrite Cycle A Step Towards metaCARE=20
(Bernt Kullbach  University of Koblenz  D)=20
Session: Logic Programming, Telecommunication
* A Metric Suite for Concurrent Logic Programs (Jianjun Zhao =20
Fukouka Institute of Technology  Jingde Cheng, Kazuo Ushijima =
=20
Kyushu University  JP)=20
* Identifying Fault Prone Modules An Empirical Study in=20
Telecommunication System (SungBack Hong, Kapsu Kim  ISDN =20
Call Processing Section, ETRI  KR)=20
Papers in OPEN FORUM Sections
* DBFW A Simple DataBase FrameWork for the Evaluation and=20
Maintenance of Automated Theorem Prover Data (Peter Jakobi,=20
Andreas Wolf  Technische Universitat Munchen D)=20
* Reengineering of Distributed Systems Using Formal Methods=20
(Stephan Kleuker  University of Oldenburg D)=20
* Metricsbased Evaluation of ObjectOriented Software=20
development Methods (Reiner R. Dumke  Erik Foltin =20
University of Magdeburg  D)=20
* Supporting Software evolution using Zones (Cathy Waite, Ray=20
Welland, Malcom Atkinson  University of Glasgow  UK)=20
* RENAISSANCE, A Method To Migrate From Legacy To Immortal
intecs Sistemi S.p.A.  I)=20
* Visualization of Differences between Versions of=20
ObjectOriented Sofware (Jochen Seemann, Jurgen Wolff von=20
Gudenberg  Wurzburg University  D)=20
* Amber Metrics for the Testing & Maintenance of ObjectOriented=
=20
Designs (Jill Doake, Ishbel Duncan  University  UK)=20
* Tailoring the Process Model for Maintanance and Reengineering
(Sara Stoecklin, Deidre Wiliams  Florida Agricoltural &=20
Mechanical University  Peter Stoecklin  PCSA Inc.  USA)=20
* Toward a systematic objectoriented transformation of a Merise=
=20
analysis (Isabelle Borne, Annya Romanczuk, Frederique Stefani =
=20
Ecole des Mines de Nantes  F)=20
* Object Evolution through Model Evolution (Roland T.Mittermeier,=
=20
Helfried Pirker, Dominik Raunerreithmayer  Univeritat =20
Klagenfurt  A)=20
* A sound and Pratical Approach to the ReEngineering of Time=20
Critical System (H.Zedan  H. Yang  De Montfort University  UK)=
=20
* Reengineering a Computerized Numerical Control Towards=20
ObjectOriented (F. Butera, B. Fontanella, P. Nesi, M. Perfetti 
ELEXA S.r.l.  I)=20
* Software Artifacts Reuse and Maintenance An organizational=20
Framework (Claudine Toffolon, Salem Dakhli  ParisDauphine=20
University  F)=20
=20
csmr98 [at] aguirre [dot] ing.unifi.it=20
Dip. Sistemi e Informatica, Universit=E0 degli Studi di Firenze=20
Via S. Marta, 3, 50139 Firenze, Italy=20
Tel: +39554796523, Fax: +39554796363=20
Home Page http://www.dsi.unifi.it/~nesi/csmr98.html=20
=
=20
=20
From ownerreliable_computing Sun Dec 7 23:14:15 1997
Received: by interval.usl.edu id AA10759
(5.65c/IDA1.4.4 for reliable_computingoutgoing); Sun, 7 Dec 1997 15:14:33 0600
Received: from fes3.cs.tin.it (mail.tin.it) by interval.usl.edu with SMTP id AA10753
(5.65c/IDA1.4.4 for ); Sun, 7 Dec 1997 15:14:24 0600
Received: from EUGENIO (Genova626.tin.it [195.31.155.25])
by fes3.cs.tin.it (8.8.4/8.8.4) with SMTP
id WAA17655 for ; Sun, 7 Dec 1997 22:14:15 +0100 (MET)
Date: Sun, 7 Dec 1997 22:14:15 +0100 (MET)
MessageId: <199712072114.WAA17655 [at] fes3 [dot] cs.tin.it>
XSender: bizet [at] freenet [dot] hut.fi
XMailer: Windows Eudora Light Version 1.5.2
MimeVersion: 1.0
ContentType: text/plain; charset="usascii"
To: reliable_computing [at] interval [dot] usl.edu
From: Federico Bizzarri
Subject: Installing PROFIL\BIAS
Sender: ownerreliable_computing
Precedence: bulk
Dear Sir,
I'm studying electronic engineering at the university of GenoaItaly. I'm
developing my thesis about interval analysis.
I'm interested in using PROFIL\BIAS library either on my PC (Intel 486DX 33
MHz O.S.=DOS, Borland C++ 3.1) or a workstation (DITAL ALPHA DEC 3000 with gcc).
I have found a lot of problems as:
1 I can't find a DMAKE utility working on my PC.
2 Using bcc make and link I'm not able to write a complete makefile
3 My workstation is not forseen to be used with this library.
If you have found these problems using PROFIL\BIAS and you solved them, I
will be very glad if you could informe me (for example sending me a makefile
or the modifications to use the library with the workstation).
Thank for your help, byebye.
Federico Bizzarri
GenovaITALY
Per Omnia Asperrima.
Have a nice day!
From ownerreliable_computing Sun Dec 7 23:32:21 1997
Received: by interval.usl.edu id AA11500
(5.65c/IDA1.4.4 for reliable_computingoutgoing); Tue, 9 Dec 1997 01:24:38 0600
Received: from Pap.UniVie.AC.AT (apap4.pap.univie.ac.at) by interval.usl.edu with SMTP id AA11494
(5.65c/IDA1.4.4 for ); Tue, 9 Dec 1997 01:24:29 0600
Received: from homer.cma.univie.ac.at by Pap.UniVie.AC.AT (PMDF V5.04 #10670)
id <01IQYOYPTC8W8WY62Q [at] Pap [dot] UniVie.AC.AT>; Tue, 09 Dec 1997 08:21:33 +0100 (MET)
Received: by homer.cma.univie.ac.at (5.65v3.2/1.1.10.5/19Mar971148AM)
id AA05777; Sun, 07 Dec 1997 22:32:21 +0100
Date: Sun, 07 Dec 1997 22:32:21 +0100
From: Arnold Neumaier
Subject: Re: Installing PROFIL\BIAS
To: bizet [at] freenet [dot] hut.fi, reliable_computing [at] interval [dot] usl.edu
Cc: neum [at] homer [dot] cma.univie.ac.at
MessageId: <9712072132.AA05777 [at] homer [dot] cma.univie.ac.at>
ContentTransferEncoding: 7BIT
Sender: ownerreliable_computing
Precedence: bulk
We couldn't install PROFIL\BIAS on our DEC Alphas because the package
is not suited for 32 bit addressing. I had contacted Dr. Knueppel
about this and he said one needs to do some very lowlevel machine code
programming, which we don't know how to do.
There were also problems with installing PROFIL\BIAS on our PC's,
which I don't remember. But probably you can get help with the
PC version from Dr. Knueppel (knueppel@tuharburg.d400.de).
If you know how to do it, please tell me.
Sorry for this negative answer.
Arnold Neumaier
From ownerreliable_computing Tue Dec 9 04:25:19 1997
Received: by interval.usl.edu id AA12118
(5.65c/IDA1.4.4 for reliable_computingoutgoing); Tue, 9 Dec 1997 12:27:03 0600
Received: from cs.utep.edu by interval.usl.edu with SMTP id AA12112
(5.65c/IDA1.4.4 for ); Tue, 9 Dec 1997 12:26:15 0600
Received: from earth.cs.utep.edu by cs.utep.edu (4.1/SMI4.1)
id AA07342; Tue, 9 Dec 97 11:25:19 MST
Date: Tue, 9 Dec 97 11:25:19 MST
From: vladik [at] cs [dot] utep.edu (Vladik Kreinovich)
MessageId: <9712091825.AA07342 [at] cs [dot] utep.edu>
To: reliable_computing [at] interval [dot] usl.edu
Subject: we are in the new ACM classification scheme
Sender: ownerreliable_computing
Precedence: bulk
December 9, 1997
Dear Colleagues,
The new ACM Subject Classification has been officially released.
It is available at http://www.acm.org/class (this URL contains
this new scheme and the previous ones).
As you may remember, in 1996, ACM announced the plans to update
their classification system, and asked for suggestions.
Their previous classification (1991, minor revision 1995) did not
mention interval computations at all, so we suggested that they
should at least mention interval computations (several researchers
proposed more detailed additions).
In response to our suggestions, interval arithmetic
is now explicitly mentioned in Section G.1.0 of the new
classification.
I think this recognition of our research area reflects its growing
importance (and, hopefully, it is only a start!).
Thanks a lot to everyone who helped to make this change happen.
Yours
Vladik
From ownerreliable_computing Wed Dec 17 11:02:19 1997
Received: by interval.usl.edu id AA15538
(5.65c/IDA1.4.4 for reliable_computingoutgoing); Wed, 17 Dec 1997 21:03:14 0600
Received: from mercury.Sun.COM by interval.usl.edu with SMTP id AA15532
(5.65c/IDA1.4.4 for ); Wed, 17 Dec 1997 21:03:11 0600
Received: from Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (SMI8.6/mail.byaddr) with SMTP id TAA19516 for ; Wed, 17 Dec 1997 19:03:08 0800
Received: from thestork (thestork.Eng.Sun.COM [129.146.88.47])
by Eng.Sun.COM (SMI8.6/SMI5.3) with ESMTP id TAA25105
for ; Wed, 17 Dec 1997 19:03:04 0800
Received: from math (math.Eng.Sun.COM)
by thestork.eng.sun.com (Sun Internet Mail Server sims.3.2.1997.12.17.10.37)
with SMTP id <0ELD003CW75BQ0 [at] thestork [dot] eng.sun.com> for
reliable_computing [at] interval [dot] usl.edu; Wed, 17 Dec 1997 19:03:12 0800 (PST)
Date: Wed, 17 Dec 1997 19:02:19 0800 (PST)
From: Dmitri Shiriaev
Subject: Questions about Expectations about Interval Exceptions
To: reliable_computing [at] interval [dot] usl.edu
Cc: interval_all [at] gww [dot] eng.sun.com
ReplyTo: Dmitri Shiriaev
MessageId:
MimeVersion: 1.0
XMailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4u sparc
ContentType: TEXT/plain; charset=usascii
ContentMd5: MZEqP4X8E0n1dcG1lJqqIA==
Sender: ownerreliable_computing
Precedence: bulk
Hi Everybody,
I think this issue can be interesting to many people on
the list.
Regards
Dmitri
 Begin Forwarded Message 
Date: Wed, 17 Dec 1997 17:33:31 0800
From: validgh [at] validgh [dot] com (David G Hough at validgh)
Subject: Questions about Expectations about Interval Exceptions
To: numericinterest [at] validgh [dot] com
I'm curious about the programs that have been written to exploit various
systems of interval arithmetic  what expectations about exceptional cases
were built into these programs? The context is an attempt to extend the non
stop exception handling policy of IEEE 754 point arithmetic to intervals with
IEEE 754 endpoints.
One point of view is that existing programs typically rely on exception
handling working in certain ways, and another is that existing programs are
typically coded defensively to avoid depending on specific exception handling.
Although interval arithmetic programs are hardly portable in the usual sense
because there are no language standards for expressing them, one would not
like to gratuitously invalidate the logic embodied in existing programs if a
consensus practice were discernible.
In IEEE 754 point arithmetic, by default invalid exceptions like 0/0 and
sqrt(1) produce NaN  Not a Number  and execution proceeds. Status flags
are also set, that can be interrogated within the program, and in addition, in
most implementations the programmer can specify that certain exceptions ter
minate execution. The methods of interrogating flags and enabling termina
tions were not standardized by languages until recently, and that's one of the
reasons that nonstop exception handling was specified as default in IEEE 754
twenty years ago. Although it was and is usually a good idea to avoid 0/0
and sqrt(1), IEEE 754 takes pains to minimize the chance that such exceptions
would produce invalid results that look valid.
A particular IEEE 754 point NaN result might be thought about in various
ways  as an Error, as an Empty set (no such number exists), as some unknown
or nonunique real number among all the real numbers (R) or among all the real
numbers extended by affine +inf and inf (R*), or as some unknown or non
unique complex number among all the complex numbers (C) or among all the com
plex numbers extended by projective inf (C*). Which interpretation makes
sense in a particular situation depends on the larger context and is not known
to the arithmetic. In many cases these different interpretations logically
propagate the same way, so the distinctions seldom matter.
Note that the Empty set, R, R*, C, C* are all intervals, and so, in
interval arithmetic, their propagation is not the same, and it begins to
matter which is chosen as the default result for each specific exception.
Even in real interval arithmetic, special representations could be constructed
for R*, C, or C*, if that were deemed useful.
Thus, cases could be made to interpret the default real interval result
for 0/0 or [0,0]/[0,0] as
Error = NaI = Not an Interval
because 0/0 might be thought of as an error,
Empty because there isn't a real number defined to be the result of 0/0,
R because any real number z satisfies 0 * z = 0.
Considering a more elaborate case, [0,1]/[0,1], which might be thought of
as containing 0/0, one could plausibly argue for any of the foregoing, and in
addition
R* or more tightly (inf, +inf], because in addition to R for 0/0, 1/0 =
+inf should be included,
[0,+inf]
because since [0,1] contains no negative numbers, the ratio [0,1]/[0,1]
should contain no negative numbers.
As a third example, consider sqrt([1,d]) for 0 < d << 1. In this case
the interval is mostly negative but has some positive numbers. Plausible
arguments might be made for
Error = NaI = Not an Interval
because sqrt(1) might be thought of as an error,
Empty because there isn't a real number defined to be the result of sqrt(1),
[0,sqrt(d)]
because sqrt is only defined over real operands and operands outside its
domain can be ignored  since in a valid interval program, negative
operands to sqrt can only arise due to roundoff or due to untight inter
val expression evaluations of expressions that should be nonnegative,
either of which can be ignored,
C because the complex numbers include all the possible results of sqrt of
negative intervals  in a real interval system, it is not possible to
represent the union of [0,sqrt(d)] and [0,1]*i, but a special representa
tion for C would at least contain that union.
My purpose in this note is NOT to argue about which of these various
choices is the "correct" nonstop default choice  that is a complicated issue
which has been argued from many different directions, as I've tried to indi
cate above. My purpose is to inquire whether the plethora of contradictory
arguments I've hinted at, plus the possibility that existing implementations
1) might silently return incorrect results, or 2) might abruptly and uncondi
tionally terminate in the event of any of these exceptions, have had the
effect that most existing substantial interval application programs have been
written to avoid these situations entirely.
So persons who have written such programs are welcome to comment to this
mailing list. Did you try to stay within the real domain by programming
techniques such as 
1) removing zero points from interval divisors, in order to handle them spe
cially, and so avoid division by intervals containing zero,
2) avoiding sqrt(1), log(1), asin(2), and the like, by proving analyti
cally that interval operands to such functions would always be valid, or
by explicitly discarding (and thus ignoring) outofdomain parts of
interval operands to such functions?
Or did you rely on specific exception handling behavior in the implemen
tations you programmed for? Even more interesting would be cases, if any
exist, of programming intended to be "portable" in some sense across different
styles of interval implementations.
 End Forwarded Message 
From ownerreliable_computing Wed Dec 17 12:04:25 1997
Received: by interval.usl.edu id AA15889
(5.65c/IDA1.4.4 for reliable_computingoutgoing); Wed, 17 Dec 1997 22:07:13 0600
Received: from mercury.Sun.COM by interval.usl.edu with SMTP id AA15883
(5.65c/IDA1.4.4 for ); Wed, 17 Dec 1997 22:07:11 0600
Received: from Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (SMI8.6/mail.byaddr) with SMTP id UAA24490; Wed, 17 Dec 1997 20:04:41 0800
Received: from kindra.eng.sun.com (kindra.Eng.Sun.COM [129.146.77.35])
by Eng.Sun.COM (SMI8.6/SMI5.3) with SMTP id UAA02111;
Wed, 17 Dec 1997 20:04:38 0800
Received: from gww.eng.sun.com by kindra.eng.sun.com (SMI8.6/SMISVR4)
id UAA06465; Wed, 17 Dec 1997 20:04:24 0800
Received: by gww.eng.sun.com (SMI8.6/SMISVR4)
id UAA09233; Wed, 17 Dec 1997 20:04:25 0800
Date: Wed, 17 Dec 1997 20:04:25 0800
From: walster [at] kindra [dot] eng.sun.com (gww)
MessageId: <199712180404.UAA09233 [at] gww [dot] eng.sun.com>
To: reliable_computing [at] interval [dot] usl.edu, Dmitri.Chiriaev [at] eng [dot] sun.com
Subject: Re: Questions about Expectations about Interval Exceptions
Cc: interval_all [at] gww [dot] eng.sun.com
XSunCharset: USASCII
Sender: ownerreliable_computing
Precedence: bulk
In particular, it may be helpful to take a look at the paper
"Extended Real Interval System" and the proposed interval Fortran
specification which can be found at:
http://www.mscs.mu.edu/~globsol/
under Walster's papers.
Comments and suggestions are welcome.
Regards,
Bill
>From dmitri.chiriaev@Eng Wed Dec 17 19:03:20 1997
>Date: Wed, 17 Dec 1997 19:02:19 0800 (PST)
>From: Dmitri Shiriaev
>Subject: Questions about Expectations about Interval Exceptions
>To: reliable_computing [at] interval [dot] usl.edu
>Cc: interval_all [at] gww [dot] eng.sun.com
>MIMEversion: 1.0
>ContentMD5: MZEqP4X8E0n1dcG1lJqqIA==
>
>Hi Everybody,
>
>I think this issue can be interesting to many people on
>the list.
>
>
>Regards
>Dmitri
> Begin Forwarded Message 
>
>Date: Wed, 17 Dec 1997 17:33:31 0800
>From: validgh [at] validgh [dot] com (David G Hough at validgh)
>Subject: Questions about Expectations about Interval Exceptions
>To: numericinterest [at] validgh [dot] com
>
>
> I'm curious about the programs that have been written to exploit various
>systems of interval arithmetic  what expectations about exceptional cases
>were built into these programs? The context is an attempt to extend the non
>stop exception handling policy of IEEE 754 point arithmetic to intervals with
>IEEE 754 endpoints.
>
> One point of view is that existing programs typically rely on exception
>handling working in certain ways, and another is that existing programs are
>typically coded defensively to avoid depending on specific exception handling.
>Although interval arithmetic programs are hardly portable in the usual sense
>because there are no language standards for expressing them, one would not
>like to gratuitously invalidate the logic embodied in existing programs if a
>consensus practice were discernible.
>
> In IEEE 754 point arithmetic, by default invalid exceptions like 0/0 and
>sqrt(1) produce NaN  Not a Number  and execution proceeds. Status flags
>are also set, that can be interrogated within the program, and in addition, in
>most implementations the programmer can specify that certain exceptions ter
>minate execution. The methods of interrogating flags and enabling termina
>tions were not standardized by languages until recently, and that's one of the
>reasons that nonstop exception handling was specified as default in IEEE 754
>twenty years ago. Although it was and is usually a good idea to avoid 0/0
>and sqrt(1), IEEE 754 takes pains to minimize the chance that such exceptions
>would produce invalid results that look valid.
>
> A particular IEEE 754 point NaN result might be thought about in various
>ways  as an Error, as an Empty set (no such number exists), as some unknown
>or nonunique real number among all the real numbers (R) or among all the real
>numbers extended by affine +inf and inf (R*), or as some unknown or non
>unique complex number among all the complex numbers (C) or among all the com
>plex numbers extended by projective inf (C*). Which interpretation makes
>sense in a particular situation depends on the larger context and is not known
>to the arithmetic. In many cases these different interpretations logically
>propagate the same way, so the distinctions seldom matter.
>
> Note that the Empty set, R, R*, C, C* are all intervals, and so, in
>interval arithmetic, their propagation is not the same, and it begins to
>matter which is chosen as the default result for each specific exception.
>Even in real interval arithmetic, special representations could be constructed
>for R*, C, or C*, if that were deemed useful.
>
> Thus, cases could be made to interpret the default real interval result
>for 0/0 or [0,0]/[0,0] as
>
>Error = NaI = Not an Interval
> because 0/0 might be thought of as an error,
>
>Empty because there isn't a real number defined to be the result of 0/0,
>
>R because any real number z satisfies 0 * z = 0.
>
> Considering a more elaborate case, [0,1]/[0,1], which might be thought of
>as containing 0/0, one could plausibly argue for any of the foregoing, and in
>addition
>
>R* or more tightly (inf, +inf], because in addition to R for 0/0, 1/0 =
> +inf should be included,
>
>[0,+inf]
> because since [0,1] contains no negative numbers, the ratio [0,1]/[0,1]
> should contain no negative numbers.
>
> As a third example, consider sqrt([1,d]) for 0 < d << 1. In this case
>the interval is mostly negative but has some positive numbers. Plausible
>arguments might be made for
>
>Error = NaI = Not an Interval
> because sqrt(1) might be thought of as an error,
>
>Empty because there isn't a real number defined to be the result of sqrt(1),
>
>[0,sqrt(d)]
> because sqrt is only defined over real operands and operands outside its
> domain can be ignored  since in a valid interval program, negative
> operands to sqrt can only arise due to roundoff or due to untight inter
> val expression evaluations of expressions that should be nonnegative,
> either of which can be ignored,
>
>C because the complex numbers include all the possible results of sqrt of
> negative intervals  in a real interval system, it is not possible to
> represent the union of [0,sqrt(d)] and [0,1]*i, but a special representa
> tion for C would at least contain that union.
>
> My purpose in this note is NOT to argue about which of these various
>choices is the "correct" nonstop default choice  that is a complicated issue
>which has been argued from many different directions, as I've tried to indi
>cate above. My purpose is to inquire whether the plethora of contradictory
>arguments I've hinted at, plus the possibility that existing implementations
>1) might silently return incorrect results, or 2) might abruptly and uncondi
>tionally terminate in the event of any of these exceptions, have had the
>effect that most existing substantial interval application programs have been
>written to avoid these situations entirely.
>
> So persons who have written such programs are welcome to comment to this
>mailing list. Did you try to stay within the real domain by programming
>techniques such as 
>
>1) removing zero points from interval divisors, in order to handle them spe
> cially, and so avoid division by intervals containing zero,
>
>2) avoiding sqrt(1), log(1), asin(2), and the like, by proving analyti
> cally that interval operands to such functions would always be valid, or
> by explicitly discarding (and thus ignoring) outofdomain parts of
> interval operands to such functions?
>
> Or did you rely on specific exception handling behavior in the implemen
>tations you programmed for? Even more interesting would be cases, if any
>exist, of programming intended to be "portable" in some sense across different
>styles of interval implementations.
>
>
>
> End Forwarded Message 
>
>
>
>
From ownerreliable_computing Thu Dec 18 14:06:20 1997
Received: by interval.usl.edu id AA16544
(5.65c/IDA1.4.4 for reliable_computingoutgoing); Thu, 18 Dec 1997 18:06:44 0600
Received: from yonge.cs.toronto.edu by interval.usl.edu with SMTP id AA16538
(5.65c/IDA1.4.4 for ); Thu, 18 Dec 1997 18:06:35 0600
Received: from dvp.cs.toronto.edu ([128.100.1.15]) by yonge.cs.toronto.edu with SMTP id <8652228772>; Thu, 18 Dec 1997 19:06:27 0500
Received: by dvp.cs.toronto.edu id <15546437>; Thu, 18 Dec 1997 19:06:24 0500
From: Jeff Tupper
To: reliable_computing [at] interval [dot] usl.edu
Subject: Re: Questions about Expectations about Interval Exceptions
ContentLength: 5959
MessageId: <97Dec18.190624edt.15546437 [at] dvp [dot] cs.toronto.edu>
Date: Thu, 18 Dec 1997 19:06:20 0500
Sender: ownerreliable_computing
Precedence: bulk
I certainly agree that it is important to correctly handle "exceptional" cases
with interval arithmetic. I might look at it a little differently, since I
think of interval arithmetic as a mathematical tool as well as a scientific
tool. As such, I am quite interested in things like "sqrt(1)", and don't
immediately jump to the conclusion that such things are errors and that my
program needs to be changed or that there is invalid input. I will show how I
handle the examples brought up.
Example 1. <0,0> / <0,0> => undefined
I use angle brackets (approximated by "<" and ">" with ASCII) for intervals
since I think they are distinct from sets of (extended) real numbers, and
moreover I don't wish to imply that positive infinity is included in "[0,inf]".
I can expand example 1 above as follows:
, domain > / , domain >
=> >
where
, domain >
means that the value is bounded between A and B and that the validity
of the result is bounded between C and D, as follows:
means that the result is not valid
(the current set of mathematical rules do not define a result)
(the value bounds are inconsequental in this case)
means that the result is valid
(the current set of mathematical rules do provide a result,
which is bounded by the value bounds)
means that the result may or may not be valid
(typically, some of the values in the argument bounds fall
within the current set of mathematical rules, some do not)
if the result is valid, it is bounded by the value bounds
So, with division by 0, I would normally flag it as being outside the domain
of realnumbered mathematics. In implementations of division, I have not
used any IEEE 754 exception handling, as "exceptions" may not occur while
computing bounds on the results, but there nevertheless would be "exceptions".
An example would be <1,1> / <1,1>.
Example 2.
, domain > / , domain >
=> , domain >
Here you can see use of as a domain bound.
Example 3.
sqrt( , domain > )
=> , domain >
This is similar to example 2.
Example 4.
sqrt( , domain > )
=> >
Here is my own example which produces a domain bound.
> My purpose in this note is NOT to argue about which of these various
>choices is the "correct" nonstop default choice  that is a complicated issue
>which has been argued from many different directions, as I've tried to indi
>cate above. My purpose is to inquire whether the plethora of contradictory
I'm not sure if it is necessary to dictate the "correct" behaviour of interval
systems when confronted with "exceptional" cases. If the interval system can
flag such cases and maintain enough information about them, the ultimate
behaviour may well be decided by a higher level of the ultimate system.
One example program using my system is GrafEq (http://www.peda.com/grafeq/)
which some interval researchers have found interesting (there is a new version
coming, which will be much more accessible to exploration by the interval
community  I will post something when it is ready). It graphs relations
of interest to high school math students/teachers, and as such, should graph
things like y So persons who have written such programs are welcome to comment to this
>mailing list. Did you try to stay within the real domain by programming
>techniques such as 
>
>1) removing zero points from interval divisors, in order to handle them spe
> cially, and so avoid division by intervals containing zero,
No, (GrafEq and other research programs I have worked on) do not remove
zero points from internal divisors.
>2) avoiding sqrt(1), log(1), asin(2), and the like, by proving analyti
> cally that interval operands to such functions would always be valid, or
> by explicitly discarding (and thus ignoring) outofdomain parts of
> interval operands to such functions?
No  I want most of my programs to be able to handle arbitrary inputs.
(which I think is part of the distinction between mathematical software
and scientific software)
If one aims to always avoid such cases with analytic techniques, then it seems
to me that the person prefers symbolic methods, and I would want to know why
the person is using intervals at all.
> Or did you rely on specific exception handling behavior in the implemen
>tations you programmed for? Even more interesting would be cases, if any
>exist, of programming intended to be "portable" in some sense across different
>styles of interval implementations.
Most of the interval software I have worked on works on a variety of platforms:
680x0 mac, power mac, windows (386 through Pentium II), SGI (some older and
newer platforms), as well as linux (x86) and Sun (a variety of SPARC platforms).
The vast majority of portability problems had nothing to do with intervals,
floatingpoint formats, roundingmode controls, or other IEEE 754 features.
Something you haven't mentioned explicitly is other forms of assumptions that
may or may not hold. An example is continuity  my software often wants to know
if the computed result is continuous (at a point, or over a region). I handle
such information in the same way...
Example 5a.
floor(, continuous >)
=> , continuous >
Example 5b.
floor(, continuous >)
=> , continuous >
If anyone is interested in reading a bit more about this my M.Sc. thesis is
online at http://www.dgp.toronto.edu/people/mooncake/msc.html. I also discuss
a little about how I try to improve the efficiency and power of interval
methods by allowing variables in the value/domain/continuity bounds.
Jeff
From ownerreliable_computing Thu Dec 18 09:58:22 1997
Received: by interval.usl.edu id AA17080
(5.65c/IDA1.4.4 for reliable_computingoutgoing); Fri, 19 Dec 1997 04:38:39 0600
Received: from Pap.UniVie.AC.AT (apap4.pap.univie.ac.at) by interval.usl.edu with SMTP id AA17074
(5.65c/IDA1.4.4 for ); Fri, 19 Dec 1997 04:38:33 0600
Received: from homer.cma.univie.ac.at by Pap.UniVie.AC.AT (PMDF V5.04 #10670)
id <01IRCU77O89C8WZO3J [at] Pap [dot] UniVie.AC.AT>; Fri, 19 Dec 1997 11:22:22 +0100 (MET)
Received: by homer.cma.univie.ac.at (5.65v3.2/1.1.10.5/19Mar971148AM)
id AA17881; Thu, 18 Dec 1997 08:58:22 +0100
Date: Thu, 18 Dec 1997 08:58:22 +0100
From: Arnold Neumaier
Subject: Re: Questions about Expectations about Interval Exceptions
To: Dmitri.Chiriaev [at] eng [dot] sun.com, reliable_computing [at] interval [dot] usl.edu
Cc: interval_all [at] gww [dot] eng.sun.com, validgh [at] validgh [dot] com
MessageId: <9712180758.AA17881 [at] homer [dot] cma.univie.ac.at>
ContentTransferEncoding: 7BIT
Sender: ownerreliable_computing
Precedence: bulk
For global optimization, it is assumed that all relations specified by
the user are finite and valid at the solution.
This implies that the right definitions
for inverse operations must yield the range of numbers that could be
possibly solutions of the respective imlicit equation. Thus
0/0=R
1/0=empty
[0,1]/[0,1]=R
[1,2]/[0,1]=[1,inf[
sqrt([1,4])=[0,2]
etc. Since global optimization applications will be among the
most important ones, this is an exception handling mode that
m u s t be supported, and it is unambiguous for all operations.
Thus I suggest that it is the default mode.
On the other hand, since there are other applications where
alternative rules are relevant, one might want to give the user a choice
on overruling the default mode by a compiler option, or something like it.
Arnold Neumaier
From ownerreliable_computing Sat Dec 20 13:48:28 1997
Received: by interval.usl.edu id AA18055
(5.65c/IDA1.4.4 for reliable_computingoutgoing); Sat, 20 Dec 1997 21:48:35 0600
Received: from cs.utep.edu by interval.usl.edu with SMTP id AA18049
(5.65c/IDA1.4.4 for ); Sat, 20 Dec 1997 21:48:32 0600
Received: from earth.cs.utep.edu by cs.utep.edu (4.1/SMI4.1)
id AA02903; Sat, 20 Dec 97 20:48:29 MST
Date: Sat, 20 Dec 97 20:48:28 MST
From: vladik [at] cs [dot] utep.edu (Vladik Kreinovich)
MessageId: <9712210348.AA02903 [at] cs [dot] utep.edu>
To: reliable_computing [at] interval [dot] usl.edu
Subject: Reliable Computing journal: opportunity
Cc: interval [at] cs [dot] utep.edu
Sender: ownerreliable_computing
Precedence: bulk
Dear Friends,
As you probably already know, the next student issue of Reliable
Computing (No. 1, 1998) is ready, it will be soon sent to the
subscribers. Guenter Mayer and I, coeditors of special student issues,
want to once again thank all the authors and referees, and to encourage new
student authors to submit high quality papers for the next (1999) issue.
I have just been in email correspondence with Slava Nesterov, the
editorinchief of our Relibale Computing journal, about the scheduling
of the next 1999 student issue, and he has sent me the following
information that may be of interest not only to the student authors,
but also to other potential authors:
* for 1999 several topical issues and conferenceproceeding issues
(including Interval'98) are already scheduled,
* while in 1998, it looks like issues 2, 3, and 4 will be regular ones.
Currently, there is practically no backlog in our journal:
once accepted, most papers are published in the nearest regular issue.
This means that 1998 is a window of opportunity for fast publication:
if you send a paper in soon, and it goes through the refereeing process
(and is accepted) fast, it has a good chance to be published already in
1998.
So if you have a good quality paper related to interval computations
and other topics of interest to the journal, please consider sending
your paper to Slava ASAP.
For detailed information on the journal, please visit the interval
computations website http://cs.utep.edu/intervalcomp/main.html click
on journal; this page contains the list of all papers published in RC +
a link to the Kluwer's page that has current editorial board,
addresses, and stylefiles (plain LaTeX is also OK).
Good luck and Happy New Year to you all!
Vladik
From ownerreliable_computing Tue Dec 23 06:57:29 1997
Received: by interval.usl.edu id AA19500
(5.65c/IDA1.4.4 for reliable_computingoutgoing); Tue, 23 Dec 1997 14:57:40 0600
Received: from cs.utep.edu by interval.usl.edu with SMTP id AA19494
(5.65c/IDA1.4.4 for ); Tue, 23 Dec 1997 14:57:33 0600
Received: from earth.cs.utep.edu by cs.utep.edu (4.1/SMI4.1)
id AA12401; Tue, 23 Dec 97 13:57:30 MST
Date: Tue, 23 Dec 97 13:57:29 MST
From: vladik [at] cs [dot] utep.edu (Vladik Kreinovich)
MessageId: <9712232057.AA12401 [at] cs [dot] utep.edu>
To: reliable_computing [at] interval [dot] usl.edu
Subject: CFP
Sender: ownerreliable_computing
Precedence: bulk
Date: Tue, 23 Dec 1997 13:40:12 +0100
From: Xizhong.Zheng@FernUniHagen.de (Xizhong Zheng)
ANNOUNCEMENT AND CALL FOR PAPERS
CCA'98Third Workshop on Computability and Complexity in Analysis
A Satellite Workshop to MFCS'98
August 2427, 1998, Brno, Czech Republic
The aim of this annual workshop is to bring again together those people interested in computability and complexity aspects of analysis, and to present the results and research aims in the area to a broader audience in the MFCS/CSL environment.
The topics includes all aspects of computability and computational complexity in analysis with emphasis on the Turing machine model of computation.
Authors are invited to send one copy of an extended abstract not exceeding ten pages to the Contact person. Electronic submissions in a form of postscript file are encouraged and can be sent to
klaus.weihrauch@fernunihagen.de.
Submissions must be received by May 25, 1998. Authors will be notified of acceptance by June 15, 1998. Double submission to MFCS'98 are allowed. It is expected that every accepted paper will be presented at the workshop by one of the authors.
A preliminary proceedings in the form of a technical report will be available at the workshop. The final version for it should be sent before August 1, 1998. Whether there will be another final form of the proceedings will be decided later.
The workshop will be organized at the same place as the federated MFCS'98/CSL'98 conference and care will be taken that participants of the workshop can attend invited talks of MFCS/CSL conferences.
No special registration fee will be required for participants who also register for the MFCS'98 or CSL'98 conference. A registration only for the workshop will be also possibleexpenses for fee, accommodation, and basic meals will be very modest.
Program Committee:
KerI Ko State University of New York (USA)
keriko [at] cs [dot] sunysb.edu
Anil Nerode Cornell University (USA)
anil [at] math [dot] cornell.edu
Marian PourEl University of Minnesota (USA)
pourel [at] math [dot] umn.edu
Klaus Weihrauch Fernuniversit\"at Hagen (D)
klaus.weihrauch@fernunihagen.de
Jiri Wiedermann Academy of Science of the Czech Republic (CZ)
wieder [at] uivt [dot] cas.cz
Contact Person:
Klaus Weihrauch
Theoretische Informatik I,
FernUniversit\"at Hagen
D58084, Hagen
Germany
klaus.weihrauch@fernunihagen.de
tel: ++4923319872722
fax: ++492331987316}
Important Dates:
submission: May 25, 1998
notification: July 15, 1998
final version: August 1, 1998
Further Information: http://www.informatik.fernunihagen.de/cca/
 End Included Message 
From ownerreliable_computing Mon Dec 29 15:25:27 1997
Received: by interval.usl.edu id AA21347
(5.65c/IDA1.4.4 for reliable_computingoutgoing); Mon, 29 Dec 1997 07:25:49 0600
Received: from animal.cs.chalmers.se by interval.usl.edu with SMTP id AA21341
(5.65c/IDA1.4.4 for ); Mon, 29 Dec 1997 07:25:40 0600
Received: (from johanj@localhost)
by animal.cs.chalmers.se (8.8.5/8.8.5) id OAA07413
for reliable_computing [at] interval [dot] usl.edu; Mon, 29 Dec 1997 14:25:27 +0100 (MET)
Date: Mon, 29 Dec 1997 14:25:27 +0100 (MET)
From: Johan Jeuring
MessageId: <199712291325.OAA07413 [at] animal [dot] cs.chalmers.se>
To: reliable_computing [at] interval [dot] usl.edu
Subject: 2nd cfp: Workshop on Generic Programming 98
Sender: ownerreliable_computing
Precedence: bulk
Call for Papers
Workshop on Generic Programming
June 18th 1998, Marstrand, Sweden
(In Conjunction with Mathematics of Program Construction Conference)
http://www.cse.ogi.edu/PacSoft/conf/wgp/
Generic programming is about making programs more adaptable by making them more
general. A generic program embodies some sort of polymorphism; ordinary
programs are obtained from it by suitably instantiating its parameters. The
parameters may be other programs, types or type constructors, or even
programming paradigms.
Generic programming techniques have always been of interest, both to
practitioners and theoreticians, but to date have rarely been a specific
focus of research. Recent developments in functional and
objectoriented programming lead the organizers of this workshop to believe
that there is sufficient interest to warrant the organisation of a oneday
workshop on the theme of generic programming. The workshop will be on
June 18th, 1998, following on from the Mathematics of Program Construction
conference.
The goal of the workshop is to inventorise the full diversity of research
activities in the area of generic programming, both theoretical and applied,
by attracting as wide a spectrum of participants as possible to the workshop.
The results of the workshop will be published in the form of a detailed summary
of all presentations, prepared by the organizers and made available on
internet.
We cordially invite all those with an active interest in this important new
area to submit a short position paper on their work to Roland Backhouse
(rolandb [at] win [dot] tue.nl). The position paper should outline your current research
activities in this area and include references to published papers and/or
web links to technical reports where more information can be found.
The recommended length is approximately three pages. The
deadline for submission is 16th February, 1998. Notification of acceptance
will be on or before 15th March, 1998.
The organizers are as follows:
Roland Backhouse (Cochair), Netherlands Tim Sheard (Cochair), USA
Robin Cockett, Canada Barry Jay, Australia
Johan Jeuring, Sweden Karl Lieberherr, USA
Oege de Moor, UK Bernhard Moeller, Germany
Jose Oliveira, Portugal Fritz Ruehr, USA
For further details on the Mathematics of Program Construction and this
workshop please consult:
http://www.md.chalmers.se/Conf/MPC98/
From ownerreliable_computing Tue Dec 30 07:36:36 1997
Received: by interval.usl.edu id AA22028
(5.65c/IDA1.4.4 for reliable_computingoutgoing); Tue, 30 Dec 1997 15:36:43 0600
Received: from cs.utep.edu by interval.usl.edu with SMTP id AA22022
(5.65c/IDA1.4.4 for ); Tue, 30 Dec 1997 15:36:40 0600
Received: from earth.cs.utep.edu by cs.utep.edu (4.1/SMI4.1)
id AA00807; Tue, 30 Dec 97 14:36:36 MST
Date: Tue, 30 Dec 97 14:36:36 MST
From: vladik [at] cs [dot] utep.edu (Vladik Kreinovich)
MessageId: <9712302136.AA00807 [at] cs [dot] utep.edu>
To: reliable_computing [at] interval [dot] usl.edu
Subject: Postdoc position
Sender: ownerreliable_computing
Precedence: bulk
From: Matthew James
I am looking for a postdoc to begin as soon as possible in 1998.
Please pass on this notice to anyone you think would be interested
and suitable.
Thanks,
Matt
*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.**
Contributed by: Matt James (Matthew.James [at] anu [dot] edu.au)
POSTDOCTORAL POSITION
Department of Engineering
Australian National University
Nonlinear Robust Control
A postdoctoral Research Associate position will be available for a period
of one year with the possibility of extension to two years starting as soon
as possible in 1998. The aim of the project is to develop design and
analysis methodologies for robust output feedback controllers for nonlinear
systems. The range of topics includes nonlinear 'Hinfinity', information
states, infinite dimensional dynamics and PDEs, stochastic risksensitive
control, approximation and numerical techniques.
Applicants should have recently completed a PhD in control or related
engineering/mathematical area. A strong background in mathematics
and control is required.
Please send applications (vita, names of at least two referees, a selection
of publications) to:
Dr Matthew R. James
Department of Engineering
Faculty of Engineering and Information Technology
Australian National University
Canberra 0200 AUSTRALIA
Phone: +61 2 6249 4889
Mobile: +61 0418442543
Fax: +61 2 6249 0506
Email: Matthew.James [at] anu [dot] edu.au
WWW: http://spigot.anu.edu.au/people/mat/home.html
*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.**
 End Included Message 
From ownerreliable_computing Wed Dec 31 03:38:18 1997
Received: by interval.usl.edu id AA22624
(5.65c/IDA1.4.4 for reliable_computingoutgoing); Wed, 31 Dec 1997 09:46:02 0600
Received: from engr.uark.edu (engr.engr.uark.edu) by interval.usl.edu with SMTP id AA22618
(5.65c/IDA1.4.4 for ); Wed, 31 Dec 1997 09:45:54 0600
Received: (qmail 28191 invoked from network); 31 Dec 1997 15:45:49 0000
Received: from dberleant.engr.uark.edu (HELO engr.uark.edu) (130.184.163.61)
by engr.engr.uark.edu with SMTP; 31 Dec 1997 15:45:49 0000
Received: (qmail 17274 invoked by uid 336); 31 Dec 1997 15:38:19 0000
MessageId: <19971231153819.17273.qmail [at] engr [dot] uark.edu>
From: djb [at] engr [dot] uark.edu (BERLEANT DANIEL J)
Date: Wed, 31 Dec 1997 09:38:18 0600
XMailer: Mail User's Shell (7.2.4 2/2/92)
To: reliable_computing [at] interval [dot] usl.edu
Subject: Faculty position
Sender: ownerreliable_computing
Precedence: bulk
Dear Prospective Interval Applicants,
I would be pleased to answer any questions you might
have about these positions on an informal basis.
Best Regards,
D. Berleant
NOTE! The chancellor has recently targeted our dept. for a major
expansion. We now have four (not one) open positions. We would like
to see applications at the assistant professor as well as senior
levels.
University of Arkansas
Computer Systems Engineering Department
The Department of Computer Systems Engineering is expanding and
invites applicants for four tenuretrack positions at all levels,
assuming final budgetary approval. Applicant must have a Ph.D. in
engineering or computer science and possess an interest in and ability
to teach in the software area. Preference will be given to candidates
with any degree (BS, etc.) in engineering. The successful applicant will
emphasize quality teaching (currently two courses per semester) at the
graduate and undergraduate levels and a demonstrated potential to
initiate research projects while attracting external funding.
The Computer Systems Engineering Department is a dynamic and growing
department within the College of Engineering with research areas in
computer architecture, telecommunications, human computer interaction
and other areas.
Departmental resources include a network of over 50 Sun workstations
and 50 PC's linked to the College of Engineering's network, new NCR
equipment, and laboratories including the Computer Architecture
Laboratory, Image Processing Laboratory, Networking Laboratory, and
Software Artifact R & D Laboratory. The department has approximately
300 undergraduate and 30 graduate students with 10 full time faculty.
The University of Arkansas is located in Fayetteville, situated with
several other dynamic, growing communities in the beautiful
Northwestern part of the state in the Ozark mountains. The academic
units on the campus include eight colleges and schools with nearly
15,000 students, 800 faculty and 2,000 staff members.
A curriculum vitae, three references, and a small amount of optional
supporting materials will be accepted until the position is
filled. All candidates should indicate citizenship and, in the case of
noncitizenship, visa status. Mail to:
Dr. Carl D. Bowling
Search Committee Chair
Computer Systems Engineering Department
University of Arkansas
Engineering Hall 313
Fayetteville, AR 72701
The University of Arkansas is committed to achieving diversity,
racial, ethnic, and gender in its faculty. Therefore, the University
is especially interested in applications from all qualified
candidates who would contribute to such diversity in the Computer
Systems Engineering Department.