# HG changeset patch
# User Jordi Gutiérrez Hermoso <jordigh@octave.org>
# Date 1367436597 14400
# Node ID 189241a7c3a952d4ff0bdbcc879558d44cbf3827
# Parent  e84b77df8940ddba4fa699ed0bb0385b31823c5c# Parent  f2f5dd09e97dedf146e1f2b98c2158a040f5d458
maint: periodic merge of stable to default

diff -r e84b77df8940 -r 189241a7c3a9 doc/interpreter/contrib.txi
--- a/doc/interpreter/contrib.txi	Wed May 01 02:24:04 2013 -0400
+++ b/doc/interpreter/contrib.txi	Wed May 01 15:29:57 2013 -0400
@@ -48,18 +48,10 @@
 @section Building the Development Sources
 
 In addition to all the tools (both optional and required) that are
-listed in @ref{Build Dependencies} you will need:
-
-@table @asis
-@item Mercurial
-Distributed version control system (@url{http://mercurial.selenic.com}).
+listed in @ref{Build Dependencies} you will need Mercurial, a
+distributed version control system (@url{http://mercurial.selenic.com}).
 Octave's sources are stored in a Mercurial archive.
 
-@item Git
-Distributed version control system (@url{http://git-scm.com}).  The
-gnulib sources that Octave depends on are stored in a Git archive.
-@end table
-
 Once you have the required tools installed, you can build Octave by
 doing
 
diff -r e84b77df8940 -r 189241a7c3a9 doc/interpreter/sparse.txi
--- a/doc/interpreter/sparse.txi	Wed May 01 02:24:04 2013 -0400
+++ b/doc/interpreter/sparse.txi	Wed May 01 15:29:57 2013 -0400
@@ -89,13 +89,15 @@
 easy to grasp, but requires more storage than is strictly needed.
 
 The storage technique used within Octave is the compressed column
-format.  In this format the position of each element in a row and the
-data are stored as previously.  However, if we assume that all elements
-in the same column are stored adjacent in the computers memory, then
-we only need to store information on the number of non-zero elements
-in each column, rather than their positions.  Thus assuming that the
-matrix has more non-zero elements than there are columns in the
-matrix, we win in terms of the amount of memory used.
+format. It is similar to the Yale format.
+@footnote{@url{http://en.wikipedia.org/wiki/Sparse_matrix#Yale_format}}
+In this format the position of each element in a row and the data are
+stored as previously. However, if we assume that all elements in the
+same column are stored adjacent in the computers memory, then we only
+need to store information on the number of non-zero elements in each
+column, rather than their positions. Thus assuming that the matrix has
+more non-zero elements than there are columns in the matrix, we win in
+terms of the amount of memory used.
 
 In fact, the column index contains one more element than the number of
 columns, with the first element always being zero.  The advantage of
@@ -797,18 +799,19 @@
 http://www.cise.ufl.edu/research/sparse/}.
 @end enumerate
 
-The band density is defined as the number of non-zero values in the matrix
-divided by the number of non-zero values in the matrix.  The banded matrix
-solvers can be entirely disabled by using @dfn{spparms} to set @code{bandden}
-to 1 (i.e., @code{spparms ("bandden", 1)}).
+The band density is defined as the number of non-zero values in the band
+divided by the total number of values in the full band. The banded
+matrix solvers can be entirely disabled by using @dfn{spparms} to set
+@code{bandden} to 1 (i.e., @code{spparms ("bandden", 1)}).
 
-The QR@tie{}solver factorizes the problem with a Dulmage-Mendelsohn, to
-separate the problem into blocks that can be treated as over-determined,
-multiple well determined blocks, and a final over-determined block.  For
-matrices with blocks of strongly connected nodes this is a big win as
-LU@tie{}decomposition can be used for many blocks.  It also significantly
-improves the chance of finding a solution to over-determined problems
-rather than just returning a vector of @dfn{NaN}'s.
+The QR@tie{}solver factorizes the problem with a Dulmage-Mendelsohn
+decomposition, to separate the problem into blocks that can be treated
+as over-determined, multiple well determined blocks, and a final
+over-determined block. For matrices with blocks of strongly connected
+nodes this is a big win as LU@tie{}decomposition can be used for many
+blocks. It also significantly improves the chance of finding a solution
+to over-determined problems rather than just returning a vector of
+@dfn{NaN}'s.
 
 All of the solvers above, can calculate an estimate of the condition
 number.  This can be used to detect numerical stability problems in the