Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Motion P1788.1/M005 to avoid non-conforming interval standards



Am 17. August 2016 09:47:20 MESZ, schrieb Walter Mascarenhas <walter.mascarenhas@xxxxxxxxx>:
>Dear all,
>
>  I plan to finish an implementation of 1788.1 "soon", and it would be
>helpful to have an explicit list of test cases describing the expected
>behaviour of constructors with arguments of the form
>
>                strings for for inf and sup  +
>       expected result (including exceptions raised)
>            mathematical relation between inf and sup
>
>[ regular expression for inf, regular expression for sup]        this
>for
>bare intervals, that for decorated intervals
>                         +
>       a bit of math involving inf and sup
>
>could you please provide me such a list? The more comprehensive the
>better.
>
>             regards,
>
>                      walter.
>
>
>
>
>
>On Wed, Aug 17, 2016 at 1:44 AM, Dmitry Nadezhin
><dmitry.nadezhin@xxxxxxxxxx
>> wrote:
>
>> Hi Ned,
>>
>> > As I understand you propose the following.
>>
>> In item 3 case is about string not about implementations.
>> So I would say:
>>
>> -----
>>
>> 3. If a string matches the syntax, we have two cases.
>>
>>    a) A string doesn't contain rational number literal or both
>decimal and
>> hexadecimal number literals.
>>     Then 1788.1 constructor behaves as in 1788.
>>
>>    b) An string contains rational number literal or both decimal and
>> hexadecimal number literals.
>>
>>    If s is a string with level 1 value x, then 1788.1 level 2
>constructor
>>    may return *any* interval containing x.
>>
>>    If s = [l,u] is not an interval literal because l > u, then level
>1
>>    constructor has no value. 1788.1 level 2 constructor may return
>>    either Empty/NaI or *any* interval which contains [u,l].
>>
>> -------
>>
>> > So, if we have an input containing [hex,dec], presently an
>> > implementation of IEEE P1788.1 and an implementation of IEEE P1788
>can
>> > produce different results. This can happen with your suggestion as
>> > well.
>>
>> The last paragraph of section 9.8 of 1788 says
>> "An implementation may relax at Level 2 the accuracy mode of some
>input
>> strings (too long strings or strings
>> with a rational number literal). Nevertheless, the constructor shall
>> either return a Level 2 result containing
>> the Level 1 value, or signal an exception, see 7.5.3."
>> So implementation of 1788 may have behavior (3b). It is relaxation of
>> accuracy mode.
>>
>> However, accuracy can't be worse than "valid" (see 7.5.4).
>> If 1788 constructor would return Empty on string "[ 0x0p0 , 1]",
>> then it is not relaxation of accuracy mode. It is containment
>violation.
>>
>> Best Regards,
>>   Dima
>>
>>
>>
>>
>>
>> ----- Original Message -----
>> From: nedialk@xxxxxxxxxxx
>> To: dmitry.nadezhin@xxxxxxxxxx
>> Cc: stds-1788@xxxxxxxxxxxxxxxxx
>> Sent: Saturday, August 13, 2016 2:50:25 PM GMT +03:00 Iraq
>> Subject: Re: Motion P1788.1/M005 to avoid non-conforming interval
>standards
>>
>>
>> Hi Dmitry,
>>
>> Thank your for your suggestions. As I understand you propose the
>> following. (Please correct me if I misunderstood something).
>>
>> 1. The text for interval literals in 1788.1 should be the same as in
>> 1788; that is, we have the same syntax.
>>
>> 2. If a string (input to 1788.1 implementation) does not match the
>> syntax, a constructor in 1788.1 behaves in the same way as in 1788.
>>
>> 3. If a string matches the syntax, we have two cases.
>>
>>    a) An implementation of a 1788.1 constructor is not relaxed. Then
>>    it behaves as in 1788.
>>
>>    b) An implementation of a 1788.1 constructor is relaxed (not
>>    supporting rational and hex numbers).
>>
>>    If s is a string s with level 1 value x, then level 2 constructor
>>    may return *any* interval containing x.
>>
>>    If s = [l,u] is not an interval literal because l > u, then level
>1
>>    constructor has no value. 1788.1 level 2 constructor may return
>>    either Empty/NaI or *any* interval which contains [u,l].
>>
>>
>> ====
>>
>> My preference would be to keep the simpler text for the literals
>syntax
>> in 1788.1 and the rest as they are. However, I can see an issue with
>> respect to
>>
>> "A program built on top of an implementation of IEEE P1788.1 should
>> compile and run, and give identical output within roundoff, using an
>> implementation of IEEE Std 1788TM-2015, or any superset of the
>former."
>>
>> So, if we have an input containing [hex,dec], presently an
>> implementation of IEEE P1788.1 and an implementation of IEEE P1788
>can
>> produce different results. This can happen with your suggestion as
>> well.
>>
>> It seems that if the input to a 1788.1 program is valid, then "it
>should
>> compile and run, and give identical output within roundoff, using an
>> implementation of IEEE Std 1788TM-2015, or any superset of the
>> former."
>>
>> Perhaps a simple solution is to introduce "valid input" in the above
>> quoted text.
>>
>> What do we do from this point? Perhaps the Chair can give directions
>> based on procedural rules?
>>
>> Best regards,
>> Ned
>>
>>
>> > On Aug 8, 2016, at 02:45, Dmitry Nadezhin
><dmitry.nadezhin@xxxxxxxxxx>
>> wrote:
>> >
>> > I would like to suggest a solution for 1788.1 which is compatible
>> > with sections 9.8 "Constructors" and 7.5.3 "Level 2 operations"
>> > of the "General Requirements" part of the standard 1788.
>> >
>> > 1788 defines syntax of interval literal by grammar 9.7.6 .
>> > Each interval literal matches the syntax.
>> > However, there may be a string which matches the syntax but which
>is not
>> an interval literal.
>> > These are strings [l,u] where l and u are number literals but l >
>u.
>> >
>> > The syntax for Interval literals in 1788.1 would be the same as in
>1788.
>> > However 1788.1 has a relaxed support for those strings which
>> > contain rational literals or which are mixed-radix [l,u] strings
>> > where one of l or u is a decimal literal and another is a
>hexadecimal
>> literal.
>> >
>> > If string s doesn't match the syntax of 1788 interval literals
>> > level 1 constructor is undefined
>> > 1788.1 level 2 constructor must return Empty bare interval or NaI
>> decorated interval.
>> >
>> > If string s matches the syntax of 1788 interval literal and its
>support
>> by 1788.1 is not relaxed
>> > then 1788.1 must determine
>> > either string s is an interval literal
>> > or it is not an interval literal (when s=[l,u] and l>u).
>> > If it is an interval literal and its level 1 value is x
>> > then 1788.1 level 2 constructor must return hull(x).
>> > If it is not an interval literal then 1788.1 level 2 constructor
>must
>> return Empty or NaI.
>> >
>> > If string s matches the syntax of 1788 interval literal and its
>support
>> by 1788.1 is relaxed,
>> > then:
>> > a) if string s is an interval literal with level 1 value x.
>> >   1788.1 level 2 constructor may return any interval which contains
>x.
>> > b) if string s = [l,u] is not an interval literal because l > u.
>> >   Level 1 constructor has not value.
>> >   1788.1 level 2 constructor may return
>> >   either Empty/NaI
>> >   or any interval which contains [u,l] .
>> > Notice that the easiest behavior of 1788.1 level 2 constructor is
>to
>> return Entire
>> > when support of input string s is relaxed in 1788.1.
>> >
>> >  -Dima
>>

Walter,

I guess that I can prepare something for you tonight.

In the meantime, you could work on an ITF1788 plugin for your implementation.

https://github.com/oheim/ITF1788

Best
Oliver