Re: proposal to toss out text2interval.

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

I am looking at P1788/D7.0 dated Jan 18, 2013

Text2interval is mentioned on these pages:
22
41
42
43
44
48

On page 22 (level 1) it suggests "[2pi,oo]" is ok for human consumption but refers forward to
level2 subclause 13 for rules which "may optionally be followed". It says "any understandable
t {text] is acceptable." From this it seems a small step to say, for human-human communication
an interval can be denoted with square brackets, e.g. [2pi,oo]. The whole business of putting
stuff in quotes and portraying it as a string and making it into an interval, at this level, is just
a game of shadows: one has not specified what strings are legal, one has not specified how
one converts a string 0.1 much less 2pi into a scalar value, or what that value represents, either
a finite-precision binary float, an exact number etc. I do not see that text2interval("[2pi,oo]") is
somehow more definitive vs [2pi,oo] at level 1.

On page 41 section 11.11.1 there is apparently introduced into the interval standard, a requirement
to parse strings into numbers. 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."

However, since this refers to the format for IEEE754-2008 -- unless it is -inf,inf,-infinity,infinity, emp, empty,
ent,entire, -- it seems that all the cases can be dispensed with by one program, and a few constants.

This eliminates the need in 1788 to refer to floating point decimal to binary (or other radix) conversion,
(which in any case later refers to "floating literal in the default locale perhaps violating the assertion of
IEEE754 compatible --)

The program could be infsup2interval(a,b) perhaps with multiple instantiations for type, e.g.
double_nums2interval(a,b)

Possibly a second bunch, midrad2interval(m,r) .

Thus instead of double_text2interval("[a,b]")
we would use
A:=<<double floating literal in the default locale>>
B:= << ditto>>

result:=double__nums2interval(A,B);

All other cases of text2interval can be similarly converted, using if necessary A:=infinity()
where infinity() is a function that returns infinity. bareempty() and bareentire().

If the locale supports IEEE754, we are set.

Also we have functions entire() and empty() returning intervals.

So I think the need to do text2interval, given the context of IEEE754, is gone.
I do not really credit the discussion of the undecidability of L<=U (page 43, 44).
If a host programming language cannot decide this properly it is unlikely
to be a proper framework for intervals.
That is, do we have a plausible situation in which
if L<=U is true when L and U are upgraded to high precision, but
L>U when L and U are downgraded to low precision?

I can just barely imagine an interval package that is hosted in a language, that
supports, say, only integer constants, although variables can hold pointers to
any quantities. and that any floating point arithmetic must then
be done by (say)
X:=text2interval("[12.34,12.34]")
Y:= add(X,X)

etc. But this doesn't really seem worth pursuing.

To provide a "formal description of strings accepted" and then allow
anything in an "enhanced syntax" of literals is unnecessary in my approach.
If there is an enhanced syntax for literals in language M, one generates an
interval by
A:=<<literal in language M>>
B:= <<literal in language M>>
result:= type_num2interval(A,B)

which both simplifies the standard and enhances the language.

I wish to point out that my own implementation in Lisp allows ratios of
arbitrary-precision integers, e.g. 1231232131213231231 / 21321321231
as literals, as well as software-bigfloats e.g. 1232132121321.0213b0
of a precision specified by a global parameter.

There is an argument perhaps that (say) an enclosure for pi in precision T
might be better computed by (say) text2interval("Pi")   and this would
be better than
A:=<<floating literal for PI>>
result:=nums2interval(A,A).
Yes.   that interval would be exactly A, which is not an enclosure of Pi.

but it would not be better than

A:=<<floating literal just less than Pi in precision p>>
B:= A*(1+<<suitable epsilon for precision p>>)

result:=nums2interval(A,B).

or perhaps result:= 4* arctan(nums2interval(1,1)).

I also assume that, for someone who might care about particular transcendental
numbers, such intervals could be supplied in a library as double_pi()   etc.

On the one hand, 1788 seems to rely upon and expect IEEE754 arithmetic,
on the other hand it seems to indicate (as in the enhanced syntax)
that other un-specified things "may be provided".

