| Home | Libraries | People | FAQ | More

### Segmentational Fineness

For overloading tables on infix operators, we need to break down `interval_sets` and `interval_maps` to the specific class templates

S1 | `interval_set` | S2 | `separate_interval_set` | S3 | `split_interval_set`
M1 | `interval_map` |  |  | M3 | `split_interval_map`

choosing Si and Mi as placeholders.

The indices i of Si and Mi represent a property called segmentational fineness or short fineness, which is a type trait on interval containers.

`segmentational_fineness<`Si`>::value` == i
`segmentational_fineness<`Mi`>::value` == i

Segmentational fineness represents the fact, that for interval containers holding the same elements, a splitting interval container may contain more segments as a separating container which in turn may contain more segments than a joining one. So for an

    operator >

where

    x > y   // means that
    x is_finer_than y

    // we have

    finer                                             coarser
    split_interval_set                           interval_set
                       > separate_interval_set >
    split_interval_map                           interval_map

This relation is needed to resolve the instantiation of infix operators e.g. `T operator + (P, Q)` for two interval container types `P` and `Q`. If both `P` and `Q` are candidates for the result type `T`, one of them must be chosen by the compiler. We choose the type that is segmentational finer as result type `T`. This way we do not loose the segment information that is stored in the finer one of the container types `P` and `Q`.

    // overload tables for
    T operator + (T, const P&)
    T operator + (const P&, T)

    element containers:     interval containers:
    +  | e b s m            +  | e  i  b  p  S1 S2 S3 M1 M3
    ---+--------            ---+---------------------------
    e  |     s              e  |             S1 S2 S3
    b  |       m            i  |             S1 S2 S3
    s  | s   s              b  |                      M1 M3
    m  |   m   m            p  |                      M1 M3
                            S1 | S1 S1       S1 S2 S3
                            S2 | S2 S2       S2 S2 S3
                            S3 | S3 S3       S3 S3 S3
                            M1 |       M1 M1          M1 M3
                            M3 |       M3 M3          M3 M3

So looking up a type combination for e.g. `T operator + (interval_map, split_interval_map)` which is equivalent to `T operator + (M1, M3)` we find for row type `M1` and column type `M3` that `M3` will be assigned as result type, because `M3` is finer than `M1`. So this type combination will result in choosing this

    split_interval_map operator + (const interval_map&, split_interval_map)

implementation by the compiler.