Re: Motion to finalise interval literals
On 6/8/2013 6:32 AM, John Pryce wrote:
Jürgen and P1788
On 7 Jun 2013, at 19:02, Jürgen Wolff von Gudenberg wrote:
as already stated in one of my last emails, I think interval literals should not be required. They will involve languages and compilers, and ,hence, augment the workload in dissemination the of standard.
so change the "shall" into a "should"
With respect, I disagree entirely with this and wonder if the draft text doesn't make the purpose of interval literals (ILs) clear enough.
- For some time to come, interval computation will not be integrated
within a language; Sun Fortran & C++ are an exception.
Instead it will be provided by a bolt-on library. Interval literals
give a standard specification for reading (especially) and writing
intervals -- important both for interactive work and for reading/
writing text files.
I think that I differ in my view of what the standard is aiming for. I
think that there is one
view that is further in the direction of bolt-on library, but may be a
helpful illustration by
carrying an idea to an extreme.
One can conceive of a language and standard design for intervals such
that every
language that allows a string data type can have a completely specified
exact-to-the-bit
identical implementation. It could in essence be an interpreter
(written in the host
language, let us call it HL ) for another language, call it IL for
Interval Language.
In the host language we would see something like:
call_IL ("double_var A, B,C")
call_IL (" A= [0.1,0.2]")
call_IL ("B=sin(A)+1"]
call_IL ("print(B)")
etc.
Within this view we can have a total disconnect between numeric data
in HL and IL. Indeed, HL need not have any floating point numbers, or even
any arithmetic. Just string matching and replacement.
Or HL can have floating point numbers, but in a different
radix. For example, it may be impossible to exactly represent 1/10 in HL,
and uttering x:=0.1 provides a number which is strictly greater than 1/10.
Yet the string "0.1" in IL, may be exact, and even decimal.
Now it is entirely possible that someone would endorse the creation of IL,
as a machine independent logically complete interval arithmetic
implementation.
It would depend solely on manipulation of strings.
At perhaps the opposite extreme that is at all plausible, would be an
interval
arithmetic "implementation" which does arithmetic on pairs, but ignores the
requirements of valid containment via directed rounding etc. This would
be so sloppy that this clearly would not pass muster.
Somewhere in-between these extremes we are trying to find the specification
in a design space that makes appropriate use of the facilities available in
the likely programming languages used for numerical calculation in
which one can embed an interval implementation.
Note that the interval
implementation need not be written in that language, just available. For
example, a Pascal or FORTRAN or LISP language interval extension package
could be written in C or Assembler etc.
Let us assume for the rest of this discussion that the host language HL
is not the string-manipulation horror suggested above, but one that
might appeal to scientific or mathematical computing applications.
It has integers and floating-point numbers. It can read and write
such numbers, and provides arithmetic operations.
It might even
provide directed rounding (but we must not depend on that given
the realities of today), It might provide exact arithmetic or rational
arithmetic or arbitrary-precision floats. But it would, I think, be
unrealistic to depend on that, either. While we cannot depend
on these being built in to the HL, it does not require great effort
to simulate any of these in an HL that already has scientific merit.
It is possible that someone would come up with a HL for which
such features as are needed cannot be reasonably added.
One solution is to push such features into the interval library
"just in case" (like text2interval). Another solution is to say that
if HL is unable to construct numbers that are within 1/2ULP of
a designated real number within RR (or however you want to
designate finite double floats)... then that HL is simply unsuitable
for interval computation.
I think that would eliminate from consideration approximately zero
languages
among the ones I am familiar with.
There are also demands to be able to produce Inf and NaN.
Also constants like the largest non-infinite float. Also to be
able to read and print such numbers. Are we eliminating
any prospective HLs with these? I think no.
As I've said, I think there is merit in using the language so that
0.1d0 designates
the same number in all contexts. For example
min(interval(0.1d0,0.2d0))
should be the same bit pattern as 0.1d0.
Construction of tight intervals around numbers that do not have exact
binary representations can be done strictly OUTSIDE the interval package,
in any HL worth considering. Or if a language cannot do this, by
specifying in the standard the requirement of new scalar
functions to do scalar arithmetic with rounding, or scalar operations like
next_up or next_down.
An interactive user of a program using 1788 ILs will know what interval
syntax to expect, independent of platform, language and application.
If I read this correctly you are hypothesizing that two or more HLs have
been used to
construct different interactive programs to be used by someone who has
been schooled
in the 1788 standard but is ignorant of either HL representation of
numbers etc.
In your scenario the purpose of the 1788 standard is to specify what
should
appear inside the strings in my extreme example of call_IL("....").
In your view the interactive program being used apparently has no
scalars from HL.
Everything is done via call_IL () ... otherwise the interactive user
might have to understand the
difference between 0.1 and "0.1".
This is, I think, setting the cart before the horse. You have to
cooperate with the HL design
to the extent possible, not cover it over.
In absence of this, different libraries would have different ways of
reading intervals from an external stream.
Different programming languages already read numbers from external
streams in
well understood ways. A programming language that has no method to
correctly read back in some number, or pair of numbers, or pair of
numbers plus a decoration,
is inappropriate to use for numeric computing, in my view.
Though not the same, this
would be similar to the situation of Algol 60, which didn't standardise
I/O, leading to different I/O systems being provided by each vendor.
This was a significant contributor to Algol 60 being made obsolete by
Fortran, which did standardise I/O.
I think this may be relevant in an historical perspective, but I suspect
that the
standardization of numeric I/O is fundamentally solved by libraries.
A distrust of the host language (and its operating system standard I/O)
to read/write floats seems unproductive.
- 1788 IL syntax is not intended to constrain (though it may guide)
interval syntax within a language. Sun Fortran is not made 1788-non-
conforming by having a different interval syntax within the language;
though to be conforming it *would* have to implement text2interval()
using the 1788 specification. (Of course, it would also have to change
from the cset model.)
I think this is one reason to make text2interval() optional.
I find Richard Fateman's Lisp implementation harder to diagnose. Is
it a library? Or is it part of the language? Or does the structure
of Lisp systems mean that this is a meaningless distinction?
I think it is probably a meaningless distinction. It is possible to read
a file into a running
Lisp system. The file can contain additional programs that define new
objects like intervals and define
how to perform arithmetic on them and how to combine them with older
objects like
floats, integers, etc. And then applications such as Newton iteration
etc. can
be used. Typically a large system built in Lisp tends to build upward
-- enhancing
the base language to be a more appropriate application-oriented framework,
and downward -- defining the important algorithms using that enhanced
framework.
Whichever, I continue to say that to conform, the implementation needs
either to implement text2interval() or to embed its syntax+semantics
of intervals within the language.
I'm not sure I understand this. If I can construct any interval
whatsoever with
containment guaranteed (or tightness guaranteed) by constructing A, B
and [A,B],
does that mean I have embedded enough to conform? While I take issue with
0.1 and "0.1" having different meanings, a program to parse "0.1" as
1/10 is just a few lines in Lisp. I am not objecting to doing the
computation,
just that it has, in Lisp, nothing to do with intervals.
- I think ILs can form the spec of the interchange format, so we don't
need to define it separately. (Text-based interchange format, that is.
Do we need to specify a binary one?)
I think the notion here is that one will need to interchange interval
data between systems written
not only in different host languages, but host languages without any
common numeric
I/O system (e.g. printf, or IEEE754 standard, or hexadecimal, or
integers as
fraction/exponent/sign ). This strikes me as quite unlikely. I
haven't thought about
the prospect of writing binary float intervals into a decimal float
interval system, but
offhand it seems that would be addressed by IEEE754 decimal spec.
Namely, if an IL represents an
interval that is exactly representable in a given type T, then the T
version of text2interval() reads it in exactly. And if T is a 754-
conforming type, it can be written out exactly as an IL using 754's
hex-significand form for the bounds (for a binary radix) or exact
decimal (for a decimal radix). This allows both (write then read)
and (read then write) to be lossless for such types
I think that lossless transmission is really not an issue for finite
floating point numbers
and thus would not be a problem for intervals, with the possible
exception of NaNs
with payloads. These may simply not be transmissible without loss of a
payload.
For example, I have used NaN's payloads to encode memory addresses (the
program counter when an arithmetic instruction created the NaN). I
would not
expect such information to survive being written out and read by another
system.
RJF
Regards
John Pryce