Re: On "infinite" sets and accumulation points.
> Date: Tue, 13 Jul 2010 10:37:05 -0400
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> From: Michel Hack <hack@xxxxxxxxxxxxxx>
> Subject: On "infinite" sets and accumulation points.
>
> Yes, all actual computer representations of sets of numbers
> are finite, but...
Do not dismiss the problem so lightly, Michel.
It is at the crux of our problems in defining
things for this standard. Tight or not.
>
> Vincent wrote, concerning "smallest superset" unambiguity:
> > I think it is sufficient to assume that there are no
> > accumulation points.
>
> Dan Zuras wrote, replying to Vincent Lefèvre:
> > > * Does IDBar have to be a finite set? ...
> >
> > First, no, it does not have to be a finite set. It is
> > just finite in any implementation known or considered
>
> There is still a difference between bounded and unbounded
> formats in computers. In his context, "unbounded" actually
> means something different from plain mathematics: it means
> that the only bounds are resource constraints. And that is
> significantly different from format-based constraints, and
> deserves to be treated as if the sets really were "infinite".
Of course it does. For the collection of formats
as a whole. But we cannot be so blithe as to
consider the density of numbers in all multi-
precision formats as a class when considering how
to compute a result in one of them.
Every result, even a multi-precision result, has
a precision specified for it, either implicitly
or explicitly (in the older sense of those words :-).
Were it not so the tightest interval containing
the value 1/3 would be an interval that sucked up
all the resources on your machine to represent it.
No one wants that.
So something must be done to say how much is enough.
We must decide what that something is to be.
>
> The reason is that one wants to avoid runaway resource
> consumption. Consider a program designed to compute the
> smallest strictly positive real number. There are formats
> where even exponents are represented in bignum form. Should
> the program be allowed to consume all available resources, or
> would it be better to detect early that there is no answer?
Just so. Something must be done. A television
character proved that back in the 60s when he
told his computer to "compute to the last digit
the value of Pi." His computer screamed & went
about doing just that. :-)
>
> Note that ZERO is an accumulation point in many such systems.
John already noted that when he described the
uniqueness problem for tight intervals with
zero near the middle of them.
> So are many exactly-representable non-zero numbers.
>
> Level-index systems are another case in point.
Oh, please, let's not consider SLI systems as
candidates for acceptable interval systems.
Not that. Not again. Please.
>
>
> To get to P1788 more directly, this suggests that, if the
> format permits "unbounded" precision, here should be controls
> on actual precision in certain cases, e.g. "tightest hull".
> (Alternatively one could indeed rule out such formats.)
>
> Michel.
> ---Sent: 2010-07-13 14:59:15 UTC
Exactly. And whether we are seeking the tightest
hull or not, there will need to be some way for
the user (or programmer, or library writer, or
implementer, whatever) to specify just what is
desired in this case.
Even when one works in a multi-precision system
where the precision changes on the fly, there
must be a way to control it.
Therefore, we cannot consider the collection of
all such precisions as a class to be a candidate
set at level 2.
Even if a precision is so fleeting as to only
exist for the creation of one result, there must
be a (finite) set of intervals that go with that
precision & we must define what the correct
answer is for that result.
Note that tightness doesn't enter into it. We
will need to define 'looser' results as well.
The definition will be different but it must
be no less well defined.
And, of course, mere containment doesn't enter
into it either. All of those sets in all of those
classes can get containment so long as the element
[entire] is in each of them. And, of course, that
would not be reasonably considered to be the right
answer to almost all problems.
But both of us are arguing in the weeds, Michel.
There are reasonable things to do. We must just
go about doing them. Alas, I'm fairly certain
that anything reasonable will also turn out to
be hard to define &, possibly, hard to do.
I am counting on those of you who know this topic
far better than I to figure out just what that is.
I'm also fairly certain there IS an answer.
Yours,
Dan