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

Re: Common interval literals



On 2015-03-10 21:28:34 -0700, Dmitry Nadezhin wrote:
> Vincent,
> 
> I tried not to deviate much from John's original text:
> 
> "If the bare interval constructor has a bare common value x, the
> decorated constructor has a decorated common value x com .
> Otherwise, it has no common value."

And this text implies the following: If the decorated constructor
has a (decorated) common value, then the bare interval constructor
has a bare common value x.

Thus, if the bare interval constructor takes in input data that are
identical to the decorated constructor[*], then this would mean that
one has potential demotion, which is bad. That's why the "except for
the decorated textToInterval(s) constructor." was added. But I think
that avoiding this demotion problem should not be restricted to the
textToInterval(s) operation; it should be general.

[*] This is an interval literal for the textToInterval constructor,
but it could also be any arbitrary object representing an interval
for some <type>ToInterval constructor, where the object could carry
what is similar to decorations in P1788.

> My primary concern is the setbased flavor. I would like that the
> standard with this value is accepted as soon as possible. The
> suggestion to forbid demotion in bare version of textToInterval(s)
> influenced behavior of the setbased flavor.

I agree that demotion for textToInterval(s) should be forbidden.
And my proposed change goes even further by allowing one to forbid
demotion in all cases.

> I understood this change and I assisted to formulate it.
> 
> Now we try to clean flavor-independent specification
> without influence to behavior of the setbased flavor.
> I don't feel myself an expert in flavor-independent specifictions
> because there is no practice with flavors other than setbased.

On this point, I think that the flavor-independent specifications
should not be too restrictive, i.e. one should not require or forbid
too much. That's also why I proposed to drop the "Otherwise, it has
no common value [...]" requirement.

> I ask you and John to find an agreement in cleaning the common
> constructors text 9.5.

So, John, what do you think?

-- 
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)