Re: Motion 46: finalise interval literals, amendments

["J. Wolff von Gudenberg" <wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx>]

John,
  here is my second part of the comment on motion 46


P1788 shall provide a constructor, (converter, transformer, function)
text2intval : String -> FRbar,
                        s \mapsto X   where s is a string representing 
an interval Y
such that Y    \subseteq  X and  for all Z \in FRbar, Y \subsetq Z ==> X 
\subseteq Z

If the underlying type is IEEE754 conformant and provides the 
covertFormat function with rounding, then X =[xlo,xup] can be computed by
 xlo = convertFromDecimalCharacter_down("ylo")
 xup = convertFromDecimalCharacter_up("yup")
where "ylo","yup"  are the corresponding parts of the string s

Jürgen

Am 03.07.2013 13:31, schrieb J. Wolff von Gudenberg:
> John
> Am 03.07.2013 10:55, schrieb John Pryce:
> > Jürgen
> >
> > On 2 Jul 2013, at 21:12, Jürgen Wolff von Gudenberg wrote:
> > >   just another option would be to use different constructors
> > >         nums2interval(x)   --> [x,x]
> > >         nums2intervalwide(x)   --> [x-ulp,x+ulp]
> > >         text2interval("x")   --> [x,x] where                      is 
> > > parseFloat("x")
> > you mean x is parseFloat("x")?
> > >         text2interval(x)   --> [x-ulp,x+ulp]
> > > and then follow Ned's idea, see below.
> > > Analogously fr 2 bounds as input
> > > And then make th whole stringprocessing optional or recommended.
> > > Advantage: simpler to conform , no compiler necessary, only parseFloat,
> > > Diaadvantage different versions will show up, your arguments below
> > > just an idea
> > The big suggestion you make is
> >        make text2interval optional or recommended.
> > Who supports that? I venture to suggest prospective implementers may 
> > agree, most prospective users will disagree!
> may be
> > Rather than nums2intervalwide(x) how about providing the nextOut(xx) 
> > function of 11.10.1 as a required user-available function for any 
> > inf-sup type (or any 754-conforming one, for which nextUp and 
> > nextDown exist, so it is trivial)? At present it is just a 
> > theoretical construct. Because
> >    nums2intervalwide(x) = nextOut(nums2interval(x))
> > according to your definition I think.
> yes nextout  is already there in 11.10.1
> does it need an own subsection (between 11.11.7 and 11.11.8?)?
> > And nextOut has uses in other interval algorithms that I've seen. Now 
> > I think of it, I'm surprised no one seems to have complained about 
> > its absence.
> > I don't understand text2interval(x) --> [x-ulp,x+ulp] because 
> > text2interval has to get a string not a number.
>  I meant an enclosure of the parsed string
> perhaps better
> text2interval("x") = parseFloat("x")
> now I think we only need parseFloat
> I stop here and write a new proposal after lunch
> Jürgen
> > John
> >
> > > Am 02.07.2013 12:22, schrieb John Pryce:
> > > > P1788
> > > >
> > > > 6. I am skeptical of various "simpler" constructors that were 
> > > > proposed, e.g. Ned Nedialkov's idea to replace
> > > >    xx = text2interval("[1.2, 3.4]")
> > > > by
> > > >    xxlo = text2interval("1.2")
> > > >    xxhi = text2interval("3.4")
> > > >    xx = convexHull(xxlo,xxhi)
> > > > It's simpler for the implementer who writes text2interval, but a 
> > > > lot more complicated for the user. (And surely takes about twice as 
> > > > long, as one has to compute the upper bound of xxlo and lower bound 
> > > > of xxhi which are discarded? So would slow down the reading of a 
> > > > large interval array from a text file.) So I leave unchanged the 
> > > > basic idea of strings like "[1.2, 3.4]".

--
-                Prof. Dr. Juergen Wolff von Gudenberg
     o           Lehrstuhl fuer Informatik II
    / \          Universitaet Wuerzburg, Am Hubland, D-97074 Wuerzburg
InfoII o         Tel.: +49 931 / 31 86602 Fax ../31 86603
  / \  Uni       E-Mail:wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx
 o   o Wuerzburg