RF> IEEE754 single 0.1 means exactly 13421773/134217728 or about 0.1000000014901... or
RF> 1/10+ 1.49..e-9.
RF>
RF> and if the default for creating an interval around 0.1 is to
RF> use double precision by [0.1] or "0.1" then one gets an interval equivalent to
RF>
RF> [3602879701896396/36028797018963968, 3602879701896397/36028797018963968]
RF> or approximately
RF> [0.099999999999999977795.. , 0.10000000000000000555..]
RF> or
RF> 1/10 + [-2.22...e-17, 5.55..e-18]
RF>
RF> The odd situation here is that the ordinary computer single precision
RF> number 0.1 mentioned previously is not contained in that interval [0.1].
More conversion functions than just text2interval are needed.
My comment is from experience. Typically, we have a basic interval data type in a program, and often, if not in most of the cases, it is an interval with two double endpoints. I think we need only (in C notation)
interval text2interval (const char * string )
which converts a decimal string to an interval containing it. How tight the returned interval is depends on the implementation, but it is reasonable to require that is as tight as possible. Specifying an additional parameter, e.g. how many significant digits of accuracy simply complicates things.
Finally, I feel string2interval is a better name. I propose we have only on such function for converting decimal strings to intervals.
Regards, Ned
One function would convert a single precision value and another a double precision value, both with a parameter specifying how precise they should be considered.
You could write
float x = 0.1f;
interval a = float2interval (x, 7);
to say that x should be considered to have 7 significant digits (0.1f happens to be accurate to 8 digits), and
double y = 0.1;
interval b = double2interval (y, 16);
to assert 16 digit accuracy for y.
An alternate approach would be for the second parameter to be the maximum relative error.
For text conversions, there are arguments in favour of two different semantics. In one, "0.1" and "0.100000" are considered as identical infinitely precise representations of 1/10. In the other, "0.1" and "0.100000" are considered as different, with "0.1" meaning [0.05, 0.15] and "0.100000" meaning [0.0000005, 0.1000005]. The first is useful for the mathematical value 1/10, and the second is more useful for measured values where trailing zeros indicate how precise the measurement was. A mathematician who wrote that only the first is needed and an engineer who said only the second is convinced me that both are. 8<)
Others (eg, Dimtry) have proposed other conversion functions.
- Ian McIntosh IBM Canada Lab Compiler Back End Support and Development
<graycol.gif>Richard Fateman ---06/09/2013 06:53:07 PM---On 6/9/2013 8:40 AM, Jürgen Wolff von Gudenberg wrote: > You don't like 0.1 changing its meaning wh
<ecblank.gif>
| <ecblank.gif>
Richard Fateman <fateman@xxxxxxxxxxxxxxxxx> |
<ecblank.gif>
| <ecblank.gif>
Ian McIntosh/Toronto/IBM@IBMCA |
<ecblank.gif>
| <ecblank.gif>
06/09/2013 06:53 PM |
<ecblank.gif>
| <ecblank.gif>
Re: Motion to finalise interval literals |
On 6/9/2013 8:40 AM, Jürgen Wolff von Gudenberg wrote:
> You don't like 0.1 changing its meaning when you put string quotes
> round it, so what about when you put square brackets round?
I am uncomfortable with both "0.1" and [0.1].
I am happier with 1/10 or ratio(1,10), since the semantics of
these are easier to explain. Even ratio(0,0), ratio(1,0) ratio(-1,0).
Perhaps an intermediate version could be fashioned with something
which so surrounds the 0.1 that it is hard to confuse.
Like IEEE754_binary_double_interval_containing_decimal("0.1")
I understand the motive to support a hypothetical "mathematician"
computer user who doesn't do scientific computation in the ordinary way and/or is
ignorant of representation issues in floating-point computation. This person
might use an interactive interval-based system to construct a proof or validate
an algorithm. (Rather than say, estimate the intensity of a tornado.)
Such a relatively "pure" mathematician might not understand (or need to understand) that 0.1
cannot be represented exactly in binary, even though binary is (probably)
the underlying representation for floats in the user's computer.
For such a person, in such a system, 0.1 meaning exactly 1/10 makes perfect sense.
Unfortunately if that interactive system is not solely about intervals but allows
that user to set x=0.1 outside the interval system, there is a potential difficulty.
IEEE754 single 0.1 means exactly 13421773/134217728 or about 0.1000000014901... or
1/10+ 1.49..e-9.
and if the default for creating an interval around 0.1 is to
use double precision by [0.1] or "0.1" then one gets an interval equivalent to
[3602879701896396/36028797018963968, 3602879701896397/36028797018963968]
or approximately
[0.099999999999999977795.. , 0.10000000000000000555..]
or
1/10 + [-2.22...e-17, 5.55..e-18]
The odd situation here is that the ordinary computer single precision
number 0.1 mentioned previously is not contained in that interval [0.1].
Thus we have a situation in which a naive user stepping outside the
interval package to read or compute a scalar number possibly encounters a
violation of containment. From a programming language perspective, this
is not so comfortable.
Certainly the same issue comes up if the single-precision computer
number 0.1 is not in the interval double_interval(1/10,1/10). But
I think it is easier to explain that 0.1 converted to binary
is not exactly the same as 1/10, and 0.10000000149.. is greater than 1/10.
Easier than to explain that 0.1 is not in [0.1].
I hope that text2interval is not so intertwined with other considerations of the
standard that it can be "optionalized" without too much difficulty. It doesn't
seem that text2interval is needed for a Lisp implementation, but that may not be "typical".
RJF
|