Re: Motion 46: finalise interval literals, amendments
On 2013-07-04, at 6:24 PM, "J. Wolff von Gudenberg" <wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> John,
> here is my second part of the comment on motion 46
>
>
> If the underlying type is IEEE754 conformant and provides the covertFormat function with rounding,
I should check this myself, but I don't recall IEEE requiring directed roundings when converting a string
to say double.
> 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
>
If such two functions are present, I am very satisfied.
Ned
> 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