Re: dependent and independent intervals, proposal to toss out text2interval. Was re: about emp (was: Motion 42:no)
On 2/20/2013 7:56 AM, Kreinovich, Vladik wrote:
Openness to possible future developments is definitely a good idea, it was always something we strived for.
Minor word of caution: while arithmetic of rational numbers is easily decidable, once we start adding constants like pi etc. (especially with special functions like exp and sin added) we run into situations where there is no known algorithm for deciding equality, or where algorithms are known but are unrealistically long. For example, as we mention in Chapter 4 of our 1997 book on computational complexity of interval computations, even algorithmic decidability of exp-polynomials (i.e., functions obtained by compositions of exp and polynomials) is based on an unproven hypothesis, and if we add sin to the mix, we get problems which are either undecidable or require exponential time in some cases.
So, while in some cases, explicitly adding pi will enables us to get exact ranges, in general, we will still need enclosures :-(
-----Original Message-----
From: stds-1788@xxxxxxxx [mailto:stds-1788@xxxxxxxx] On Behalf Of Vincent Lefevre
Moreover an arithmetic where 0.1 + pi is exactly representable might be used, e.g. something based on Q[pi] or simpler. This could be useful when trig functions are used. In such an arithmetic, sqrt(cos([0,pi/2])) could be evaluated without the drawback of some values being undefined.
Perhaps such an arithmetic hasn't been implemented yet, but the standard (that will be there for many years in the future) should encourage new arithmetics rather than forbidding them.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
I have no doubt that a system that has explicit representations of
e, pi, sqrt(2), ... and knows that sqrt(2)*sin(pi/4) -1 is identically zero
is useful, and could be used for building an interval system.
My favorite computer algebra system is happy to host such a system.
BUT I think that encouraging unknown future extensions, or implementations
clearly beyond the scope of "let's extend C, or Fortran, or Java to do
intervals"
should not be the point of this standard.
If there later arises a new and wonderful kind of arithmetic, that might be
reason to write a new standard if it cannot conform to this one.
I think the points of the standard should be
Descriptive
1. To consolidate what people already agree about. That way
we can, to some extent, exchange simple programs.
Prescriptive
2. Compare and contrast areas of disagreement among distinct
well-defined alternatives so as to make an informed choice as
to the behavior of "the standard". This typically involves
showing examples of programs that accomplish a well-known
computation and how one version works better than another,
perhaps each version can simulate the other at some cost.
Compare the costs.
This means we can exchange more elaborate programs.
3. (Compromises, decisions) In the case of irreconcilable differences,
that is where only one path can be taken and others cut off,
there is a vote.
Experiments [[not good..]]
4. It is generally not good to
put new, experimental, untested ideas in a standard. Some people
think that the IEEE-754 standard broke new ground, but it was
actually more like a battle among arithmetics... as done by
intel 8087, IBM-360, DEC VAX 11/780, and a few other ideas
that had been explored like floating/slash. At UC Berkeley, one
important effort was a design, down to the circuit board level,
then the building of hardware and software, to add what was then
called KCS (Kahan/Coonen/Stone) arithmetic to a DEC VAX. To show
how it could be put into a non-Intel environment.
Reference Implementation
There appear to be parts of the 1788 proposal that have never
been implemented in hardware or software anywhere.
Without at least one reference implementation I think the IEEE
will (should!) simply reject any proposed software standard.
RJF