head	1.9;
access;
symbols
	REL9_0_0:1.7.8.2
	REL9_1_ALPHA1:1.9
	REL9_0_RC1:1.7.8.2
	REL9_0_BETA4:1.7.8.1
	REL9_0_STABLE:1.7.0.8
	REL9_0_BETA3:1.7
	REL9_0_BETA2:1.7
	REL8_3_11:1.5
	REL8_4_4:1.6.2.1
	REL9_0_BETA1:1.7
	REL9_0_ALPHA5_BRANCH:1.7.0.6
	REL9_0_ALPHA5:1.7
	REL8_3_10:1.5
	REL8_4_3:1.6.2.1
	REL9_0_ALPHA4:1.7
	REL9_0_ALPHA4_BRANCH:1.7.0.4
	REL8_5_ALPHA3:1.7
	REL8_5_ALPHA3_BRANCH:1.7.0.2
	REL8_3_9:1.5
	REL8_4_2:1.6.2.1
	REL8_5_ALPHA2:1.6
	REL8_5_ALPHA2_BRANCH:1.6.0.6
	REL8_3_8:1.5
	REL8_4_1:1.6
	REL8_5_ALPHA1:1.6
	REL8_5_ALPHA1_BRANCH:1.6.0.4
	REL8_4_STABLE:1.6.0.2
	REL8_4_0:1.6
	REL8_4_RC2:1.6
	REL8_4_RC1:1.6
	REL8_4_BETA2:1.5
	REL8_4_BETA1:1.5
	REL8_3_7:1.5
	REL8_3_6:1.5
	REL8_3_5:1.5
	REL8_3_4:1.5
	REL8_3_3:1.5
	REL8_3_2:1.5
	REL8_3_1:1.5
	REL8_3_STABLE:1.5.0.2
	REL8_3_0:1.5
	REL8_3_RC2:1.5
	REL8_3_RC1:1.5
	REL8_3_BETA4:1.2
	REL8_3_BETA3:1.2;
locks; strict;
comment	@# @;


1.9
date	2010.08.17.04.37.20;	author petere;	state Exp;
branches;
next	1.8;

1.8
date	2010.07.29.19.34.40;	author petere;	state Exp;
branches;
next	1.7;

1.7
date	2009.12.08.20.08.30;	author mha;	state Exp;
branches
	1.7.8.1;
next	1.6;

1.6
date	2009.05.18.11.08.24;	author petere;	state Exp;
branches
	1.6.2.1;
next	1.5;

1.5
date	2007.12.06.04.12.09;	author tgl;	state Exp;
branches;
next	1.4;

1.4
date	2007.12.03.23.49.50;	author tgl;	state Exp;
branches;
next	1.3;

1.3
date	2007.12.03.03.05.47;	author tgl;	state Exp;
branches;
next	1.2;

1.2
date	2007.11.11.14.23.18;	author momjian;	state Exp;
branches;
next	1.1;

1.1
date	2007.11.10.23.30.46;	author momjian;	state Exp;
branches;
next	;

1.6.2.1
date	2009.12.08.20.08.37;	author mha;	state Exp;
branches;
next	;

1.7.8.1
date	2010.07.29.19.34.36;	author petere;	state Exp;
branches;
next	1.7.8.2;

1.7.8.2
date	2010.08.17.04.37.15;	author petere;	state Exp;
branches;
next	;


desc
@@


1.9
log
@Spell and markup checking
@
text
@<!-- $PostgreSQL: pgsql/doc/src/sgml/cube.sgml,v 1.8 2010/07/29 19:34:40 petere Exp $ -->

