Re: dependent and independent intervals, proposal to toss out text2interval. Was re: about emp (was: Motion 42:no)
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.
On 20 Feb 2013, at 15:37, Richard Fateman wrote:
> 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.
This seems a VERY important point. From your implementation viewpoint -- and also so that one can reason about the behaviour of a conforming implementation -- the standard must specify an "upper bound" on any options.
For text2interval(s) where s is a string, here are some possible upper bounds.
(a) No options. Only the mandatory syntax in 11.11.1 (of draft 7.0).
(b) Permit the "enhanced syntax" in 11.11.1, but tighten up its specification to disallow many of the possibilities that have been discussed recently.
(c) Permit arbitrary arithmetic expressions (of some defined syntax) within s, as in text2interval("0.1+pi") and other more exotic examples discussed.
K.I.S.S. With respect, I think (c) is way beyond the bounds of reason, and the discussion of it has only served to confirm this.
I favour (b) in some form. Here's the list of options from 11.11.1:
> (1) Alternative syntax for floating literals (e.g., that of Ada) may be provided.
> (2) sp should be allowed to be a sequence of zero or more language-defined white-space characters.
> (3) Other ways of denoting an interval (besides inf-sup and mid-rad) may be provided.
> (4) Locale-dependent variations may be provided.
> (5) Floating literals may include denotations of real constants such as Pi denoting π.
> (6) The inf-sup style [ x ] should be provided, with the same meaning as [ x , x ].
I call on you experts to harden these options up, possibly delete some of them, and possibly move some of them to the "required" category.
- (2), (6) look simple and unambiguous to me.
- For (1), I did not intend that floating literal syntax should permit arbitrary expressions -- not even ones as simple as "0.1+pi" or "1+1e-10". I meant that there should be an option to accept (floating literals as defined by the underlying language of the implementation), instead of -- not alongside -- those defined in 11.11.1. Is that sensible?
- (3) clearly opens "an arbitrary can of worms". So either delete it, or restrict to one or two specified alternatives, e.g. §6.4 "Uncertain numbers" and/or §6.5 "Exact numbers" in Arnold Neumaier's Vienna proposal. (Richard, you can get this from the position papers on the P1788 web site.)
- (4) I meant, allow to use a decimal comma instead of decimal point, and similar trivialities.
- (5) I meant here
{enhanced floating literals} = {required floating literals} union C,
where C is some finite set of (denotations of) real constants. I did not mean that a floating literal can be an expression in which one of these constants occurs.
> 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 ...
It may look like that just now, but be assured decorations are not optional. The basic structure of the decoration system is fixed and is not changed by, e.g., the proposed removing "emp" from the set of decorations. Yes, the coupling is such that you can implement bare intervals first, and add decorations later.
> 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.
I agree. But we may disagree on what counts as "not well understood".
John