Re: Motion 46: finalise interval literals, amendments
Perhaps, there is an issue with leading zeroes in ratNumLit .
Let's take ratNumLit "010/011". It's value is 10/11 .
However, some languages treat leading zero as start of octal number,
so some users may expect that the value of the literal is 8/9 .
Will it be safer if we forbid leading zeros in ratNumLit ?
-Dima
----- Исходное сообщение -----
От: j.d.pryce@xxxxxxxxxx
Кому: stds-1788@xxxxxxxxxxxxxxxxx
Копия: rbk@xxxxxxxxxxxxx
Отправленные: Вторник, 2 Июль 2013 г 14:22:55 GMT +04:00 Абу-Даби, Маскат
Тема: Re: Motion 46: finalise interval literals, amendments
P1788
I attach the final version of the interval literals (ILs) subclause, after taking discussion into account. Please read the introductory paragraphs, which I have rewritten aiming to clarify several points on which there was disagreement or misunderstanding.
Chair, may we start the vote, after a day or two for final comments?
I get these pointers from the discussion. They apply mainly to ILs. They also affect I/O, but that will be a separate motion that I aim to submit shortly.
1. On balance, AGAINST the Sun notation of 1.2300 denoting [1.2299,1.2301]. I tend to agree, and think the Neumaier (Vienna) notation of 1.2300?1 is less prone to confusion once you get used to it.
2. No discussion I think, of Ned's suggestion to use the form supported by PROFIL, illustrated by
1.23456[46,89] meaning [1.2345646, 1.2345689].
It has been around for many years, and is especially useful in presenting tables of numerical results. Often it is typeset like
89
1.2345646
with the final 46 and 89 in smaller font. It's nice for output, but should this be part of the IL syntax?
If so, for K.I.S.S. reasons, it should *replace* uncertain form, so instead of 1.2300?1 (above) one would write
1.2[299,301] (*)
- note that bracket form *appends* digits to the preceding number, whereas uncertain form gives a number of ULPs *added* to the number.
I don't like this as a notation for input. Someone used to normal algebra notation might think (*) means multiplication, 1.2 times [299,301]. So I think the I/O clause should *recommend* this form be available for *output*. But it should not be used in ILs.
3. On balance, AGAINST the Rump scheme of nums2interval(oo,oo) giving [realmax,oo], and similarly for text2interval. (Pity, I rather like it.)
So I will drop that from *both* constructors. E.g. for nums2interval(oo,oo) and text2interval("[inf,inf]"), the bare version will give Empty. The decorated version will give NaI.
It was suggested that (bare) nums2interval(oo,oo) might give Entire. Discussion about 3 years ago showed both choices have advantages and disadvantages as an indicator that "something went wrong", and most people favoured Empty.
4. On balance, FOR "[Empty]", "[Entire]" instead of "Empty", "Entire". Note this is PURELY as syntax for an IL. Someone thought I wanted to change Empty to [Empty] throughout the standard text. No!
5. On balance, AGAINST Ian McIntosh's constructors with an accuracy or precision argument.
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]".
Regards
John Pryce