Re: dependent and independent intervals, proposal to toss out text2inter

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

Date: Tue, 19 Feb 2013 12:37:40 -0800
From: Richard Fateman <fateman@xxxxxxxxxxxxxxxxx>
To: "'stds-1788'" <stds-1788@xxxxxxxxxxxxxxxxx>
Subject: dependent and independent intervals, proposal to toss out text2interval. Was re: about emp (was: Motion 42:no)

Folks,

I have remained silent on this problem since it began.

(Actually, I am mostly listening to this list these days.)

But Richard has raised a point about decimal to binary conversion

that I'm not quite sure he is aware of. Indeed, as the quotations

are a bit unclear, *I'M* not quite sure just who raised it.

In the past, I have considered problems such as the conversion of

expressions like "0.1 + pi" or "0.1 + 3.141" as being the conversion

of strings to intervals followed by an interval add.

Now lets ignore the interval add on the grounds that we all know

how its done. But what about the string conversion? Again, in the

past, I have always considered it a problem of generalizing the

floating-point string conversion to intervals.

In the floating-point conversion, one converts the entire string

to the form m*10^e or m/10^e, exactly if possible, & does the

floating-point operation on those (mostly) exact floating-point

operands. For interval conversion, I would generalize to something

like [m-1,m+1]*[10^e-ulp,10^e+ulp] which is already widening the

result quite enough to cover the original decimal operand.

However, given the way it is written, 0.1 + 3.141, such a formula

must be converted to something equivalent to an interval like

[0,0.2] + [3.140,3.142] = [3.140,3.342] which is quite a bit wider

than I believe the user expects. *I*, as a user, would expect

something like 0.10000000000 + 3.14100000000 to be the result.

This has 2 problems. If you don't do it then the user is left

with far wider intervals than I believe are reasonable. And if

you do, the result of 0.10000000000 + 3.14100000000 will not

contain the answer to 0.1 + pi.

Which is it to be? We can justify the first even if the user

cannot. I don't believe we can justify the latter.

But its up to you...

Dan

On 2/19/2013 2:00 AM, Guillaume Melquiond wrote:
.... snip, , expressions meaning what they say...

I think that whatever advantage can be gained by allowing an implementation
to process string expressions like "0.1 + pi" is more than overcome by
. . .

If we are allowed to be slightly sloppy, by about half a unit in the
last place, we can take
the closest binary approximation for 0.1d0 and widen it by one ulp up
and down, and enclose
it. It turns out that for careful decimal-to-binary conversion, this
interval will
also enclose the mathematical value of 1/10 as well.

If we want to get the _tightest_ interval some work is required but I'm
not sure which of several
approaches is simplest.

One way is to form an interval [1.0d0,1.0d0] and divide by the scalar
10.0d0. If proper IEEE-754
directed rounding is available, we are done.

Any decimal constant, say 3.141, could be done by
scalar_to_interval(3141d0)/10^3.

(I believe that directed rounding here can be cheaply simulated by
default rounding-to-nearest
by bumping 3141 up and down before division. for example, to get the
tightest enclosure
around 1/3, in double-float binary, let eps = double-float-epsilon =
2.0d0^-53= 1.11022...d-16;
then create an interval [ 3141*(1-eps), 3141*(1+eps)] and then
divide, default rounding,
by 10.
)

Another more elaborate way is to make available tight intervals around
1/10, 1/100, etc.

. . .

Richard Fateman

Re: dependent and independent intervals, proposal to toss out text2interval. Was re: about emp (was: Motion 42:no)