Re: Motion 46: finalise interval literals, amendments
John & All,
On 2013-07-10, at 10:40 AM, John Pryce <j.d.pryce@xxxxxxxxxx> wrote:
> Dmitry, Michel, Richard & others
> Also Christian, as I have a conformance question.
>
> Views ASAP please, on the two alternatives mooted for (A), so we can proceed to the vote.
>
> (A)
> On 9 Jul 2013, at 07:59, Dmitry Nadezhin wrote:
>> 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 ?
>
> I don't think it's a good idea to restrict all implementations because of a feature of one language. Someone would come along with another unusual language feature and there would be no end to it.
>
> Maybe, after the definition of the 4 kinds of number literal, add
>> An implementation may make language-defined restrictions on the form of
>> number literal.
>> [Example. Some languages treat leading zero as the start of an octal number.
>> They may forbid p and q of the p/q form to start with a zero.]
>
> An alternative is Richard Fateman's suggestion (9 July): Let p and q be "integer literals" (a new category in this subclause) of the host language, instead of being decimal strings. I think that removes from 1788 the responsibility of avoiding a syntax clash. And if someone wants to write p and q in octal or hex, etc., that's OK if the host language allows it.
I am having the feeling we are going to complicate things. I would like to see a compact standard,
like a "kernel" on which to build applications. Having rational literals may be of academic interest,
but we want to "hit" industrial applications. I think we should leave out rationals at this stage.
>
> (We must require that p & q don't themselves contain '/'.)
>
> (B)
> What about restricting the size (length) of p and q? IMO an "industrial strength" implementation should not do so. But a small implementation such as for university student use may well wish to.
>
> I think this can be handled within the conformance clause. Christian, am I right one can use the notion of "conformance levels", so one can specify a subset of requirements that are what a "small" implementation must satisfy?
In my opinion, there should be one, minimalistic implementation containing
end point representation + handling infinities & NaI + decorations
and of course elementary functions and conversions.
Anything beyond that can be useful, but the bottom line is we want something working *everywhere*
with the press of the button.
I may appear extreme, but my opinion is also based on frustrations installing packages and dealing with
changing C++ compilers.
Here is an item, which is not part of the standard, but we may want to keep in mind.
In many interval algorithms, we use automatic differentiation (AD). If an AD package does not
support some of the elementary functions in the standard, then my application using AD is restricted by
the AD package.
Regards,
Ned