<sect1 id="cube">
 <title>cube</title>

 <indexterm zone="cube">
  <primary>cube</primary>
 </indexterm>

 <para>
  This module implements a data type <type>cube</> for
  representing multidimensional cubes.
 </para>

 <sect2>
  <title>Syntax</title>

  <para>
   <xref linkend="cube-repr-table"> shows the valid external
   representations for the <type>cube</>
   type.  <replaceable>x</>, <replaceable>y</>, etc. denote
   floating-point numbers.
  </para>

  <table id="cube-repr-table">
   <title>Cube external representations</title>
   <tgroup cols="2">
    <tbody>
     <row>
      <entry><literal><replaceable>x</></literal></entry>
      <entry>A one-dimensional point
       (or, zero-length one-dimensional interval)
      </entry>
     </row>
     <row>
      <entry><literal>(<replaceable>x</>)</literal></entry>
      <entry>Same as above</entry>
     </row>
     <row>
      <entry><literal><replaceable>x1</>,<replaceable>x2</>,...,<replaceable>xn</></literal></entry>
      <entry>A point in n-dimensional space, represented internally as a
      zero-volume cube
      </entry>
     </row>
     <row>
      <entry><literal>(<replaceable>x1</>,<replaceable>x2</>,...,<replaceable>xn</>)</literal></entry>
      <entry>Same as above</entry>
     </row>
     <row>
      <entry><literal>(<replaceable>x</>),(<replaceable>y</>)</literal></entry>
      <entry>A one-dimensional interval starting at <replaceable>x</> and ending at <replaceable>y</> or vice versa; the
       order does not matter
      </entry>
     </row>
     <row>
      <entry><literal>[(<replaceable>x</>),(<replaceable>y</>)]</literal></entry>
      <entry>Same as above</entry>
     </row>
     <row>
      <entry><literal>(<replaceable>x1</>,...,<replaceable>xn</>),(<replaceable>y1</>,...,<replaceable>yn</>)</literal></entry>
      <entry>An n-dimensional cube represented by a pair of its diagonally
       opposite corners
      </entry>
     </row>
     <row>
      <entry><literal>[(<replaceable>x1</>,...,<replaceable>xn</>),(<replaceable>y1</>,...,<replaceable>yn</>)]</literal></entry>
      <entry>Same as above</entry>
     </row>
    </tbody>
   </tgroup>
  </table>

  <para>
   It does not matter which order the opposite corners of a cube are
   entered in.  The <type>cube</> functions
   automatically swap values if needed to create a uniform
   <quote>lower left &mdash; upper right</> internal representation.
  </para>

  <para>
   White space is ignored, so <literal>[(<replaceable>x</>),(<replaceable>y</>)]</literal> is the same as
   <literal>[ ( <replaceable>x</> ), ( <replaceable>y</> ) ]</literal>.
  </para>
 </sect2>

 <sect2>
  <title>Precision</title>

  <para>
   Values are stored internally as 64-bit floating point numbers. This means
   that numbers with more than about 16 significant digits will be truncated.
  </para>
 </sect2>

 <sect2>
  <title>Usage</title>

  <para>
   The <filename>cube</> module includes a GiST index operator class for
   <type>cube</> values.
   The operators supported by the GiST operator class are shown in <xref linkend="cube-gist-operators">.
  </para>

  <table id="cube-gist-operators">
   <title>Cube GiST operators</title>
   <tgroup cols="2">
    <thead>
     <row>
      <entry>Operator</entry>
      <entry>Description</entry>
     </row>
    </thead>

    <tbody>
     <row>
      <entry><literal>a = b</></entry>
      <entry>The cubes a and b are identical.</entry>
     </row>

     <row>
      <entry><literal>a &amp;&amp; b</></entry>
      <entry>The cubes a and b overlap.</entry>
     </row>

     <row>
      <entry><literal>a @@&gt; b</></entry>
      <entry>The cube a contains the cube b.</entry>
     </row>

     <row>
      <entry><literal>a &lt;@@ b</></entry>
      <entry>The cube a is contained in the cube b.</entry>
     </row>
    </tbody>
   </tgroup>
  </table>

  <para>
   (Before PostgreSQL 8.2, the containment operators <literal>@@&gt;</> and <literal>&lt;@@</> were
   respectively called <literal>@@</> and <literal>~</>.  These names are still available, but are
   deprecated and will eventually be retired.  Notice that the old names
   are reversed from the convention formerly followed by the core geometric
   data types!)
  </para>

  <para>
   The standard B-tree operators are also provided, for example

   <informaltable>
    <tgroup cols="2">
     <thead>
      <row>
       <entry>Operator</entry>
       <entry>Description</entry>
      </row>
     </thead>

     <tbody>
      <row>
       <entry><literal>[a, b] &lt; [c, d]</literal></entry>
       <entry>Less than</entry>
      </row>

      <row>
       <entry><literal>[a, b] &gt; [c, d]</literal></entry>
       <entry>Greater than</entry>
      </row>
     </tbody>
    </tgroup>
   </informaltable>

   These operators do not make a lot of sense for any practical
   purpose but sorting. These operators first compare (a) to (c),
   and if these are equal, compare (b) to (d). That results in
   reasonably good sorting in most cases, which is useful if
   you want to use ORDER BY with this type.
  </para>

  <para>
   <xref linkend="cube-functions-table"> shows the available functions.
  </para>

  <table id="cube-functions-table">
   <title>Cube functions</title>
   <tgroup cols="2">
    <tbody>
     <row>
      <entry><literal>cube(float8) returns cube</literal></entry>
      <entry>Makes a one dimensional cube with both coordinates the same.
       <literal>cube(1) == '(1)'</literal>
      </entry>
     </row>

     <row>
      <entry><literal>cube(float8, float8) returns cube</literal></entry>
      <entry>Makes a one dimensional cube.
       <literal>cube(1,2) == '(1),(2)'</literal>
      </entry>
     </row>

     <row>
      <entry><literal>cube(float8[]) returns cube</literal></entry>
      <entry>Makes a zero-volume cube using the coordinates
       defined by the array.
       <literal>cube(ARRAY[1,2]) == '(1,2)'</literal>
      </entry>
     </row>

     <row>
      <entry><literal>cube(float8[], float8[]) returns cube</literal></entry>
      <entry>Makes a cube with upper right and lower left
       coordinates as defined by the two arrays, which must be of the
       same length.
       <literal>cube('{1,2}'::float[], '{3,4}'::float[]) == '(1,2),(3,4)'
       </literal>
      </entry>
     </row>

     <row>
      <entry><literal>cube(cube, float8) returns cube</literal></entry>
      <entry>Makes a new cube by adding a dimension on to an
       existing cube with the same values for both parts of the new coordinate.
       This is useful for building cubes piece by piece from calculated values.
       <literal>cube('(1)',2) == '(1,2),(1,2)'</literal>
      </entry>
     </row>

     <row>
      <entry><literal>cube(cube, float8, float8) returns cube</literal></entry>
      <entry>Makes a new cube by adding a dimension on to an
       existing cube. This is useful for building cubes piece by piece from
       calculated values. <literal>cube('(1,2)',3,4) == '(1,3),(2,4)'</literal>
      </entry>
     </row>

     <row>
      <entry><literal>cube_dim(cube) returns int</literal></entry>
      <entry>Returns the number of dimensions of the cube
      </entry>
     </row>

     <row>
      <entry><literal>cube_ll_coord(cube, int) returns double </literal></entry>
      <entry>Returns the n'th coordinate value for the lower left
       corner of a cube
      </entry>
     </row>

    <row>
      <entry><literal>cube_ur_coord(cube, int) returns double
      </literal></entry>
      <entry>Returns the n'th coordinate value for the
       upper right corner of a cube
      </entry>
     </row>

     <row>
      <entry><literal>cube_is_point(cube) returns bool</literal></entry>
      <entry>Returns true if a cube is a point, that is,
       the two defining corners are the same.</entry>
     </row>

     <row>
      <entry><literal>cube_distance(cube, cube) returns double</literal></entry>
      <entry>Returns the distance between two cubes. If both
       cubes are points, this is the normal distance function.
      </entry>
     </row>

     <row>
      <entry><literal>cube_subset(cube, int[]) returns cube
      </literal></entry>
      <entry>Makes a new cube from an existing cube, using a list of
       dimension indexes from an array. Can be used to find both the LL and UR
       coordinates of a single dimension, e.g.
       <literal>cube_subset(cube('(1,3,5),(6,7,8)'), ARRAY[2]) = '(3),(7)'</>.
       Or can be used to drop dimensions, or reorder them as desired, e.g.
       <literal>cube_subset(cube('(1,3,5),(6,7,8)'), ARRAY[3,2,1,1]) = '(5, 3,
       1, 1),(8, 7, 6, 6)'</>.
      </entry>
     </row>

     <row>
      <entry><literal>cube_union(cube, cube) returns cube</literal></entry>
      <entry>Produces the union of two cubes
      </entry>
     </row>

     <row>
      <entry><literal>cube_inter(cube, cube) returns cube</literal></entry>
      <entry>Produces the intersection of two cubes
      </entry>
     </row>

     <row>
      <entry><literal>cube_enlarge(cube c, double r, int n) returns cube</literal></entry>
      <entry>Increases the size of a cube by a specified radius in at least
       n dimensions. If the radius is negative the cube is shrunk instead. This
       is useful for creating bounding boxes around a point for searching for
       nearby points. All defined dimensions are changed by the radius r.
       LL coordinates are decreased by r and UR coordinates are increased by r.
       If a LL coordinate is increased to larger than the corresponding UR
       coordinate (this can only happen when r &lt; 0) than both coordinates
       are set to their average.  If n is greater than the number of defined
       dimensions and the cube is being increased (r &gt;= 0) then 0 is used
       as the base for the extra coordinates.
      </entry>
     </row>
    </tbody>
   </tgroup>
  </table>
 </sect2>

 <sect2>
  <title>Defaults</title>

  <para>
   I believe this union:
  </para>
