Re: Difficulties in implementation of textToInterval(s)
Hi Dmitry (et al)
> On May 21, 2016, at 09:13, Dmitry Nadezhin <dmitry.nadezhin@xxxxxxxxxx> wrote:
>
> The section 12.12.7 of the original IEEE 1788 standard has the text
> about "difficulties in implementation".
> It explains difficulties of testing the condition "l <= u".
> Later in the text it allows constructors to succeed ("false positives")
> when l and u are close to each other
> and implementation can't determine for sure that "l <= u".
> The condition when this case might occur shall be documented.
> PossiblyUndefinedOperation exception must be signaled in this case.
>
> This difficulty doesn't happen in P1788.1 with numsToInterval(l,u) constructor
> because l and u are both b64 numbers.
>
> However, it might happen in P1788.1 with textToInterval(s) constructor.
> The P1788.1 omits the text about "difficulties in implementation" and about PossiblyUndefinedOperation.
> The section 6.7.4 of the suggested Level2 chapter of P1788.1 requires stricter behaviour.
> It requires textToInterval(s) to fail and to return empty interval when s is not valid.
> The section 6.6.2 says that an interval literal [l,u] is valid iff "l <= u".
> So the operation textToInterval(s) for some inputs is more expensive in P1788.1 than in P1788.
> Is it intentional project decision of P1788.1 ?
Very subtle point, and thank you for spotting this. My rationale was that if l and u are decimal strings we can determine if l<=u, unless I am missing something. But then we added back the hex literals, so
if one is decimal (l or u) and the other one hex, then it might be difficult.
Ned