Re: dependent and independent intervals, proposal to toss out text2interval. Was re: about emp (was: Motion 42:no)
On 2/20/2013 5:08 AM, Vincent Lefevre wrote:
On 2013-02-19 17:34:33 -0500, Michel Hack wrote:
Richard Fateman wrote:
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 requiring the library of programs
double_float_text2interval etc. to include a parser, evaluator
of arbitrary-precision (or perhaps exact rational) arithmetic,
an algebraic simplifier, and perhaps more.
The standard does not require this, but it allows it. It makes
it possible for a standard-complying implementation to offer tight
enclosures, which would not be possible if one had to go through
standard non-interval literals, which would most likely suffer
inappropriate rounding (unless one carries the context around,
as in my macro example below).
[...]
And I would add that it doesn't make the standard more complex.
It is tantamount to saying that a standards-complying program can call any
other program, in the guise of text2interval, in order to produce an
interval.
I do not know if one can include a variable name in such a string as
text2interval( "sin(x)") but presumably one can create a string by
s := concatenate("sin(" , public_format(x), ")")
t:= text2interval(s).
And then text2interval can call (say) Maple or Mathematica or some Lisp
library...
Now I do not have a problem using such a program. I do not have
a problem hypothesizing its existence. It could be used to compute, for
example, a tight interval around.
exp(sqrt(163)*pi)-262537412640768744.
In double-float this evaluates probably to about 480.
In higher precision it evaluates to about -7.5d-13
Here is the problem though.
A reference implementation, if it is to be truly useful in evaluating the
standard, should be a reference implementation for the OPTIONS
to the standard as well. Otherwise there is no rein on what can be
included in the options. Any objection to an option can be dismissed
by saying "it's only an option".
If you believe that a reference implementation should exist, then the
options, if any, should be specified sufficiently that they too can be
implemented without the considerable imagination needed here.
Again, from an implementation perspective,
there seems to be enough dispute about the handling of decorations
at this point that -- from the point of view of implementation -- it looks
more like an option tacked on to a library for bare intervals, and
should be treated as an option -- an extra layer, if you will, of
"17 byte intervals" constructed from calls to the "double-float interval"
library and some extra bookkeeping. (just to specify one particular
type). Viewed as an option, I think any set of choices would be
easy enough. I have no plan to personally figure out applications which
would
use particular decorations, so I would not be able to say if it was a good
set of ideas, just that it is not inconsistent from an implementation view.
My goal was (and still is) to write a reference implementation so that
I can understand this proposal. Leaving out parts from the implementation
seems like a bad idea from that perspective. Better to remove
things that are not well understood from the standard, it seems to me.
RJF
Moreover an arithmetic where 0.1 + pi is exactly representable
might be used, e.g. something based on Q[pi] or simpler. This
could be useful when trig functions are used. In such an
arithmetic, sqrt(cos([0,pi/2])) could be evaluated without
the drawback of some values being undefined.
Perhaps such an arithmetic hasn't been implemented yet, but the
standard (that will be there for many years in the future) should
encourage new arithmetics rather than forbidding them.