Re: Proposal for a new structure of the standard
Vincent, Dan,
Thank you for your contributions.
I have inserted a couple of comments with my personal opinions.
Best regards,
Baker
On 7/14/2010 02:56, Dan Zuras Intervals wrote:
Date: Wed, 14 Jul 2010 02:49:31 +0200
From: Vincent Lefevre<vincent@xxxxxxxxxx>
To: stds-1788@xxxxxxxxxxxxxxxxx
Subject: Re: Proposal for a new structure of the standard
.
.
.
On 2010-07-13 06:43:25 -0700, Dan Zuras Intervals wrote:
* Does IDBar have to be a finite set? This doesn't seem to be really
useful and that would rule out some implementations, such as
intervals of GMP integers, for instance.
Well, two things here.
First, no, it does not have to be a finite set. It is
just finite in any implementation known or considered&
therefore useful in that sense.
And, second, that includes GMP. GMP may be able to
represent a great many more numbers. But not infinitely
many. :-)
According to the *specification*, the numbers are not bounded, thus
the set is infinite.
I'm not sure what specification you mean here.
That some set at level 2 contains intervals with
unbounded endpoints does not imply that the set
itself is infinite. There may be only finitely
Was the confusion here about whether the set that an
interval represents is infinite or whether the set of
sets that is representable at level 2 is infinite? My reading
of this is that it reduces to confusion about what we mean
by "level 2". My reading of Motion 2 is that, at level 2,
we are speaking of a finite underlying set of numbers
(a conceptual model of machine numbers), from which intervals
are somehow built (via mid-rad, etc.). The usual thing
would seem to be a fixed precision, in which case the set of
intervals would somehow be a subset of a finite cross product
of power sets of a finite set, and thus finite. One way
the set of intervals at level 2 could not be finite would be
if we somehow devised a variable-precision interval arithmetic
with an unlimited maximum precision. Am I right?
Would the apparent controversy or confusion reduce
to us perhaps not using the same meaning for "Level 2"?
A possible analogy comes to mind: In English, "sensible"
means, roughly, "logical," whereas, in Spanish, I think
it means, roughly, the English equivalent of "sensitive."
We should all attach the same meaning to "Level 2" for discussions
about it to make sense.
One can deduce obvious bounds from the internal
structure, but I don't think such bounds have any interest as in
practice, the limit is implied by the available memory, with an
undefined behavior (in general) when the available memory is
exhausted.
Of course.
Ah, yes, even the variable precision case is finite, but I think
I see Vincent's point about perhaps somehow not stipulating limits
here. It isn't necessarily a case of different interpretations of
"Level 2." What practical impact does it have on how we specify operations?
This is very different from the set of floating-point
numbers in fixed precision, where the limits (range and precision)
are well-known and the specification is clear (though there may
still be implementation limits in practice, e.g. because in general
some memory will be dynamically allocated).
I would argue against that. The limits of range&
precision are just as clear as they are with smaller,
hardware implemented floating-point numbers. It is
just that in the case of multi-precision intervals
the user is allowed to choose those limits.
But the limits are there all the same.
Hmmm.... It seems this could go either way. Is it worth a motion
that we somehow specify limits? Again, what practical impact does
this have in our specifications?
.
.
.
Ditto, it is *not* required for reproducibility. A fixed algorithm
in a fixed arithmetic (i.e. with no optimizations that can change
the behavior) is sufficient for reproducibility.
Ah, now we get into what amounts to a philosophical
question. Mostly about how one writes standards.
I know people in this working group (and others) who would object
to us specifying algorithms. In particular, someone might design
an algorithm that gives the same result much faster, or is more
scalable, or more appropriate on a new architecture not foreseen
by us. (My personal opinion): An example that comes to mind is
new algorithms for accurate computations of sums and dot products,
that make specibutand note that I say "debatable," not "not desirable").
.
.
.
Of course interval arithmetic is not designed to detect
bugs in processors. Or anywhere else for that matter.
What ever gave you THAT idea?
Then the paragraph on the Pentium bug is meaningless.
Don't blame John for that comment. Blame me. And it
was not about detecting bugs in processors. It was
about companies that let arithmetic bugs get out there
& then deny that they are a problem by saying that only
obscure mathematicians doing obscure mathematics would
ever find it.
Well, even though interval arithmetic is not designed to detect
bugs in processors, my (by current standards) rather rudimentary
portable INTLIB package has detected various bugs in systems.
Even though INTLIB is purportedly portable and doesn't require
any underlying arithmetic standards, it makes certain assumptions,
such as the relative amount by which the stored result of an
operation can be in error. Assuming there isn't a bug in INTLIB
itself, INTLIB producing a contradiction (such as zero not an
element of a result that, mathematically, must equal zero) means
that the underlying assumptions are violated. As one of several
examples of this, INTLIB discovered a surprising undocumented
lack of accuracy in decimal to binary conversions in an early
version of the WATCOM Fortran compiler.
I view interval arithmetic as a possible tool in gathering evidence
of correctness, although I don't think it can provide certificates
of correctness of hardware.
My own opinion:
Reproducibility could aid greatly in implementing and validating
packages that implement the standard itself.
.
.
.
--
---------------------------------------------------------------
R. 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
---------------------------------------------------------------