Collection concept

Description

A collection allows to access a collection of objects using an identifier or index. What this index exactly is, is defined by the encapsulated size_type. This is not necessarily an unsigned integral type such as is the case for an STL Container. For a 2D matrix for instance, the size type might be a structure containing 2 unsigned integral types. Because every structure has to be linearised to be stored in computer memory anyway, we also require the size type must be LessThanComparable. Thus the indexes, whatever they are, can be ordered. Generally the indexes should be ordered similar to the elements they are associated with.

The object associated to a specific index is fixed unless explicitly changed by the user. Maximally one object is associated to each index.

The collection is intended to be the concept that is implemented by all types of dense and sparse vectors, dense and sparse matrices (by going through all elements in column-major or row-major fashion), and all views on any of the vectors and matrices (like a row of a sparse matrix etc.)

Because this is such a fundamental concept, it was intentionally kept compatible with std::vector because, although std::vector is not ideal for use in linear algebra routines, compatibility with this frequently used data-type is highly desireable.

Refinement of

Expression, Assignable.

Any Expression is convertible to a Collection, when the Expression's value_type is convertible to the Collection's value_type and when their rank is equal.

Associated types

Notation

`X`	Type that is a model of Collection
`E`	Type that is a model of Expression and `value<E>::type` is convertible to `value<X>::type`
`a,b`	Objects of type `X`
`e`	Objects of type `E`

Definitions

Valid expressions

In addition to those of Expression, Assignable:

Name	Expression	Type requirements	Return type
Assignment	`a=b`		`X&`
Conversion constructor	`X a(e)`	`value<E>:type is convertible to value<X>::type`	`X&`
Conversion assignment	`a=e`	`value<E>::type is convertible to value<X>::type`	`X&`

Expression semantics

Name	Expression	Precondition	Semantics	Postcondition
Assignment	`a=b`	`size(a)==size(b)[2]`	The assignment is already in the concept because this concept is a refinement of Assignable. The reason why the assignment is repeated here is because there is an additional precondition.	`v==w`
Conversion constructor	`X a(e)`	`size(a)==size(e)`		`e==a` NOT POSSIBLE (YET)?
Conversion assignment	`a=e`	`size(a)==size(e)`

Complexity guarantees

Invariants

After assigning one collection to another (a=b), they should be equal (a==b) afterwards. This way the Assignable concept interacts with the EqualityComparable concept.

Models

Notes

[1] The sizes of the object's are required to be equal because this simplifies/optimises the implementation. Additionally, moving for instance a vector from one vector space to another is usually undesired if not stated explicitly. If the user wants to adapt the size of the lhs anyway, this can easily be accomplished by doing v.resize(w.size());v=w. Next automatically resizing a vector range might result in a vector range that is out of bounds with the vector on which it is defined.

[2] If we require the sizes of both objects in assignment to be equal, it's only logic that the same precondition holds for the equality operator. To bypass this precondition one can also v.size()==w.size() ? v == w : false ;