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

Re: Version 2.11, Proposal for interval standardization

Arnold Neumaier wrote:

Sylvain Pion schrieb:

Arnold Neumaier wrote:

Just to make my point clear, and make sure we agree:
if IEEE-1788 requires being able to parse the text of expressions in
the format specified in 2.6, then I find it not language-level-friendly. 
It would be a boring-to-implement and useless requirement (and not
constexpr-friendly for the particular case of C++0x).
Specifying I/O text/literals formats for isolated intervals is fine,
but going to expressions is too much, IMO.  Languages already have
their own ways and syntax to specify expressions, we should just talk
about expressions in a more abstract way than text format in IEEE-1788.
The next version of my proposal will have the conversion of text containing constant expressions only as recommendation, except for the conversion of quotients of arbitrary integers, which will be required to convert to the tightest interval containing the quotient. 

I guess I will then have to ask for a paragraph in the Rationale which
explains "why this one?" :)


Very long rationals frequently arise in problems generated
from computer algebra packages using rational arithmetic.
For example, I have seen rationals with 800 digits in a particular
constraint satisfaction problem posed to me, generated for a
computer-assisted proof in the geometry of numbers. See the end
of Section 4 in
    http://www.mat.univie.ac.at/~neum/ms/caps.pdf

Computer-assisted proofs are one of the application areas where
interval arithmetic is indispensible, and the standard must cater
for it.


Tight rational -> interval conversions are important, I agree.
I felt the need for this numerous times in computational geometry as well,
but not for constants only.
So, this still has nothing to do with constants or text parsing either.
I am not sure how to present this requirement, then.  We would have to
refer to a multiple precision rational data type (the LIA standards have
these, I think, but not IEEE-754).

--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
CGAL, http://cgal.org/

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature