Update of /cvsroot/monetdb/MonetDB5/src/modules/kernel
In directory sc8-pr-cvs16.sourceforge.net:/tmp/cvs-serv12994/src/modules/kernel

Modified Files:
      Tag: MonetDB_5-4
        algebra.mx counters.mx group.mx mkey.mx 
Log Message:
more texi fixes


Index: mkey.mx
===================================================================
RCS file: /cvsroot/monetdb/MonetDB5/src/modules/kernel/mkey.mx,v
retrieving revision 1.37
retrieving revision 1.37.2.1
diff -u -d -r1.37 -r1.37.2.1
--- mkey.mx     11 Jan 2008 10:41:36 -0000      1.37
+++ mkey.mx     7 Feb 2008 08:23:29 -0000       1.37.2.1
@@ -61,7 +61,7 @@
 comment "pre:  h and b should be synced on head
          post: [:xor=]([:rotate=](h, nbits), [hash](b))";
 
[EMAIL PROTECTED]
[EMAIL PROTECTED] The Problem
 @}
 When creating a join, we want to make a unique key of the attributes on both
 sides and then join these keys. Consider the following BATs.
@@ -104,7 +104,7 @@
 by the command hash(). Hence, we do hash on both sides, and join
 that together with a simple join:
 
-join(hash(keys), hash(keys.reverse);
[EMAIL PROTECTED](hash(keys), hash(keys.reverse);}
 
 One complication of this procedure are nil values:
 @table

Index: algebra.mx
===================================================================
RCS file: /cvsroot/monetdb/MonetDB5/src/modules/kernel/algebra.mx,v
retrieving revision 1.192
retrieving revision 1.192.2.1
diff -u -d -r1.192 -r1.192.2.1
--- algebra.mx  11 Jan 2008 10:41:35 -0000      1.192
+++ algebra.mx  7 Feb 2008 08:23:28 -0000       1.192.2.1
@@ -246,9 +246,13 @@
 
 @+ Set operations
 Sets in Monet can be viewed in two ways:
-(1) by looking at both columns of a BAT together (Set-, or s-operators).
-(2) by looking at the head column only (Key- or k-operators).
-(3) by looking at the tail column only (Tail key- or t-operators).
[EMAIL PROTECTED]
[EMAIL PROTECTED]
+by looking at both columns of a BAT together (Set-, or s-operators).
[EMAIL PROTECTED]
+by looking at the head column only (Key- or k-operators).
+by looking at the tail column only (Tail key- or t-operators).
[EMAIL PROTECTED] itemize
 For this reason, all standard set operations come in three flavors:
 [EMAIL PROTECTED] series, which look only at the head column, 
 [EMAIL PROTECTED] series, which look only at the tail column, and
@@ -267,14 +271,14 @@
 @end itemize
 Implementations typically take two forms: if the input relation(s) is/are
 ordered, a merge-algorithm is used. Otherwise, hash-indices are produced
-on demand for the hash-based [EMAIL PROTECTED]
+on demand for the hash-based algorithms.
 The [k,s]intersect(l,r) operations result in all BUNs of @emph{l} that
-are also in @emph{r}. They do not do double-elimination over the @emph{l} 
[EMAIL PROTECTED]
+are also in @emph{r}. They do not do double-elimination over the @emph{l} BUNs.
 The [k,s]difference(l,r) operations result in all BUNs of @emph{l} that are
-not in @emph{r}. They do not do double-elimination over the @emph{l} [EMAIL 
PROTECTED]
-The [k,s]union(l,r) operations result in all BUNs of l that are 
-not in @emph{r}, plus all BUNs of @emph{r}. They do not do double-elimination
-over the @emph{l} nor @emph{r} [EMAIL PROTECTED]
+not in @emph{r}. They do not do double-elimination over the @emph{l} BUNs.
+The [k,s]union(l,r) operations result in all BUNs of l, plus all BUNs
+of @emph{r} that are not in @emph{l}. They do not do double-elimination
+over the @emph{l} nor @emph{r} BUNs.
 Operations with double-elimination can be formed by performing
 [k,s]unique(l) on their operands.
 The kintersect(l,r) is used also as implementation for the
@@ -658,7 +662,7 @@
 
 @- Default Min and Max
 Implementations a generic Min and Max routines get declared first. The
[EMAIL PROTECTED] min()} and @emph{ max()} routines below catch any tail-type.
[EMAIL PROTECTED]()} and @emph{max()} routines below catch any tail-type.
 The type-specific routines defined later are faster, and will
 override these any implementations.
 @mal
@@ -765,35 +769,36 @@
 column (ordered(BAT)). Tail columns can be described by
 using the mirror BAT with the minus operator (ordered(-BAT)).
 
[EMAIL PROTECTED] Column Properties
 @table @code
[EMAIL PROTECTED](BAT) :bit]
[EMAIL PROTECTED] [ordered(BAT) :bit]
        TRUE if the head column is stored in ascending order, else FALSE.
[EMAIL PROTECTED](BAT) :bit]
[EMAIL PROTECTED] [keyed(BAT) :bit]
        TRUE if no duplicates are present in the head column, else FALSE.
[EMAIL PROTECTED](BAT) :bit]
[EMAIL PROTECTED] [idx(BAT) :bit]
        TRUE if a binary index tree search accelerator is present on
        the head column of the BAT, else FALSE.
