[Boost-commit] svn:boost r67228 - sandbox/icl/libs/icl/doc

Subject: [Boost-commit] svn:boost r67228 - sandbox/icl/libs/icl/doc
From: afojgo_at_[hidden]
Date: 2010-12-14 09:36:47

Author: jofaber
Date: 2010-12-14 09:36:45 EST (Tue, 14 Dec 2010)
New Revision: 67228
URL: http://svn.boost.org/trac/boost/changeset/67228

Log:
Removed aggrovering neologisms in docs and examples.
Text files modified: 
   sandbox/icl/libs/icl/doc/concepts.qbk     |     6 +-                                      
   sandbox/icl/libs/icl/doc/examples.qbk     |     4 +-                                      
   sandbox/icl/libs/icl/doc/interface.qbk    |     6 +-                                      
   sandbox/icl/libs/icl/doc/introduction.qbk |     2                                         
   sandbox/icl/libs/icl/doc/semantics.qbk    |    72 ++++++++++++++++++++--------------------
   5 files changed, 45 insertions(+), 45 deletions(-)

Modified: sandbox/icl/libs/icl/doc/concepts.qbk
==============================================================================
--- sandbox/icl/libs/icl/doc/concepts.qbk	(original)
+++ sandbox/icl/libs/icl/doc/concepts.qbk	2010-12-14 09:36:45 EST (Tue, 14 Dec 2010)
@@ -180,11 +180,11 @@
 for `Maps` we want to implement ['*aggregation*] on
 the associated values for the case of collision (of key elements)
 or overlap (of key intervals), which has been refered to as 
-['*aggregate on overlap*] or ['*aggrovering*] above.
+['*aggregate on overlap*] above.
 This kind of `Addability` and `Subtractability` allows to compute
 a lot of useful aggregation results on an __itv_map_s__ associated
 values, just by adding and subtracting value pairs. 
-Various examples of ['*aggrovering*] are given in 
+Various examples of ['*aggregate on overlap*] are given in 
 [link boost_icl.examples section examples].
 In addition, this concept of `Addability` and `Subtractability`
 contains the classical `Insertability` and `Erasability` of
@@ -418,7 +418,7 @@
 
 A map that is modelled in this way, is one large vector with
 a value `v` for every key `k` of it's domain type `DomainT`.
-But only protonic value are actually stored.
+But only non-identity values are actually stored.
 This is the motivation for the definedness-Trait on `icl Maps`.
 
 A ['*partial*] map models the intuitive view that only value

Modified: sandbox/icl/libs/icl/doc/examples.qbk
==============================================================================
--- sandbox/icl/libs/icl/doc/examples.qbk	(original)
+++ sandbox/icl/libs/icl/doc/examples.qbk	2010-12-14 09:36:45 EST (Tue, 14 Dec 2010)
@@ -85,10 +85,10 @@
 time, where the group of party guests changed.
 
 Party demonstrates a principle that we call 
-['*aggregate on overlap (aggrovering)*]:
+['*aggregate on overlap*]:
 On insertion a value associated to the interval is aggregated with those
 values in the interval_map that overlap with the inserted value.
-There are two behavioral aspects to ['*aggrovering*]: a ['*decompositional
+There are two behavioral aspects to ['*aggregate on overlap*]: a ['*decompositional
 behavior*] and an ['*accumulative behavior*].
 
 * The ['*decompositional behavior*] splits up intervals on the /time/ /dimension/ of the 

Modified: sandbox/icl/libs/icl/doc/interface.qbk
==============================================================================
--- sandbox/icl/libs/icl/doc/interface.qbk	(original)
+++ sandbox/icl/libs/icl/doc/interface.qbk	2010-12-14 09:36:45 EST (Tue, 14 Dec 2010)
@@ -321,9 +321,9 @@
 ``
 So a type `DomainT` that is `incrementable` will
 also have an `unit_element`. If it does not, a `unit_element` can be provided.
-An `unit_element` can be any value, that is greater as the `neutron` value
+A `unit_element` can be any value, that is greater as the `identity_element` 
 in the `Compare` order given.
-An example of a type, that has a `neutron` but no increment is
+An example of a type, that has an `identity_element` but no increment operation is
 `string`. So for `std::string` a unit_element is implemented like this:
 ``
 // Smallest 'visible' string that is greater than the empty string.
@@ -427,7 +427,7 @@
 In the icl's design we make the assumption,
 in particular for the default setting of parameters
 `Combine = `[classref boost::icl::inplace_minus inplace_plus],
-that type `CodomainT` has a neutral element or `neutron` 
+that type `CodomainT` has a neutral element or `identity_element` 
 with respect to the `Combine` functor.
 
 

Modified: sandbox/icl/libs/icl/doc/introduction.qbk
==============================================================================
--- sandbox/icl/libs/icl/doc/introduction.qbk	(original)
+++ sandbox/icl/libs/icl/doc/introduction.qbk	2010-12-14 09:36:45 EST (Tue, 14 Dec 2010)
@@ -142,7 +142,7 @@
 [h4 Aggregate on Overlap]
 
 This is a first motivating example of a very small party, demonstrating the 
-['*aggregate on overlap*] principle ['*(aggrovering)*] on __itv_maps__:
+['*aggregate on overlap*] principle on __itv_maps__:
 
 In the example Mary enters the party first. She attends during the 
 time interval `[20:00,22:00)`. Harry enters later. He stays within `[21:00,23:00)`.

Modified: sandbox/icl/libs/icl/doc/semantics.qbk
==============================================================================
--- sandbox/icl/libs/icl/doc/semantics.qbk	(original)
+++ sandbox/icl/libs/icl/doc/semantics.qbk	2010-12-14 09:36:45 EST (Tue, 14 Dec 2010)
@@ -142,7 +142,7 @@
 
 For the operation ['*set union*] available as 
 `operator +, +=, |, |=` and the neutral element
-`neutron<S>::value()` which is the empty set `S()`
+`identity_element<S>::value()` which is the empty set `S()`
 these laws hold:
 ``
 Associativity<S,+,== >: S a,b,c; a+(b+c) == (a+b)+c
@@ -399,10 +399,10 @@
 This problem can be dealt with in two ways. 
 
 # Deleting value pairs form the Collector, if it's associated value 
-  becomes a neutral value or `neutron`.
-# Using a different equality, called protonic equality in the laws
-  to validate. Protonic equality only 
-  accounts for value pairs that that carry values unequal to the `neutron` value. 
+  becomes a neutral value or `identity_element`.
+# Using a different equality, called distinct equality in the laws
+  to validate. Distinct equality only 
+  accounts for value pairs that that carry values unequal to the `identity_element`. 
 
 Solution (1) led to the introduction of map traits, particularly trait
 ['*partial_absorber*], which is the default setting in all icl's map
@@ -410,10 +410,10 @@
 
 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
-protonic equality in pseudocode and law denotations is denoted
-as `=p=` operator.
+identity elements. Distinct equality is implemented by a non member function
+called `is_distinct_equal`. Throughout this chapter
+distinct equality in pseudocode and law denotations is denoted
+as `=d=` operator.
 
 The validity of the sets of laws that make up `Set` semantics
 should now be quite evident. So the following text shows the
@@ -439,7 +439,7 @@
 
 All the fundamental laws could be validated for all 
 icl Maps in their instantiation as Maps of Sets or Collectors.
-As expected Inversion only holds for protonic equality,
+As expected, Inversion only holds for distinct equality,
 if the map is not a `partial_absorber`.
 
 ``
@@ -448,7 +448,7 @@
 Neutrality                   ==        ==
 Commutativity                ==   ==
 Inversion partial_absorber             ==
-          partial_enricher             =p=
+          partial_enricher             =d=
 ``
 
 [h5 Distributivity Laws]
@@ -494,9 +494,9 @@
 ``
 
 Reviewing the validity tables above shows, that the sets of valid laws for
-`icl Sets` and `icl Maps of Sets` that are /neutron absorbing/ are exactly the same.
+`icl Sets` and `icl Maps of Sets` that are /identity 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.
+called /identity enrichers/, there are marginal semantic differences.
 
 [endsect][/ Collectors]
 
@@ -632,12 +632,12 @@
 valid for `Collectors`:
 
 ``
-                             +    &    -
-Associativity                ==   == 
-Neutrality                   ==        ==
-Commutativity                ==   ==
-Inversion absorbs_neutrons             ==
-          enriches_neutrons            =p=
+                               +    &    -
+Associativity                  ==   == 
+Neutrality                     ==        ==
+Commutativity                  ==   ==
+Inversion absorbs_identities             ==
+          enriches_identities            =d=
 ``
 
 The subset of laws, that relates to `operator +` and the neutral
@@ -656,12 +656,12 @@
 `signed Quantifiers`, the pattern of valid
 laws is somewhat different:
 ``
-                             +    &    -
-Associativity                =v=  =v=  
-Neutrality                   ==        ==
-Commutativity                ==   ==
-Inversion absorbs_neutrons             ==
-          enriches_neutrons            =p=
+                               +    &    -
+Associativity                  =v=  =v=  
+Neutrality                     ==        ==
+Commutativity                  ==   ==
+Inversion absorbs_identities             ==
+          enriches_identities            =d=
 ``
 
 The differences are tagged as `=v=` indicating, that
@@ -682,17 +682,17 @@
 
 For `operator &` the associativity is broken for all maps
 that are partial absorbers. For total absorbers associativity
-is valid for element equality. All maps having the neutron enricher
+is valid for element equality. All maps having the /identity enricher/
 Trait are associative wrt. lexicographical equality `==`.
 ``                               
-Associativity                      &
-   absorbs_neutrons && !is_total   false
-   absorbs_neutrons &&  is_total   =e=
-   enriches_neutrons               ==                  
+Associativity                        &
+   absorbs_identities && !is_total   false
+   absorbs_identities &&  is_total   =e=
+   enriches_identities               ==                  
 ``
 
 Note, that all laws that establish a commutative
-monoid for `operator +` and neutron `Q()` are valid
+monoid for `operator +` and identity element `Q()` are valid
 for `signed Quantifiers`.
 In addition symmetric difference that does not
 hold for `unsigned Qunatifiers` is valid
@@ -748,11 +748,11 @@
 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,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>`]]
+[[]                          [is model of]        [if]                         [example]]
+[[`Map<D,Monoid>`]           [`Modoid`]           []                           [`interval_map<int,string>`]]
+[[`Map<D,Set,Trait>`]        [`Set`]              [`Trait::absorbs_identities`][`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>`]]
 ]
 
 [endsect][/ Concept Induction]