|
|
Boost-Commit : |
Subject: [Boost-commit] svn:boost r66402 - sandbox/icl/libs/icl/doc
From: afojgo_at_[hidden]
Date: 2010-11-04 10:16:30
Author: jofaber
Date: 2010-11-04 10:16:14 EDT (Thu, 04 Nov 2010)
New Revision: 66402
URL: http://svn.boost.org/trac/boost/changeset/66402
Log:
Itl to Icl replacements in docs.
Text files modified:
sandbox/icl/libs/icl/doc/examples.qbk | 12 +++---
sandbox/icl/libs/icl/doc/functions.qbk | 14 ++++----
sandbox/icl/libs/icl/doc/functions_addition.qbk | 10 +++---
sandbox/icl/libs/icl/doc/functions_cons_copy_dest.qbk | 2
sandbox/icl/libs/icl/doc/functions_interval_construct.qbk | 2
sandbox/icl/libs/icl/doc/functions_size.qbk | 2
sandbox/icl/libs/icl/doc/functions_symmetric_difference.qbk | 2
sandbox/icl/libs/icl/doc/implementation.qbk | 20 ++++++------
sandbox/icl/libs/icl/doc/introduction.qbk | 26 ++++++++--------
sandbox/icl/libs/icl/doc/projects.qbk | 6 +-
sandbox/icl/libs/icl/doc/semantics.qbk | 65 +++++++++++++++++++--------------------
11 files changed, 80 insertions(+), 81 deletions(-)
Modified: sandbox/icl/libs/icl/doc/examples.qbk
==============================================================================
--- sandbox/icl/libs/icl/doc/examples.qbk (original)
+++ sandbox/icl/libs/icl/doc/examples.qbk 2010-11-04 10:16:14 EDT (Thu, 04 Nov 2010)
@@ -220,7 +220,7 @@
An alternative way to choose a desired aggregation is to
instantiate an interval_map class template with an
appropriate ['*aggregation functor*]. For the most common
-kinds of aggregation the [*itl]
+kinds of aggregation the [*icl]
provides such functors as shown in the example.
Example `partys_tallest_guests.cpp` also demonstrates
@@ -308,7 +308,7 @@
the usage of `std::copy` differs from what we
are familiar with using ['containers of elements].
-* Use `itl::inserter` from `#include <boost/itl/iterator.hpp>`
+* Use `icl::inserter` from `#include <boost/icl/iterator.hpp>`
instead of `std::inserter` to call insertions on the target
interval container.
@@ -316,8 +316,8 @@
the time we will not be interested to `insert` segments
into __itv_maps__ but to __biLadd__
them, in order to generate the desired aggregation results.
- You can use `std::copy` with an `itl::adder` instead of an
- `itl::inserter` to achieve this.
+ You can use `std::copy` with an `icl::adder` instead of an
+ `icl::inserter` to achieve this.
[import ../example/std_copy_/std_copy.cpp]
[example_std_copy]
@@ -336,7 +336,7 @@
['segement type] of an interval map or the
['interval type] of an interval set.
Based on that we can use `std::transform`
-with an `itl::inserter` or `itl::adder`
+with an `icl::inserter` or `icl::adder`
to transform the user objects into interval
containers.
@@ -349,7 +349,7 @@
that uses the same data.
[/
-Instead of `itl::inserter` we could also use an `std::inserter`
+Instead of `icl::inserter` we could also use an `std::inserter`
with algorithms `std::copy` and `std::transform`.
This is ['*depreciated*], because `std::inserter` is designed for
containers of elements, where ['*exacty one*] element is inserted
Modified: sandbox/icl/libs/icl/doc/functions.qbk
==============================================================================
--- sandbox/icl/libs/icl/doc/functions.qbk (original)
+++ sandbox/icl/libs/icl/doc/functions.qbk 2010-11-04 10:16:14 EDT (Thu, 04 Nov 2010)
@@ -10,8 +10,8 @@
[section Function Reference]
Section [link boost_icl.interface.function_synopsis Function Synopsis]
-above gave an overview of the polymorphic functions of the itl.
-This is what you will need to find the desired possibilities to combine itl
+above gave an overview of the polymorphic functions of the icl.
+This is what you will need to find the desired possibilities to combine icl
functions and objects most of the time.
The functions and overloads that you intuitively expect
should be provided, so you won't need to refer to the documentation very often.
@@ -22,7 +22,7 @@
* in ['*complexity characteristics*] for certain overloads
* or if the compiler ['*refuses to resolve*] specific function application you want to use,
-refer to this section that describes the polymorphic function families of the itl
+refer to this section that describes the polymorphic function families of the icl
in detail.
[h5 Placeholders]
@@ -33,13 +33,13 @@
[h5 More specific function documentation]
This section covers the most important polymorphical and namespace global
-functions of the *itl*. More specific functions can be looked up
+functions of the *icl*. More specific functions can be looked up
in the doxygen generated
[link interval_template_library_reference reference documentation].
[section Overload tables]
-Many of the *itl's* functions are overloaded for
+Many of the *icl's* functions are overloaded for
elements, segments, element and interval containers.
But not all type combinations are provided. Also
the admissible type combinations are different for
@@ -183,14 +183,14 @@
template `K` is called `key_type`. It allows to select key-value pairs
pairs via `find(const K&)`
and to remove key-value pairs using `erase(const K&)`.
-For itl Maps we have generalized key types to a larger
+For icl Maps we have generalized key types to a larger
set of types. Not only the `key_type` (`domain_type`)
but also an interval type and a set type can be ['*key types*],
that allow for ['*selection*] and ['*removal*] of map elements
segments and submaps.
[table Selection of elements, segments and sub maps using key types
-[[ ][ __M: __itv_maps__ ][ __m: itl_map ]]
+[[ ][ __M: __itv_maps__ ][ __m: icl_map ]]
[[__e: `domain_type` ][ key value pair ][ key value pair ]]
[[__i: `interval_type` ][ interval value pair ][ ]]
[[__S: __itv_sets__ ][ interval map ][ ]]
Modified: sandbox/icl/libs/icl/doc/functions_addition.qbk
==============================================================================
--- sandbox/icl/libs/icl/doc/functions_addition.qbk (original)
+++ sandbox/icl/libs/icl/doc/functions_addition.qbk 2010-11-04 10:16:14 EDT (Thu, 04 Nov 2010)
@@ -32,7 +32,7 @@
]
-Functions and operators that implement ['*Addition*] on *itl* objects
+Functions and operators that implement ['*Addition*] on *icl* objects
are given in the table above.
`operator |=` and `operator |` are behavioral identical to
`operator +=` and `operator +`.
@@ -142,8 +142,8 @@
For the definition of admissible overloads
we separate /element containers/ from /interval containers/.
Within each group all combinations of types are supported
-for an operation, that are in line with the *itl's*
-design and the sets of laws, that establish the *itl's*
+for an operation, that are in line with the *icl's*
+design and the sets of laws, that establish the *icl's*
[link boost_icl.semantics semantics].
@@ -155,7 +155,7 @@
error prone and slows down compilation speed. Error messages
for unresolvable or ambiguous overloads are difficult
to read and understand. Therefore overloading of namespace
-global functions in the *itl* are limited to a reasonable
+global functions in the *icl* are limited to a reasonable
field of combinations, that are described here.
[endsect][/ Inplace operators]
@@ -174,7 +174,7 @@
interval value pairs (__p) which in turn is faster than
the combination of element or interval containers.
The next table shows /time complexities/ of addition for
-*itl's* element containers.
+*icl's* element containers.
Sizes `n` and `m` are in the complexity statements are sizes
of objects `T y` and `P x`:
Modified: sandbox/icl/libs/icl/doc/functions_cons_copy_dest.qbk
==============================================================================
--- sandbox/icl/libs/icl/doc/functions_cons_copy_dest.qbk (original)
+++ sandbox/icl/libs/icl/doc/functions_cons_copy_dest.qbk 2010-11-04 10:16:14 EDT (Thu, 04 Nov 2010)
@@ -18,7 +18,7 @@
[[`void T::swap(T&)`] [ ] [1] [1] [1] [1] ]
]
-All *itl* types are ['*regular types*]. They are ['*default constructible*],
+All *icl* types are ['*regular types*]. They are ['*default constructible*],
['*copy constructible*] and ['*assignable*]. On icl Sets and Maps a `swap`
function is available, that allows for *constant time* swapping of
container contents.
Modified: sandbox/icl/libs/icl/doc/functions_interval_construct.qbk
==============================================================================
--- sandbox/icl/libs/icl/doc/functions_interval_construct.qbk (original)
+++ sandbox/icl/libs/icl/doc/functions_interval_construct.qbk 2010-11-04 10:16:14 EDT (Thu, 04 Nov 2010)
@@ -75,7 +75,7 @@
We can get the library default interval type as `interval<P>::type`.
The library default uses ['*dynamically bounded intervals*]. You
can switch to ['*statically bounded intervals*] by
- `#define BOOST_ICL_USE_STATIC_BOUNDED_INTERVALS` prior to itl includes. ]]
+ `#define BOOST_ICL_USE_STATIC_BOUNDED_INTERVALS` prior to icl includes. ]]
[[``
static T right_open(const P&, const P&)
static T left_open(const P&, const P&)
Modified: sandbox/icl/libs/icl/doc/functions_size.qbk
==============================================================================
--- sandbox/icl/libs/icl/doc/functions_size.qbk (original)
+++ sandbox/icl/libs/icl/doc/functions_size.qbk 2010-11-04 10:16:14 EDT (Thu, 04 Nov 2010)
@@ -20,7 +20,7 @@
[[`size_type interval_count(const T&)`] [ ] [__O1__] [__O1__] [ ] [ ] ]
]
-For *itl* containers the single `size` function known from std containers
+For *icl* containers the single `size` function known from std containers
branches into tree to five different members functions.
The table above shows the types, `size` functions are implemented for,
together with their *complexities*. Linear complexities __On__ refer to the container's
Modified: sandbox/icl/libs/icl/doc/functions_symmetric_difference.qbk
==============================================================================
--- sandbox/icl/libs/icl/doc/functions_symmetric_difference.qbk (original)
+++ sandbox/icl/libs/icl/doc/functions_symmetric_difference.qbk 2010-11-04 10:16:14 EDT (Thu, 04 Nov 2010)
@@ -23,7 +23,7 @@
]
-Functions and operators that implement ['*symmetric difference*] on *itl* objects
+Functions and operators that implement ['*symmetric difference*] on *icl* objects
are given in the table above.
[table
Modified: sandbox/icl/libs/icl/doc/implementation.qbk
==============================================================================
--- sandbox/icl/libs/icl/doc/implementation.qbk (original)
+++ sandbox/icl/libs/icl/doc/implementation.qbk 2010-11-04 10:16:14 EDT (Thu, 04 Nov 2010)
@@ -9,21 +9,21 @@
[section Implementation]
The [link boost_icl.interface previous section] gave an overview over the interface
-of the *itl* outlining
+of the *icl* outlining
[link boost_icl.interface.class_templates class templates],
[link boost_icl.interface.associated_types associated types]
and polymorphic
[link boost_icl.interface.function_synopsis functions and operators].
In preparation to the
[link boost_icl.function_reference next section],
-that describes the *itl's* polymorphic functions in
+that describes the *icl's* polymorphic functions in
more detail together with ['*complexity characteristics*],
this section summarizes some general information on
implementation and performance.
[h5 STL based implementation]
-The *implementation* of the *itl's* containers is based on
+The *implementation* of the *icl's* containers is based on
[*std::set] and [*std::map]. So the underlying data structure of
interval containers is a red black tree of intervals or
interval value pairs.
@@ -32,7 +32,7 @@
Interval containers are then using __icl_sets__ of intervals
or __icl_maps__ of interval value pairs as implementing
containers.
-So all the ['*complexity characteristics*] of itl containers
+So all the ['*complexity characteristics*] of icl containers
are based on and limited by the ['*red-black tree implementation*]
of the underlying std::AssociativeContainers.
@@ -57,8 +57,8 @@
``
bool T::iterative_size()const; // Number of entities that can be iterated over.
``
-for all element and interval containers of the itl. So for
-complexity statements throughout the itl's documentation
+for all element and interval containers of the icl. So for
+complexity statements throughout the icl's documentation
the sizes will be `iterative_sizes` and big /O/ expressions like
__Omlgn__ will refer to sizes
``
@@ -97,7 +97,7 @@
interval containers is briefly discussed.
More information on ['*complexity characteristics*]
-of *itl's* functions is contained in section
+of *icl's* functions is contained in section
[link boost_icl.function_reference Function Reference]
@@ -171,7 +171,7 @@
[section Inplace and infix operators]
For the major operations /addition, subtraction, intersection/
-of *itl* containers and for /symmetric difference/
+of *icl* containers and for /symmetric difference/
inplace `operator`s `+= |=, -=, &=` and `^=`
are provided.
@@ -179,7 +179,7 @@
``
T& operator o= (T& object, const P& operand)
``
-the *itl* provides corresponding ['*infix*] operators.
+the *icl* provides corresponding ['*infix*] operators.
``
T operator o (T object, const P& operand){ return object o= operand; }
T operator o (const P& operand, T object){ return object o= operand; }
@@ -204,7 +204,7 @@
[h5 Time Complexity of infix `operators o`]
-The time complexity of all infix operators of the *itl*
+The time complexity of all infix operators of the *icl*
is biased by the extra copy of the `object` argument.
So all infix `operators o` are at least
/linear/ in `n = object.iterative_size()`.
Modified: sandbox/icl/libs/icl/doc/introduction.qbk
==============================================================================
--- sandbox/icl/libs/icl/doc/introduction.qbk (original)
+++ sandbox/icl/libs/icl/doc/introduction.qbk 2010-11-04 10:16:14 EDT (Thu, 04 Nov 2010)
@@ -178,7 +178,7 @@
[section Icl's class templates]
-In addition to interval containers the *itl* provides element containers
+In addition to interval containers the *icl* provides element containers
__icl_set__ and __icl_map__.
* An __icl_set__ is behavioral equal to __itv_bsets__ on the __bi_conceptual__ aspect.
@@ -189,9 +189,9 @@
named ['*aggregate on collision*] for an element container.
The following table gives an overview over the main
-class templates provided by the *itl*.
+class templates provided by the *icl*.
-[table Synopsis over the itl's class templates
+[table Synopsis over the icl's class templates
[[granularity][style] [sets] [maps] ]
[[interval] [] [__itv__] [] ]
[[] [joining] [__itv_set__] [__itv_map__] ]
@@ -217,12 +217,12 @@
[table Interval container's ways to combine intervals
[[] [joining] [separating] [splitting]]
- [[set] [[classref boost::itl::interval_set interval_set]]
- [[classref boost::itl::separate_interval_set separate_interval_set]]
- [[classref boost::itl::split_interval_set split_interval_set]]]
- [[map] [[classref boost::itl::interval_map interval_map]]
+ [[set] [[classref boost::icl::interval_set interval_set]]
+ [[classref boost::icl::separate_interval_set separate_interval_set]]
+ [[classref boost::icl::split_interval_set split_interval_set]]]
+ [[map] [[classref boost::icl::interval_map interval_map]]
[]
- [[classref boost::itl::split_interval_map split_interval_map]]]
+ [[classref boost::icl::split_interval_map split_interval_map]]]
[[] [Intervals are joined on overlap or touch\n(if associated values are equal).]
[Intervals are joined on overlap, not on touch.]
[Intervals are split on overlap.\nAll interval borders are preserved.]]
@@ -230,9 +230,9 @@
[table Interval combining styles by example
[[] [joining] [separating] [splitting]]
- [[set] [[classref boost::itl::interval_set interval_set] /A/]
- [[classref boost::itl::separate_interval_set separate_interval_set] /B/]
- [[classref boost::itl::split_interval_set split_interval_set] /C/]]
+ [[set] [[classref boost::icl::interval_set interval_set] /A/]
+ [[classref boost::icl::separate_interval_set separate_interval_set] /B/]
+ [[classref boost::icl::split_interval_set split_interval_set] /C/]]
[[]
[``
{[1 3) }
@@ -251,9 +251,9 @@
= {[1 2)[2 3)[3 4)[4 5)}``]
]
- [[map] [[classref boost::itl::interval_map interval_map] /D/]
+ [[map] [[classref boost::icl::interval_map interval_map] /D/]
[]
- [[classref boost::itl::split_interval_map split_interval_map] /E/]]
+ [[classref boost::icl::split_interval_map split_interval_map] /E/]]
[[]
[``
Modified: sandbox/icl/libs/icl/doc/projects.qbk
==============================================================================
--- sandbox/icl/libs/icl/doc/projects.qbk (original)
+++ sandbox/icl/libs/icl/doc/projects.qbk 2010-11-04 10:16:14 EDT (Thu, 04 Nov 2010)
@@ -262,14 +262,14 @@
Finally there is one important piece of meta information, we have
to provide: `mini::bits` has to be recognized as a `Set` by the
-itl code. Otherwise we can not exploit the fact that a map of
+icl code. Otherwise we can not exploit the fact that a map of
sets is model of `Set` and the resulting large_bitset would not
behave like a set. So we have to say that `mini::bits` shall be sets:
[mini_bits_is_set]
This is done by adding a partial template specialization to
-the type trait template `itl::is_set`.
+the type trait template `icl::is_set`.
For the extension of this type trait template and the result
values of inclusion_compare we need these `#includes` for the
implementation of `mini::bits`:
@@ -289,7 +289,7 @@
[import ../example/large_bitset_/large_bitset.hpp]
[large_bitset_includes]
-Besides `boost/itl/interval_map.hpp` and `bits.hpp` the most important
+Besides `boost/icl/interval_map.hpp` and `bits.hpp` the most important
include here is `boost/operators.hpp`. We use this library in order
to further minimize the code and to provide pretty extensive operator
functionality using very little code.
Modified: sandbox/icl/libs/icl/doc/semantics.qbk
==============================================================================
--- sandbox/icl/libs/icl/doc/semantics.qbk (original)
+++ sandbox/icl/libs/icl/doc/semantics.qbk 2010-11-04 10:16:14 EDT (Thu, 04 Nov 2010)
@@ -11,7 +11,7 @@
["Beauty is the ultimate defense against complexity] -- [/David Gelernter]
[@http://en.wikipedia.org/wiki/David_Gelernter David Gelernter]
-In the *itl* we follow the notion, that the semantics of a ['*concept*] or
+In the *icl* we follow the notion, that the semantics of a ['*concept*] or
['*abstract data type*] can be expressed by ['*laws*]. We formulate
laws over interval containers that can be evaluated for a given
instantiation of the variables contained in the law. The following
@@ -21,14 +21,14 @@
T a, b; a + b == b + a;
``
This can of course be coded as a proper c++ class template which has
-been done for the validation of the *itl*. For sake of simplicity
+been done for the validation of the *icl*. For sake of simplicity
we will use pseudocode here.
-The laws that describe the semantics of the *itl's* class templates
+The laws that describe the semantics of the *icl's* class templates
were validated using the Law based Test Automaton ['*LaBatea*],
a tool that generates instances for the law's variables and then
tests it's validity.
-Since the *itl* deals with sets, maps and relations, that are
+Since the *icl* deals with sets, maps and relations, that are
well known objects from mathematics, the laws that we are
using are mostly /recycled/ ones. Also some of those laws are grouped
in notions like e.g. /orderings/ or /algebras/.
@@ -37,7 +37,7 @@
[h4 Lexicographical Ordering and Equality]
-On all set and map containers of the itl, there is an `operator <`
+On all set and map containers of the icl, there is an `operator <`
that implements a
[@http://www.sgi.com/tech/stl/StrictWeakOrdering.html strict weak ordering].
[/ (see also [@http://en.wikipedia.org/wiki/Strict_weak_ordering here]).]
@@ -53,11 +53,11 @@
Transitivity<T,< > : T a,b,c; a<b && b<c implies a<c
``
-`Operator <` depends on the itl::container's template parameter
+`Operator <` depends on the icl::container's template parameter
`Compare` that implements a ['strict weak ordering] for the container's
`domain_type`.
For a given `Compare` ordering, `operator <` implements a
-lexicographical comparison on itl::containers, that uses the
+lexicographical comparison on icl::containers, that uses the
`Compare` order to establish a unique sequence of values in
the container.
@@ -102,9 +102,9 @@
For a constant `Compare` order on key elements,
member function `contained_in` that is defined for all
-itl::containers implements a
+icl::containers implements a
[@http://en.wikipedia.org/wiki/Partially_ordered_set partial order]
-on itl::containers.
+on icl::containers.
``
with <= for contained_in,
@@ -117,7 +117,7 @@
The induced equivalence is the equality of elements that
is implemented via function `is_element_equal`.
``
-//equivalence induced by the partial ordering contained_in on itl::container a,b
+//equivalence induced by the partial ordering contained_in on icl::container a,b
a.contained_in(b) && b.contained_in(a) implies is_element_equal(a, b);
``
@@ -242,11 +242,10 @@
correspond to containers according to
``
style set
-joining interval_set, itl::set
+joining interval_set
separating separate_interval_set
splitting split_interval_set
``
-where the __icl_set__ of elements can be subsumed in the `joining` rows.
Finally there are two laws that combine all three major set operations:
@@ -280,7 +279,7 @@
SymmetricDifference<S,== > : S a,b,c; (a + b) - (a & b) == (a - b) + (b - a)
``
-Finally Symmetric Difference holds for all of itl set types and
+Finally Symmetric Difference holds for all of icl set types and
lexicographical equality.
[/ pushout laws]
@@ -291,11 +290,11 @@
By definition a map is set of pairs. So we would expect maps to
obey the same laws that are valid for sets. Yet
-the semantics of the *itl's* maps may be a different one, because
+the semantics of the *icl's* maps may be a different one, because
of it's aggregating facilities, where the aggregating combiner
operations are passed to combine the map's associated values.
It turns out, that the aggregation on overlap principle
-induces semantic properties to itl maps in such a way,
+induces semantic properties to icl maps in such a way,
that the set of equations that are valid will depend on
the semantics of the type `CodomainT` of the map's associated
values.
@@ -324,7 +323,7 @@
type to a smaller set of laws and thus to a less restricted semantics.
Currently we have investigated and validated two major instantiations
-of itl::Maps,
+of icl::Maps,
* ['*Maps of Sets*] that will be called ['*Collectors*] and
* ['*Maps of Numbers*] which will be called ['*Quantifiers*]
@@ -343,7 +342,7 @@
Icl ['*Maps of Sets*] or ['*Collectors*]
are models of concept `Set`. This implies that all laws that have been
-stated as a semantics for `itl::Sets` in the previous chapter also hold for
+stated as a semantics for `icl::Sets` in the previous chapter also hold for
`Maps of Sets`.
Icl ['*Maps of Numbers*] or ['*Quantifiers*] on the contrary are not models
of concept `Set`.
@@ -369,11 +368,11 @@
set of pairs.
For instance in the pseudocode below map `m`
``
-itl::map<int,set<int> > m = {(1->{1,2}), (2->{1})};
+icl::map<int,set<int> > m = {(1->{1,2}), (2->{1})};
``
is equivalent to set `s`
``
-itl::set<pair<int,int> > s = {(1,1),(1,2), //representing 1->{1,2}
+icl::set<pair<int,int> > s = {(1,1),(1,2), //representing 1->{1,2}
(2,1) }; //representing 2->{1}
``
@@ -406,10 +405,10 @@
accounts for value pairs that that carry values unequal to the `neutron` value.
Solution (1) led to the introduction of map traits, particularly trait
-['*partial_absorber*], which is the default setting in all itl's map
+['*partial_absorber*], which is the default setting in all icl's map
templates.
-Solution (2), is applied to check the semantics of itl::Maps for the
+Solution (2), is applied to check the semantics of icl::Maps for the
partial_enricher trait that does not delete value pairs that carry
neutrons. Protonic equality is implemented by a non member function
called `is_protonic_equal`. Throughout this chapter
@@ -439,7 +438,7 @@
``
All the fundamental laws could be validated for all
-itl Maps in their instantiation as Maps of Sets or Collectors.
+icl Maps in their instantiation as Maps of Sets or Collectors.
As expected Inversion only holds for protonic equality,
if the map is not a `partial_absorber`.
@@ -495,7 +494,7 @@
``
Reviewing the validity tables above shows, that the sets of valid laws for
-`itl Sets` and `itl Maps of Sets` that are /neutron absorbing/ are exactly the same.
+`icl Sets` and `icl Maps of Sets` that are /neutron absorbing/ are exactly the same.
As expected, only for Maps of Sets that represent empty sets as associated values,
called /neutron enrichers/, there are marginal semantic differences.
@@ -516,20 +515,20 @@
The question is how subtraction should be defined here?
``
//Pseudocode:
-itl::map<int,some_number> q = {(1->1)};
+icl::map<int,some_number> q = {(1->1)};
q -= (2->1);
``
If type `some_number` is `unsigned` a /set difference/ kind of
subtraction make sense
``
-itl::map<int,some_number> q = {(1->1)};
+icl::map<int,some_number> q = {(1->1)};
q -= (2->1); // key 2 is not in the map so
q == {(1->1)}; // q is unchanged by 'aggregate on collision'
``
If `some_number` is a `signed` numerical type
the result can also be this
``
-itl::map<int,some_number> q = {(1->1)};
+icl::map<int,some_number> q = {(1->1)};
q -= (2->1); // subtracting works like
q == {(1->1), (2-> -1)}; // adding the inverse element
``
@@ -604,7 +603,7 @@
[h4 Laws for Quantifiers of unsigned Numbers]
-The semantics of itl Maps of Numbers is different
+The semantics of icl Maps of Numbers is different
for unsigned or signed numbers. So the sets of
laws that are valid for Quantifiers will be different
depending on the instantiation of an unsigned or
@@ -614,7 +613,7 @@
`Quantifier` types `Q` which are
__icl_map__`<D,N,T>`, __itv_map__`<D,N,T>` and __spl_itv_map__`<D,N,T>`
where `CodomainT` type `N` is a `Number` and `Trait` type `T` is one of
-the itl's map traits.
+the icl's map traits.
``
Associativity<Q,+,== >: Q a,b,c; a+(b+c) == (a+b)+c
@@ -628,7 +627,7 @@
Inversion<Q,-,=v= > : Q a; a - a =v= Q()
``
-For an `unsigned Quantifier`, an itl Map of `unsigned numbers`,
+For an `unsigned Quantifier`, an icl Map of `unsigned numbers`,
the same basic laws apply that are
valid for `Collectors`:
@@ -644,7 +643,7 @@
The subset of laws, that relates to `operator +` and the neutral
element `Q()` is that of a commutative monoid. This is the same
concept, that applies for the `CodomainT` type. This gives
-rise to the assumption that an itl `Map` over a `CommutativeModoid`
+rise to the assumption that an icl `Map` over a `CommutativeModoid`
is again a `CommutativeModoid`.
Other laws that were valid for `Collectors` are not valid
@@ -673,7 +672,7 @@
The differences are these:
``
+
-Associativity itl::map ==
+Associativity icl::map ==
interval_map ==
split_interval_map =e=
``
@@ -746,12 +745,12 @@
Obviously we can observe the induction of semantics
from the `CodomainT` parameter into the instantiations
-of itl maps.
+of icl maps.
[table
[[] [is model of] [if] [example]]
[[`Map<D,Monoid>`] [`Modoid`] [] [`interval_map<int,string>`]]
-[[`Map<D,Set,Trait>`] [`Set`] [`Trait::absorbs_neutrons`][`interval_map<int,itl::set<int> >`]]
+[[`Map<D,Set,Trait>`] [`Set`] [`Trait::absorbs_neutrons`][`interval_map<int,std::set<int> >`]]
[[`Map<D,CommutativeMonoid>`][`CommutativeMonoid`][] [`interval_map<int,unsigned int>`]]
[[`Map<D,CommutativeGroup>`] [`CommutativeGroup`] [`Trait::is_total`] [`interval_map<int,int,total_absorber>`]]
]
Boost-Commit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk