Re: [boost] [Review] ITL review starts today, February 18th

Subject: Re: [boost] [Review] ITL review starts today, February 18th
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2010-02-23 13:32:49

Jeff Flinn wrote:
>> For a nice and simple integral_rightopen_interval<T> the mutating
>> operations are pretty simple and you can work with a fairly minimal
>> class. If you work with arbitrary interval bounds these computations
>> can be quite nasty, so I prefer defining functions that hide the
>> distinction of cases that one always gets wrong.
> 
> Perhaps bound_type should be refactored from an enum into a class that
> provides the facilities dealing with bound-ness. I'm always suspect of
> enum's that encode type information anyway.

I was thinking that bound-ness can be factored out of the algorithms entirely by adding it to the domain type.  An underlying domain type paired with a bool expresses bound-ness.  The domain type would need traits like get_mirror(domain_type value) that returns value if we are ignoring bound-ness and returns a value with the complimentary bound-ness if we are using it.  This would simplify the implementation of the algorithms and the interval data structure and increase the usefulness of the library.

The interval map can store one domain_type value and one bool per interval it contains if bound-ness is needed and one domain_type value per interval it contains otherwise.  The other value (and bound-ness) is implied by the adjacent interval in the map.  The interval map would need to store whether the interval is empty or not associated with each entry paired with the codomain value.  That is how my interval maps work in the internal details of 2D geometry set operations.  In my case it is easy because I ignore bound-ness and the codomain type is a count and a count of zero means the interval is empty, so emptyness is implicit.  I also never interate over intervals in the map, but instead use their end points and codomain values above and below.

Regards,
Luke