<programlisting>
select cube_union('(0,5,2),(2,3,1)', '0');
cube_union
-------------------
(0, 0, 0),(2, 5, 2)
(1 row)
</programlisting>

   <para>
    does not contradict common sense, neither does the intersection
   </para>

<programlisting>
select cube_inter('(0,-1),(1,1)', '(-2),(2)');
cube_inter
-------------
(0, 0),(1, 0)
(1 row)
</programlisting>

   <para>
    In all binary operations on differently-dimensioned cubes, I assume the
    lower-dimensional one to be a Cartesian projection, i. e., having zeroes
    in place of coordinates omitted in the string representation. The above
    examples are equivalent to:
   </para>

<programlisting>
cube_union('(0,5,2),(2,3,1)','(0,0,0),(0,0,0)');
cube_inter('(0,-1),(1,1)','(-2,0),(2,0)');
</programlisting>

   <para>
    The following containment predicate uses the point syntax,
    while in fact the second argument is internally represented by a box.
    This syntax makes it unnecessary to define a separate point type
    and functions for (box,point) predicates.
   </para>

<programlisting>
select cube_contains('(0,0),(1,1)', '0.5,0.5');
cube_contains
--------------
t
(1 row)
</programlisting>
 </sect2>

 <sect2>
  <title>Notes</title>

  <para>
   For examples of usage, see the regression test <filename>sql/cube.sql</>.
  </para>

  <para>
   To make it harder for people to break things, there
   is a limit of 100 on the number of dimensions of cubes. This is set
   in <filename>cubedata.h</> if you need something bigger.
  </para>
 </sect2>

 <sect2>
  <title>Credits</title>

  <para>
   Original author: Gene Selkov, Jr. <email>selkovjr@@mcs.anl.gov</email>,
   Mathematics and Computer Science Division, Argonne National Laboratory.
  </para>

  <para>
   My thanks are primarily to Prof. Joe Hellerstein
   (<ulink url="http://db.cs.berkeley.edu/jmh/"></ulink>) for elucidating the
   gist of the GiST (<ulink url="http://gist.cs.berkeley.edu/"></ulink>), and
   to his former student, Andy Dong (<ulink
   url="http://best.me.berkeley.edu/~adong/"></ulink>), for his example
   written for Illustra,
   <ulink url="http://best.berkeley.edu/~adong/rtree/index.html"></ulink>.
   I am also grateful to all Postgres developers, present and past, for
   enabling myself to create my own world and live undisturbed in it. And I
   would like to acknowledge my gratitude to Argonne Lab and to the
   U.S. Department of Energy for the years of faithful support of my database
   research.
  </para>

  <para>
   Minor updates to this package were made by Bruno Wolff III
   <email>bruno@@wolff.to</email> in August/September of 2002. These include
   changing the precision from single precision to double precision and adding
   some new functions.
  </para>

  <para>
   Additional updates were made by Joshua Reich <email>josh@@root.net</email> in
   July 2006. These include <literal>cube(float8[], float8[])</literal> and
   cleaning up the code to use the V1 call protocol instead of the deprecated
   V0 protocol.
  </para>
 </sect2>

</sect1>
@


1.8
log
@Fix indentation of verbatim block elements

Block elements with verbatim formatting (literallayout, programlisting,
screen, synopsis) should be aligned at column 0 independent of the surrounding
SGML, because whitespace is significant, and indenting them creates erratic
whitespace in the output.  The CSS stylesheets already take care of indenting
the output.

Assorted markup improvements to go along with it.
@
text
@d1 1
a1 1
<!-- $PostgreSQL: pgsql/doc/src/sgml/cube.sgml,v 1.7 2009/12/08 20:08:30 mha Exp $ -->
d12 1
a12 1
  representing multi-dimensional cubes.
d101 1
a101 1
   The operators supported by the GiST opclass are shown in <xref linkend="cube-gist-operators">.
d143 1
a143 1
   datatypes!)
d342 1
a342 1
    lower-dimensional one to be a cartesian projection, i. e., having zeroes
@


1.7
log
@Fix a couple of broken links to third-party sites.
@
text
@d1 1
a1 1
<!-- $PostgreSQL: pgsql/doc/src/sgml/cube.sgml,v 1.6 2009/05/18 11:08:24 petere Exp $ -->
d101 1
a101 1
   The operators supported by the GiST opclass include:
d104 33
a136 34
  <itemizedlist>
   <listitem>
    <programlisting>
a = b                 Same as
    </programlisting>
    <para>
     The cubes a and b are identical.
    </para>
   </listitem>
   <listitem>
    <programlisting>
a &amp;&amp; b                Overlaps
    </programlisting>
    <para>
     The cubes a and b overlap.
    </para>
   </listitem>
   <listitem>
    <programlisting>
a @@&gt; b                Contains
    </programlisting>
    <para>
     The cube a contains the cube b.
    </para>
   </listitem>
   <listitem>
  <programlisting>
a &lt;@@ b                Contained in
  </programlisting>
    <para>
     The cube a is contained in the cube b.
    </para>
   </listitem>
  </itemizedlist>
d139 2
a140 2
   (Before PostgreSQL 8.2, the containment operators @@&gt; and &lt;@@ were
   respectively called @@ and ~.  These names are still available, but are
d149 22
a170 4
  <programlisting>
[a, b] &lt; [c, d]                Less than
[a, b] &gt; [c, d]                Greater than
  </programlisting>
@


1.7.8.1
log
@Fix indentation of verbatim block elements

Block elements with verbatim formatting (literallayout, programlisting,
screen, synopsis) should be aligned at column 0 independent of the surrounding
SGML, because whitespace is significant, and indenting them creates erratic
whitespace in the output.  The CSS stylesheets already take care of indenting
the output.

Assorted markup improvements to go along with it.
@
text
@d1 1
a1 1
<!-- $PostgreSQL: pgsql/doc/src/sgml/cube.sgml,v 1.7 2009/12/08 20:08:30 mha Exp $ -->
d101 1
a101 1
   The operators supported by the GiST opclass are shown in <xref linkend="cube-gist-operators">.
d104 34
a137 33
  <table id="cube-gist-operators">
   <title>Cube GiST operators</title>
   <tgroup cols="2">
    <thead>
     <row>
      <entry>Operator</entry>
      <entry>Description</entry>
     </row>
    </thead>

    <tbody>
     <row>
      <entry><literal>a = b</></entry>
      <entry>The cubes a and b are identical.</entry>
     </row>

     <row>
      <entry><literal>a &amp;&amp; b</></entry>
      <entry>The cubes a and b overlap.</entry>
     </row>

     <row>
      <entry><literal>a @@&gt; b</></entry>
      <entry>The cube a contains the cube b.</entry>
     </row>

     <row>
      <entry><literal>a &lt;@@ b</></entry>
      <entry>The cube a is contained in the cube b.</entry>
     </row>
    </tbody>
   </tgroup>
  </table>
d140 2
a141 2
   (Before PostgreSQL 8.2, the containment operators <literal>@@&gt;</> and <literal>&lt;@@</> were
   respectively called <literal>@@</> and <literal>~</>.  These names are still available, but are
d150 4
a153 22
   <informaltable>
    <tgroup cols="2">
     <thead>
      <row>
       <entry>Operator</entry>
       <entry>Description</entry>
      </row>
     </thead>

     <tbody>
      <row>
       <entry><literal>[a, b] &lt; [c, d]</literal></entry>
       <entry>Less than</entry>
      </row>

      <row>
       <entry><literal>[a, b] &gt; [c, d]</literal></entry>
       <entry>Greater than</entry>
      </row>
     </tbody>
    </tgroup>
   </informaltable>
@


1.7.8.2
log
@Spell and markup checking
@
text
@d1 1
a1 1
<!-- $PostgreSQL: pgsql/doc/src/sgml/cube.sgml,v 1.7.8.1 2010/07/29 19:34:36 petere Exp $ -->
d12 1
a12 1
  representing multidimensional cubes.
d101 1
a101 1
   The operators supported by the GiST operator class are shown in <xref linkend="cube-gist-operators">.
d143 1
a143 1
   data types!)
d342 1
a342 1
    lower-dimensional one to be a Cartesian projection, i. e., having zeroes
@


1.6
log
@Refer to tables by id, not by "the following table", because tables are in
theory floating elements.
@
text
@d1 1
a1 1
<!-- $PostgreSQL: pgsql/doc/src/sgml/cube.sgml,v 1.5 2007/12/06 04:12:09 tgl Exp $ -->
d375 1
a375 1
   (<ulink url="http://db.cs.berkeley.edu/~jmh/"></ulink>) for elucidating the
d380 1
a380 1
   <ulink url="http://garcia.me.berkeley.edu/~adong/rtree"></ulink>.
@


1.6.2.1
log
@Fix a couple of broken links to third-party sites.
@
text
@d1 1
a1 1
<!-- $PostgreSQL: pgsql/doc/src/sgml/cube.sgml,v 1.6 2009/05/18 11:08:24 petere Exp $ -->
d375 1
a375 1
   (<ulink url="http://db.cs.berkeley.edu/jmh/"></ulink>) for elucidating the
d380 1
a380 1
   <ulink url="http://best.berkeley.edu/~adong/rtree/index.html"></ulink>.
@


1.5
log
@Make an editorial pass over the newly SGML-ified contrib documentation.
Fix lots of bad markup, bad English, bad explanations.

This commit covers only about half the contrib modules, but I grow weary...
@
text
@d1 1
a1 1
<!-- $PostgreSQL$ -->
d19 4
a22 3
   The following are valid external representations for the <type>cube</>
   type.  <replaceable>x</>, <replaceable>y</>, etc denote floating-point
   numbers:
d25 1
a25 1
  <table>
d163 1
a163 1
   The following functions are available:
d166 1
a166 1
  <table>
@


1.4
log
@Entity-ify a passel of & < > characters.  Per gripe from Devrim.
@
text
@d1 1
d5 1
a5 1
 
d11 2
a12 2
  This module contains the user-defined type, CUBE, representing 
  multidimensional cubes.
d19 3
a21 1
   The following are valid external representations for the CUBE type:
d29 2
a30 132
      <entry>'x'</entry>
      <entry>A floating point value representing a one-dimensional point or 
       one-dimensional zero length cubement
      </entry>
     </row>
     <row>
      <entry>'(x)'</entry>
      <entry>Same as above</entry>
     </row>
     <row>
      <entry>'x1,x2,x3,...,xn'</entry>
      <entry>A point in n-dimensional space, represented internally as a zero 
       volume box
      </entry>
     </row>
     <row>
      <entry>'(x1,x2,x3,...,xn)'</entry>
      <entry>Same as above</entry>
     </row>
     <row>
      <entry>'(x),(y)'</entry>
      <entry>1-D cubement starting at x and ending at y or vice versa; the 
       order does not matter
      </entry>
     </row>
     <row>
      <entry>'(x1,...,xn),(y1,...,yn)'</entry>
      <entry>n-dimensional box represented by a pair of its opposite corners, no 
       matter which.  Functions take care of swapping to achieve "lower left -- 
       upper right" representation before computing any values
      </entry>
     </row>
    </tbody>
   </tgroup>
  </table>
   </sect2>
  
   <sect2>
    <title>Grammar</title>
    <table>
     <title>Cube Grammar Rules</title>
     <tgroup cols="2">
      <tbody>
       <row>
        <entry>rule 1</entry>
        <entry>box -> O_BRACKET paren_list COMMA paren_list C_BRACKET</entry>
       </row>
       <row>
        <entry>rule 2</entry>
        <entry>box -> paren_list COMMA paren_list</entry>
       </row>
       <row>
        <entry>rule 3</entry>
        <entry>box -> paren_list</entry>
       </row>
       <row>
        <entry>rule 4</entry>
        <entry>box -> list</entry>
       </row>
       <row>
        <entry>rule 5</entry>
        <entry>paren_list -> O_PAREN list C_PAREN</entry>
       </row>
       <row>
        <entry>rule 6</entry>
        <entry>list -> FLOAT</entry>
       </row>
       <row>
        <entry>rule 7</entry>
        <entry>list -> list COMMA FLOAT</entry>
       </row>
      </tbody>
     </tgroup>
    </table>
   </sect2>

   <sect2>
    <title>Tokens</title>
    <table>
     <title>Cube Grammar Rules</title>
     <tgroup cols="2">
      <tbody>
       <row>
        <entry>n</entry>
        <entry>[0-9]+</entry>
       </row>
       <row>
        <entry>i</entry>
        <entry>nteger                [+-]?{n}</entry>
       </row>
       <row>
        <entry>real</entry>
        <entry>[+-]?({n}\.{n}?|\.{n})</entry>
       </row>
       <row>
        <entry>FLOAT</entry>
        <entry>({integer}|{real})([eE]{integer})?</entry>
       </row>
       <row>
        <entry>O_BRACKET</entry>        
        <entry>\[</entry>
       </row>
       <row>
        <entry>C_BRACKET</entry>
        <entry>\]</entry>
       </row>
       <row>
        <entry>O_PAREN</entry>
        <entry>\(</entry>
       </row>
       <row>
        <entry>C_PAREN</entry>
        <entry>\)</entry>
       </row>
       <row>
        <entry>COMMA</entry>
        <entry>\,</entry>
       </row>
      </tbody>
     </tgroup>
    </table>
   </sect2>

 <sect2>
  <title>Examples</title>
  <table>
   <title>Examples</title>
   <tgroup cols="2">
    <tbody>
     <row>
      <entry>'x'</entry>
      <entry>A floating point value representing a one-dimensional point 
d35 1
a35 1
      <entry>'(x)'</entry>
d39 3
a41 3
      <entry>'x1,x2,x3,...,xn'</entry>
      <entry>A point in n-dimensional space,represented internally as a zero 
       volume cube
d45 1
a45 1
      <entry>'(x1,x2,x3,...,xn)'</entry>
d49 2
a50 2
      <entry>'(x),(y)'</entry>
      <entry>A 1-D interval starting at x and ending at y or vice versa; the
d55 1
a55 1
      <entry>'[(x),(y)]'</entry>
d59 3
a61 6
      <entry>'(x1,...,xn),(y1,...,yn)'</entry>
      <entry>An n-dimensional box represented by a pair of its diagonally 
       opposite corners, regardless of order. Swapping is provided
       by all comarison routines to ensure the 
       "lower left -- upper right" representation
       before actaul comparison takes place.
d65 1
a65 1
      <entry>'[(x1,...,xn),(y1,...,yn)]'</entry>
d71 1
d73 4
a76 1
   White space is ignored, so '[(x),(y)]' can be: '[ ( x ), ( y ) ]'
d78 1
a78 3
 </sect2>
 <sect2>
  <title>Defaults</title>
d80 2
a81 1
   I believe this union:
d83 1
a83 30
<programlisting>
select cube_union('(0,5,2),(2,3,1)','0'); 
cube_union        
-------------------
(0, 0, 0),(2, 5, 2)
(1 row)
</programlisting>

   <para>
    does not contradict to the common sense, neither does the intersection
   </para>

<programlisting>
select cube_inter('(0,-1),(1,1)','(-2),(2)');
cube_inter  
-------------
(0, 0),(1, 0)
(1 row)
</programlisting>

   <para>
    In all binary operations on differently sized boxes, I assume the smaller
    one to be a cartesian projection, i. e., having zeroes in place of coordinates
    omitted in the string representation. The above examples are equivalent to:
   </para>

<programlisting>
cube_union('(0,5,2),(2,3,1)','(0,0,0),(0,0,0)'); 
cube_inter('(0,-1),(1,1)','(-2,0),(2,0)');
</programlisting>
a84 15
   <para>
    The following containment predicate uses the point syntax,
    while in fact the second argument is internally represented by a box.
    This syntax makes it unnecessary to define the special Point type
    and functions for (box,point) predicates.
   </para>

<programlisting>
select cube_contains('(0,0),(1,1)', '0.5,0.5');
cube_contains
--------------
t             
(1 row)
</programlisting>
 </sect2>
d87 1
d89 2
a90 2
Values are stored internally as 64-bit floating point numbers. This means that
numbers with more than about 16 significant digits will be truncated.
a95 11
  <para>
   The access method for CUBE is a GiST index (gist_cube_ops), which is a
   generalization of R-tree. GiSTs allow the postgres implementation of
   R-tree, originally encoded to support 2-D geometric types such as
   boxes and polygons, to be used with any data type whose data domain
   can be partitioned using the concepts of containment, intersection and
   equality. In other words, everything that can intersect or contain
   its own kind can be indexed with a GiST. That includes, among other
   things, all geometric data types, regardless of their dimensionality
   (see also contrib/seg).
  </para>
d98 16
a113 11
   The operators supported by the GiST access method include:
  </para>

  <programlisting>
a = b                Same as
  </programlisting>
  <para>
   The cubements a and b are identical.
  </para>

  <programlisting>
d115 7
a121 6
  </programlisting>
  <para>
   The cubements a and b overlap.
  </para>

  <programlisting>
d123 6
a128 5
  </programlisting>
  <para>
   The cubement a contains the cubement b.
  </para>

d132 5
a136 3
  <para>
   The cubement a is contained in b.
  </para>
d147 1
a147 8
   Although the mnemonics of the following operators is questionable, I
   preserved them to maintain visual consistency with other geometric
   data types defined in Postgres.
  </para>

  <para>
   Other operators:
  </para>
d153 1
a153 2
 
  <para>
d156 1
a156 1
   and if these are equal, compare (b) to (d). That accounts for
d158 1
a158 1
   you want to use ORDER BY with this type
d166 1
a166 1
   <title>Functions available</title>
a169 12
      <entry><literal>cube_distance(cube, cube) returns double</literal></entry>
      <entry>cube_distance returns the distance between two cubes. If both 
       cubes are points, this is the normal distance function.
      </entry>
     </row>
     <row>
      <entry><literal>cube(text)</literal></entry>
      <entry>Takes text input and returns a cube. This is useful for making 
      cubes from computed strings.
      </entry>
     </row>
     <row>
d171 1
a171 3
      <entry>This makes a one dimensional cube with both coordinates the same.
       If the type of the argument is a numeric type other than float8 an
       explicit cast to float8 may be needed.
d178 1
a178 2
      <entry>
       This makes a one dimensional cube.
d185 3
a187 2
      <entry>This makes a zero-volume cube using the coordinates 
       defined by thearray.<literal>cube(ARRAY[1,2]) == '(1,2)'</literal>
d193 2
a194 2
      <entry>This makes a cube, with upper right and lower left 
       coordinates as defined by the 2 float arrays. Arrays must be of the 
d203 2
a204 2
      <entry>This builds a new cube by adding a dimension on to an 
       existing cube with the same values for both parts of the new coordinate. 
d212 2
a213 2
      <entry>This builds a new cube by adding a dimension on to an 
       existing cube. This is useful for building cubes piece by piece from 
d220 1
a220 3
      <entry>cube_dim returns the number of dimensions stored in the 
       the data structure
       for a cube. This is useful for constraints on the dimensions of a cube.
d226 2
a227 3
      <entry>
       cube_ll_coord returns the nth coordinate value for the lower left 
       corner of a cube. This is useful for doing coordinate transformations.
d234 15
a248 3
      <entry>cube_ur_coord returns the nth coordinate value for the
       upper right corner of a cube. This is useful for doing coordinate 
       transformations.
d255 7
a261 7
      <entry>Builds a new cube from an existing cube, using a list of 
       dimension indexes
       from an array. Can be used to find both the ll and ur coordinate of single
       dimenion, e.g.: cube_subset(cube('(1,3,5),(6,7,8)'), ARRAY[2]) = '(3),(7)'
       Or can be used to drop dimensions, or reorder them as desired, e.g.:
       cube_subset(cube('(1,3,5),(6,7,8)'), ARRAY[3,2,1,1]) = 
       '(5, 3, 1, 1),(8, 7, 6, 6)'
d266 9
a274 3
      <entry><literal>cube_is_point(cube) returns bool</literal></entry>
      <entry>cube_is_point returns true if a cube is also a point. 
       This is true when the two defining corners are the same.</entry>
d276 1
a276 1
 
d278 3
a280 5
      <entry><literal>cube_enlarge(cube, double, int) returns cube</literal></entry>
      <entry>
       cube_enlarge increases the size of a cube by a specified 
       radius in at least
       n dimensions. If the radius is negative the box is shrunk instead. This
d282 7
a288 9
       nearby points. All defined dimensions are changed by the radius. If n
       is greater than the number of defined dimensions and the cube is being
       increased (r &gt;= 0) then 0 is used as the base for the extra coordinates.
       LL coordinates are decreased by r and UR coordinates are increased by r. 
       If a LL coordinate is increased to larger than the corresponding UR 
       coordinate (this can only happen when r &lt; 0) than both coordinates are 
       set to their average. To make it harder for people to break things there 
       is an effective maximum on the dimension of cubes of 100. This is set 
       in cubedata.h if you need something bigger.
d294 5
a298 1
 
d300 1
a300 5
   There are a few other potentially useful functions defined in cube.c 
   that vanished from the schema because I stopped using them. Some of 
   these were meant to support type casting. Let me know if I was wrong: 
   I will then add them back to the schema. I would also appreciate 
   other ideas that would enhance the type and make it more useful.
d302 50
d354 7
a360 1
   For examples of usage, see sql/cube.sql
d366 1
d368 2
a369 2
   This code is essentially based on the example written for
   Illustra, <ulink url="http://garcia.me.berkeley.edu/~adong/rtree"></ulink>
d371 1
d374 11
a384 8
   (<ulink url="http://db.cs.berkeley.edu/~jmh/"></ulink>) for elucidating the 
   gist of the GiST (<ulink url="http://gist.cs.berkeley.edu/"></ulink>), and 
   to his former student, Andy Dong 
   (<ulink url="http://best.me.berkeley.edu/~adong/"></ulink>), for his exemplar.
   I am also grateful to all postgres developers, present and past, for enabling
   myself to create my own world and live undisturbed in it. And I would like to
   acknowledge my gratitude to Argonne Lab and to the U.S. Department of Energy
   for the years of faithful support of my database research.
d388 3
a390 14
   Gene Selkov, Jr.
   Computational Scientist
   Mathematics and Computer Science Division
   Argonne National Laboratory
   9700 S Cass Ave.
   Building 221
   Argonne, IL 60439-4844
   <email>selkovjr@@mcs.anl.gov</email>
  </para>

  <para>
   Minor updates to this package were made by Bruno Wolff III 
   <email>bruno@@wolff.to</email> in August/September of 2002. These include 
   changing the precision from single precision to double precision and adding 
d395 4
a398 4
   Additional updates were made by Joshua Reich <email>josh@@root.net</email> in 
   July 2006. These include <literal>cube(float8[], float8[])</literal> and 
   cleaning up the code to use the V1 call protocol instead of the deprecated V0 
   form.
d401 1
a402 1

@


1.3
log
@Update SGML contrib documentation to catch up with recent changes to
the former README files.  Albert Cervera i Areny
@
text
@d290 1
a290 1
a && b                Overlaps
d297 1
a297 1
a @@> b                Contains
d304 1
a304 1
a <@@ b                Contained in
d311 1
a311 1
   (Before PostgreSQL 8.2, the containment operators @@> and <@@ were
d329 2
a330 2
[a, b] < [c, d]                Less than
[a, b] > [c, d]                Greater than
d465 1
a465 1
       increased (r >= 0) then 0 is used as the base for the extra coordinates.
d468 1
a468 1
       coordinate (this can only happen when r < 0) than both coordinates are 
@


1.2
log
@Remove tabs from SGML files.
@
text
@d356 6
@


1.1
log
@Move most /contrib README files into SGML.  Some still need conversion
or will never be converted.
@
text
@d110 1
a110 1
	<entry>[0-9]+</entry>
d114 1
a114 1
	<entry>nteger		[+-]?{n}</entry>
d118 1
a118 1
	<entry>[+-]?({n}\.{n}?|\.{n})</entry>
d122 1
a122 1
	<entry>({integer}|{real})([eE]{integer})?</entry>
d125 2
a126 2
        <entry>O_BRACKET</entry>	
	<entry>\[</entry>
d130 1
a130 1
	<entry>\]</entry>
d134 1
a134 1
	<entry>\(</entry>
d138 1
a138 1
	<entry>\)</entry>
d142 1
a142 1
	<entry>\,</entry>
d283 1
a283 1
a = b		Same as
d290 1
a290 1
a && b		Overlaps
d297 1
a297 1
a @@> b		Contains
d304 1
a304 1
a <@@ b		Contained in
d329 2
a330 2
[a, b] < [c, d]		Less than
[a, b] > [c, d]		Greater than
@

