Boost logo

Boost-Commit :

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]


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