while I'm ragging on this section, here's a simpler / readable/ more complete? BNF grammar,
in case text2interval persists.

floatlit ::=    floating literal in the default locale optionally preceded and/or followed by zero or more spaces, tabs
unsignedinf::= infinity
unsignedinf::= inf
floatlit::= unsignedinf
floatlit:= - unsignedinf
intervalliteral ::=   [ floatlit, floatlit ]
intervalliteral::= <floatlit +- floatlit>
intervalliteral ::= empty
intervalliteral ::= entire

The section on input and output (13.) seems too long, but it finally provides
(for me) a glimmer of a reason for text2interval, in one context, namely reading
as input stuff that was printed in a format that needs to be parsed.

Let us disregard the decoration issue; decorations can be added or printed later.

There are 2 issues:

Exact input and output:
Since an interval consists of 2 numerical endpoints (or mid/radius perhaps), any means by which
a number may be written and read back to the same internal form is suitable for writing
an interval. This need not be hexadecimal, even for a IEEE754 system. This seems to
require that empty and entire have endpoints which are expressible and printable as
(say) floats. And that inf and -inf as endpoints, can be printed and read back.

There is, finally, a rationale for text2interval.
If one program writes to a file a bunch of intervals, say one per line
[1,2]
<3+-0.1>
empty
[0,infinity]
entire

then reading them in a loop, say for i:=1 to 5 do a[i]:=double_text2interval(read_line_to_string(file_descriptor)) end
makes some sense.

Not as much sense as printing the intervals in a way that allows the
host system to read numbers, as its best effort.

0 1 2   /// 0 means valid interval with bounds 1 and 2
1 3 0.1 /// 1 means mid-rad form is used
2   0 0 /// 2 means empty
3 0 0 /// 3 means the lim-sup is oo;;   4 0 x means [-inf, x] etc. unnecessary if host allows input of inf.0d0 say,
9 0 0 /// 9 means entire or   -oo oo

If empty were [ NaN, NaN]    and the host allowed NaN.0d0 etc for float input
we could do this more simply without the first column of keys, except maybe for mid-rad representation: as

1 3
3 0.1
NaN.0d0 NaN.0d0
0 inf.0d0
-inf.0d0 inf.0d0

(essentially none of this is necessary in Lisp, since the output can ordinarily
be arranged to read back in without loss, and if the setup was
to write out an interval with the intention of reading it back in, one would
write out
(nums2int 1234.0 5.678 DAC)                for example.
(nums2int 0 infinity DEF)
(nums2int 0 0 EMP)
etc

And these lines in a file would be read in as any other expressions using
the Lisp program (dotimes (i 5) (setf (array a i) (read <<file descriptor>>))

Abbreviated output (shorter strings for human consumption).

Clearly if an interval is, say [0.6, 1.4]   and it is printed "rounded to one digit" as [1,1], this
violates the presumption that the presented interval is an enclosure. A simple example
or statement to this effect might help

I have not seen the Vienna proposal Part 6, so I can only speculate that it would return an
enclosure [0,2] for the above. There are certainly difficulties in printing infinity or overflow or
empty in one digit, a problem that is already faced by (say) FORTRAN presented with
the task of printing 12345 in 4 digits. I think it used to print ****, but I have no recent
FORTRAN formatting experience.

Rather than putting a burden on formatting, the operations of maintaining the enclosure
property can be done equivalently by calculation, and then allowing the host system to print away.
e.g. round down a lower limit to be printable in F5.2 format, and similarly for upper bound.
Then let the host language do its job. Presumably the Vienna proposal is better thought out
than my typing from the top of my head.

This could be done in any radix, in case there are people who would like hex representations,
but not too many digits.

Summary: I still think text2interval is unnecessary and vague with regard to allowing "extended"
syntax, and that it complicated and lengthens the standard. My bias is partly generated by
not ever having any use for it, in spite of writing many lines of code and some standard kinds
of application examples, in Lisp.

RJF

On 3/1/2013 5:02 AM, Vincent Lefevre wrote: