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