Re: text2interval again /
Richard Fateman wrote:
> On 3/7/2013 12:51 AM, Arnold Neumaier wrote:
> > This would not be enough as the error in a computed scalar can be
> > arbitrarily large, depending on how it was computed.
>
> If the error in a computed scalar can be arbitrarily large, then
> no such number whatsoever should be permitted as an endpoint to an
> interval ever.
If the sign of the error is known -- and it can be known when directed
rounding is used appropriately -- then this is perfectly ok. That's
precisely the point in encapsulating the whole interval constructor
instead of letting a program do it piecemeal.
> If the mathematician was so inclined to prove something about x in
> [1/10, 2/10] with a computer, then he (or she) should first make
> sure that [0.1,0.2] meant the same as [1/10,2/10]. Are we going
> to protect the mathematician from all possible representation-
> related issues in the scalar world outside intervals?
YES -- that's precisely what text2interval() can do: make the program
portable to environments with different underlying representations,
while at the same time allowing the properties of the representation
to be fully exploited.
> > The value is determined by the mathematical problem posed, which is
> > usually in text format.
>
> I really don't see this the same way you do. There are applications in
> which some physical problem starts with some uncertainty. A scientist
> will not know the uncertainty exactly and so will add some "slop" to it.
The purpose of the standard is to define primitives that can be used to
construct some programs with provable properties (NOT to guarantee that
every program will have provable properties). What those properties are
depends on the application, but containment is the underlying premise.
> There are problems that come from pure mathematics. It seems to me that
> a mathematician approaching a computer should understand how numbers are
> represented in a computer, and how to construct, using integers, etc. any
> exact numbers he or she needs to be represented in the computer.
The trouble with this is that different representations have different
properties, different ranges, etc., which makes it very difficult to
write portable programs. This affects integers as well as various
approximations to real-number arithmetic. By providing appropriate
primitives we can avoid this issue, to the extent that representation
issues will affect the quality of an implementation (e.g. tightness),
but not the correctness (i.e. containment).
> I recall, but cannot spot some discussion of 0.5 vs 0.50.
The Vienna Proposal mentions some literal representations to denote
intervals representing uncertain numbers such as
12.3_ # represents 12.3 +- 1 ulp, i.e., [12.2,12.4]
1.23?e3 # represents 1.23e3 +- 1/2 ulp, i.e., [12250,12350]
So far we have not had any motions that go to that level of detail.
It would certainly be ok for text2interval() to support such conventions.
But some explicit syntactic denotation would be required; conventions
that distinguish 0.5 from 0.50 are just not common enough (and make it
impossible to express exact decimals, except as explicit rationals, which
could conflict with a "no expressions please" syntax).
> what happens if we add .000 at the end of [2¬1023,2¬1023], and
> it causes us to round down and up. The endpoints of the original
> zero-width interval would be known to about 307 decimal places,
> but the endpoints of the widened interval would be known to about
> 16 decimal places.
Was the .000 a typo? If not, it would not cause any rounding or widening.
In any case, the number of digits of an exact decimal representation of a
binary floating-point number (which exists; max is 751 for IEEE binary64)
is a red herring. It is perhaps mathematically awkward that zero-length
intervals are ony possible for certain numbers -- but the fact that this
set includes all reasonably-small integers and a few common fractions
(namely the dyadic ones) means that it is possible to take advantage of
point intervals in most representations. Lisp's rationals are of course
a lot more attractive in this respect, and exact-real arithmetic (via
spigot algorithms or deferred functional expansion) would be even more
so -- unlike unbounded rationals it might even meet the requirement for
a well-defined hull.
(Now I wandered off the range... sorry.)
Michel.
---Sent: 2013-03-08 05:55:23 UTC