[std-interval] Mathematical relations and default initialization

[Sylvain Pion]

Guillaume Melquiond wrote:
> Le jeudi 14 septembre 2006 à 10:21 +0200, Frédéric Goualard a écrit :
> 
>> The nth_root_rel() operator does not appear in the standard. Is this
>> omission on purpose? If indeed it is, why is it so?
> 
> The nth_root_rel is purposely out of the proposal because nth_root is
> out too :-). I don't think the omission is on purpose though. If people
> feel it is useful, it can be added.

Let's be careful with the list of functions, especially those hard
to implement.  Having too many may trigger resistance from the C++
committee.  I already fear that the changes done in the revision
won't be appreciated a lot on that aspect...  But we'll see.


>> * Default initialization
>> I see on page 15 that the default constructor creates an empty interval.
>>  At some point in the discussion, Sylvain gave 6 possible ways of
>> implementing this constructor:
>>
>> 1- no default constructor at all
>> 2- [0,0]
>> 3- empty
>> 4- whole
>> 5- uninitialized tag
>> 6- see below (something a la "singular iterator")
>>
>> Possibility 4 was brushed away from the start, and the remaining
>> possibilities heavily debated. In my opinion, it makes sense to have the
>> default constructor return "whole" since interval arithmetic is often
>> used in processes that try to gain some information on the possible
>> value of a variable (that is, we start from a wide interval and narrow
>> it down to some reasonably small one).
> 
> I don't remember 4 being brushed right away (proposition 1 was). As a
> matter of fact, propositions 3 and 4 have reached a point in my opinion
> where I consider them to be equally useful. So, at least on my side, it
> is still 4 in the proposal, only because of inertia.

As George says, there is indeed no perfect choice.  I can see good
arguments supporting 2, 3, 4, 6 (I see 5 as a debug mode allowed by 6).

The debug mode, 5, (e.g. using a tag) can be envisioned for the
other cases than 6 as well, but then it's not a bug anymore to not
initialize, so it might become hard to distinguish forgotten
initializations from correct code assuming the documented default
constructed value.

"empty" can help for propagating uninitialized-ness, as George
mentioned, and it was my argument for picking this choice in the
proposal.  But it's incomplete, since there are cases where it
does not propagate (e.g. with branches).
(while at it : concerning the propagation of empty, the current
proposal does not say anything, since any function taking empty
can return any interval: are there opinions on the sharpness of
returned intervals in this case?  we could easily enforce empty
as returned interval)

6 also has the advantage of speed, I'm thinking especially of array
initialization.

I'm not very convinced by the arguments which have been given so
far in favor of "whole", because I think they mix the correctness
issue of forgotten initializations, with the preferred value of
the initializations of variables in *some* algorithms.
Such algorithms should initialize variables explicitly to "whole",
IMO.  And given that there is no clear intuitive default, users
will never remember that "whole" is used as default value, so
in practice it will be better to use "whole" explicitly anyway
for these cases, so no need to make it the default constructed
value.  If somebody thinks it would be too inconvenient to require
an explicit initialization to "whole" for some codes, I would be
interesting in seeing such codes.

My personal preference goes to 6 (i.e. producing an "uninitialized
interval", similar to the behavior of iterators, that is, only
copies/assignments are allowed on them, basically).

-- 
Sylvain