[EMAIL PROTECTED](BAT) :bit] 
-               presence of hash table on the head column of
-               a BAT. TRUE if a bucket-chained hash table search accelerator is
-               present on the head column of the BAT, else FALSE.
[EMAIL PROTECTED](BAT, BAT) :bit]
[EMAIL PROTECTED] [hashtab(BAT) :bit] 
+       presence of hash table on the head column of
+       a BAT. TRUE if a bucket-chained hash table search accelerator is
+       present on the head column of the BAT, else FALSE.
[EMAIL PROTECTED] [subcol(BAT, BAT) :bit]
        TRUE if the bag of all values in the head column of the left BAT is
        a bag-subset of the bag of all values in the head column of the
        right BAT, else FALSE.
[EMAIL PROTECTED](BAT) :oid]
[EMAIL PROTECTED] [sync(BAT) :oid]
        Sync-OID on the head column of a BAT. A sync-OID denotes some unique
        sequence of values. If two columns have the same sync-OID, then they
        are guaranteed to contain the same values, in the same sequence.
 
[EMAIL PROTECTED](BAT) :int]
[EMAIL PROTECTED] [size(BAT) :int]
        The (estimated) length of a column.
[EMAIL PROTECTED](BAT) :int]
[EMAIL PROTECTED] [unique(BAT) :int]
        The (estimated) number of distinct values in one column.
[EMAIL PROTECTED](BAT, BAT) :bit]
[EMAIL PROTECTED] [subset(BAT, BAT) :bit]
        TRUE if the left BAT is a subset of the BUNs of the right BAT,
        else FALSE.
[EMAIL PROTECTED](BAT) :bit]
[EMAIL PROTECTED] [setunique(BAT) :bit]
        TRUE if the BAT contains no duplicate BUNs, else FALSE.
 @end table
 

Index: group.mx
===================================================================
RCS file: /cvsroot/monetdb/MonetDB5/src/modules/kernel/group.mx,v
retrieving revision 1.105.2.3
retrieving revision 1.105.2.4
diff -u -d -r1.105.2.3 -r1.105.2.4
--- group.mx    6 Feb 2008 20:33:48 -0000       1.105.2.3
+++ group.mx    7 Feb 2008 08:23:29 -0000       1.105.2.4
@@ -40,7 +40,7 @@
 schemes at the MAL level.
 
 The prime limitation of the current implementation is that an
-underlying database of @{oid->[EMAIL PROTECTED] BATs is assumed.
+underlying database of @code{oid->any} BATs is assumed.
 This enables representation of each group using an oid,
 and the value representation of the group can be accordingly be
 retrieved easily. An optimized implementation in which we use positional
@@ -70,8 +70,8 @@
 to derive a new GRP BAT for the subgroups. After all groups have been
 identified this way, a BAT histogram operation can be used to obtain
 the counts of each data cube. Other aggregation operations using the MIL
-set aggregate construct @[EMAIL PROTECTED](bat) 
-can be used as well; note for instance that histogram == @[EMAIL 
PROTECTED](b.reverse()).
+set aggregate construct @[EMAIL PROTECTED]@}(bat)} 
+can be used as well; note for instance that @code{histogram == @[EMAIL 
PROTECTED](b.reverse())}.
 
 The Monet interface module specification is shown below.
 Ideally we should defined stronger type constraints, e.g.

Index: counters.mx
===================================================================
RCS file: /cvsroot/monetdb/MonetDB5/src/modules/kernel/counters.mx,v
retrieving revision 1.23.2.1
retrieving revision 1.23.2.2
diff -u -d -r1.23.2.1 -r1.23.2.2
--- counters.mx 6 Feb 2008 14:45:39 -0000       1.23.2.1
+++ counters.mx 7 Feb 2008 08:23:28 -0000       1.23.2.2
@@ -33,12 +33,10 @@
 @itemize
 @item @url{http://www.cse.msu.edu/~enbody/perfmon.html,libperfmon } libperfex 
(IRIX) for R10000/R12000,
 @item (Solaris <= 7) by Richard Enbody, libcpc (Solaris >= 8) for 
UltraSparcI/II,
[EMAIL PROTECTED] @url{http://qso.lanl.gov/~mpg/pperf.html,libpperf} 
(Linux-i?86 <= 2.2), by M. Patrick Goda and Michael S. Warren,
[EMAIL PROTECTED] @url{http://www.csd.uu.se/~mikpe/linux/perfctr/,libperfctr} 
(Linux-i?86 >= 2.4), by M. Pettersson for Pentiums & Athlons.
[EMAIL PROTECTED] @url{http://user.it.uu.se/~mikpe/linux/perfctr/,libperfctr} 
(Linux-i?86 >= 2.4), by M. Pettersson for Pentiums & Athlons.
 @item @url{http://www.hpl.hp.com/research/linux/perfmon/, libpfm} (Linux-ia64 
>= 2.4), by HP for Itanium[2].
 @end itemize
 
-
 Module counters provides similar interface and facilities as Peter's
 R10000 perfex module, but it offers no multiplexing of several events;
 only two events can be monitored at a time.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Monetdb-checkins mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/monetdb-checkins

Reply via email to