Re: dependent and independent intervals, proposal to toss out text2interval. Was re: about emp (was: Motion 42:no)
On 3/3/2013 6:05 AM, John Pryce wrote:
Richard
One point where I completely disagree with you, and one where I agree.
On 1 Mar 2013, at 18:37, Richard Fateman wrote:
>Pertaining to a floating literal, it says "Its value is the exact
>real number it represents." which has an certain air of either obviousness or mystery.
>I read it as meaning "A floating-point literal string converted to an internal floating-point representation is a single exact number, not a range."
Well, it seems utterly unambiguous to me, so no mystery. But it does not mean what you say, at all, so it seems it's not obvious either.
The floating literal "0.1" denotes 0.1, a tenth, the rational 1/10. It does not denote some approximation thereto obtained by a finite precision conversion.
It seems to me you are misunderstanding the roles of Level 1 and Level 2, and of the hull_T() function that implements the map from Level 1 intervals to Level 2 intervals.
text2interval("[0.1,0.1]") denotes at Level 1 the singleton interval [1/10,1/10], hence at Level 2 the hull of this in whatever interval type T.
Perhaps my misunderstanding was fed, in part, by the previous sentence,
which reads,
"If the former [i.e. a string not infinity], it is a decimal or hexadecimal
floating constant, of arbitrary precision, acceptable as input to the
754 standard's string-to-
float conversions (see IEEE754-2008, x5.12)."
Your explanation then says that a string s , say s = "0.1" which is
acceptable as input to the
IEEE754 string-to-float conversion is also acceptable to the
text2inteval program. However it seems
it does not necessarily denote the same numeric value in text2interval
as in the IEEE754 standard.
In text2interval("[0.1 ...]"), the number is 1/10. The IEEE-754
(binary) float would be the
closest binary float in the designated precision, but certainly not
exactly 1/10 which cannot
be expressed in binary float. Or is it somehow assumed that the
floating-point radix will be decimal
when reading "0.1"? Also I'm not sure how arbitrary precision works
into this. If you put in too many
digits does IEEE754-2008 round?
Presumably if one makes a concrete version of text2interval, say
IEEE754double_text2interval(), the
string s will ultimately be converted to the IEEE754double
representation and then possibly rounding up or down.
I suppose I would be happier if 1788 confined itself to constructable
numbers.
So perhaps the sentence "Its value is the exact real number it
represents." would be
clearer if it said something more like this..
"If the string syntax conforms to describing
a finite binary or decimal float, it represents that an exact rational
number, e.g decimal 0.1 is exactly
1/10, not subject to rounding or conversion-to-binary approximations.
Such conversions may be required to fit a machine representation at
level 2 in the standard."
While I have suggested eliminating text2interval, your option (b) is more
perspicuous. One could write it then, in pseudo-code as
text2interval(s):=
look for [A,B]; return (nums2int( read_from_string(A),
read_from_string(B))
look for <A+-B> ; return mid-rad version
look for [A], do whatever is decided.
This same data could be generated by separating the strings for A and B and
writing a short program...
lo:=read_from_string (A);
hi:= read_from_string(B);
nums2int(lo,hi)
thereby eliminating text2interval.
Actually it would be eliminating IEEE754double_text2interval,
IEEE754single_text2interval ...
On the other hand I object to (b) if it eliminates or deprecates in some
way the
option of creating intervals with rational endpoints as
text2interval("[1/10,1/3]")
This does not actually affect Lisp since I would never use text2interval...
I would simple use the equivalent of nums2interval(1/10,1/3).
RJF