Re: Motion 46: finalise interval literals, amendments
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!
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.
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.
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]".
>