Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: IEEE Standard 1788-2015



Svetoslav,

The reason the inner operations were not included is
because no-one wrote up a document for them and presented
it formally to the committee.  The primary P-1788 editors
assumed Nate would do this, but he never got around to it.

The full P-1788 document provides a clear mechanism (flavors)
for including inner operations, and it still can be done.  However,
at this point, I think it would involve submitting another PAR
and seeing it through the approval process.  The thing is, someone
needs to do the work.

Baker

On 09/27/2015 02:50 AM, Svetoslav Markov wrote:
In the standard there are interval operations that
allow you to obtain x-x=0, these are the cancel plus/minus
operations. However, the cancel +/-  are not "operations" in the
sense of algebra. I would suggest that the cancel plus/minus "operations"
are included in the basic standard.
S. Markov
PS. Algebraic operations have to be defined for all
intervals, whereas the cancel +/- are not. It is a pity that
the inner operations (proposed by me and Nate) were not
included in the standard. The inner +/- operations are
operations in algebraic sense.



On 26 Sep 2015 at 17:10, Kreinovich, Vladik wrote:

From:	"Kreinovich, Vladik" <vladik@xxxxxxxx>
To:	"Kreinovich, Vladik" <vladik@xxxxxxxx>,
        	Mehran Mazandarani <me.mazandarani@xxxxxxxxx>,
        	stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>,
        	"Andrzej Piegat" <apiegat@xxxxxxxxxxxxx>
Subject:	RE: IEEE Standard 1788-2015
Date sent:	Sat, 26 Sep 2015 17:10:56 +0000

     On 1): we are talking about the problem that I mentioned in my first very email
     reply: we have a function f(x1,…,xn) and n intervals, we need to find a range
     of this function on these intervals.

     If n is fixed, then we have a polynomial-time algorithm – but the power of the
     corresponding polynomial grows with n.

     From: stds-1788@xxxxxxxx [mailto:stds-1788@xxxxxxxx] On Behalf Of Kreinovich,
     Vladik
     Sent: Saturday, September 26, 2015 10:33 AM
     To: Mehran Mazandarani <me.mazandarani@xxxxxxxxx>; stds-1788
     <stds-1788@xxxxxxxxxxxxxxxxx>; Andrzej Piegat <apiegat@xxxxxxxxxxxxx>
     Subject: RE: IEEE Standard 1788-2015

1)     Yes, it would be desirable to compute the exact range all the time and
     to avoid overestimation, but it is known theorem that computing the exact range
     of a function under interval uncertainty is NP-hard, even for quadratic
     functions, so if we want to get guaranteed bounds, excess width is inevitable,
     i.e., if we want to always get an enclosure, an interval always containing the
     exact range, it is inevitable that we have an enclosure which is sometimes
     different from the exact range.
2)     The original example of x-x when x is [1,3] (and a similar example of
     x/x)  are based on a major misunderstanding of interval computations which is,
     unfortunately, rather common: that interval computations means replacing each
     operation with numbers by a corresponding operation with intervals. This
     so-called na"ive interval computations was never advocated by anyone, the very
     first 1966 book by Moore has exactly this example of x-x to show that this is
     NOT the way to go. A proper way – as shown in any textbook or survey on
     interval computations and implemented in all the packages – is to first check
     monotonicity and then use centered form if the function is not monotonic.
     Monotonicity can be checked if we apply automatic differentiation to the
     expression and then use na"ive interval computations to find the range of the
     resulting derivative. If the resulting interval is always non-negative or
     always non-positive, the function is monotonic and its range is easy to compute
     by simply computing the values at endpoints. When we apply this to x-x,
     interval computations lead to 0 range, NOT to [-2,2]. Same with x/x.

     From:stds-1788@xxxxxxxx [mailto:stds-1788@xxxxxxxx] On Behalf Of Mehran
     Mazandarani
     Sent: Saturday, September 26, 2015 6:19 AM
     To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>; Andrzej Piegat
     <apiegat@xxxxxxxxxxxxx>
     Subject: IEEE Standard 1788-2015

     Dear John, Vladik, Michel, and IC members
     Thank you for your kind reply.
     I am writing to you regarding the previous emails about that section in Std.
     1788 which deals with operations for interval arithmetic.
     As I mentioned, based on the Std. 1788-2015 we may obtain results which lead to
     values that are not possible actually.
     Michel told that it is because of dependency issue, and that Moore's arithmetic
     is indeed a worst-case arithmetic -- but this allows it to *guarantee* that the
     computed result encloses any possible actual result.
     Then, he told When an interval programmer writes a program to compute a
     particular function, which could (in the point-function context) be written as
     an
     algebraic expression where certain variables may appear multiple times,
     the programmer may take advantage of specific knowledge -- in particular,
     monotonicity properties -- to compute a tighter enclosure than blindly
     evaluating the expression using Moore arithmetic.
     1. Using Moore's approach leads to obtain values which may not be possible,
     i.e. impossible values. So, it makes us to analyze, decide, and design systems
     and processes with too high costs and probably too complex. That all of these
     are because of values which are impossible, i.e. they will not happen.
     2. The standard should be based on an approach which makes us be assured in at
     least some future development. This is while as you can see the attachment,
     using advantage of specific knowledge we get to what I termed it Restoration
     issue.
     Additionally, we are just considering very simple cases, because the
     cases themselves have their own issues of obtaining real possible
     results/values, let alone problems related to differential equations and
     defining derivatives.
     I recommend to rethink about the section of Std. 1788-2015 which deals with
     fourth basic operations in order to avoiding what will mislead us in so many
     problems.
     Comments are welcome.
     Thank you so much for your kind attention and consideration.
     Warmest regards,

     Mehran Mazandarani
     Department of Electrical Engineering
     Ferdowsi University of Mashhad, Mashhad, Iran.
     homepage:http://mehran.mazandarani.fumblog.um.ac.ir/
     http://works.bepress.com/mehran_mazandarani
     IEEE Member, me.mazandarani@xxxxxxxx











  Prof. Svetoslav Markov, DSci, PhD,
  Dept.  "Math Modelling & Num Analysis",    phone: +359-2-979-2876
  Inst. of Mathematics and Informatics,          fax: +359-2-971-3649
  Bulgarian Academy of Sciences,                  e-mail: smarkov@xxxxxxxxxx
  "Acad. G. Bonchev" st., block 8,
  BG-1113 Sofia,  BULGARIA                      mobile (gsm): 08888 24567
URL: http://www.math.bas.bg/~bio/
URL:  http://www.biomath.bg/
www.biomath.bg/2015/
http://www.biomathforum.org/biomath/





--

---------------------------------------------------------------
Ralph Baker Kearfott,   rbk@xxxxxxxxxxxxx   (337) 482-5346 (fax)
(337) 482-5270 (work)                     (337) 993-1827 (home)
URL: http://interval.louisiana.edu/kearfott.html
Department of Mathematics, University of Louisiana at Lafayette
(Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
Box 4-1010, Lafayette, LA 70504-1010, USA
---------------------------------------------------------------