Mercurial > hg > octave-jordi
diff doc/interpreter/diagperm.txi @ 18816:9ac2357f19bc
doc: Replace "non-zero" with "nonzero" to match existing usage.
Replace all occurrences in both documentation and code comments.
* doc/interpreter/contrib.txi, doc/interpreter/diagperm.txi,
doc/interpreter/external.txi, doc/interpreter/sparse.txi,
doc/interpreter/stmt.txi, doc/interpreter/testfun.txi, doc/refcard/refcard.tex,
examples/mysparse.c, libinterp/corefcn/balance.cc,
libinterp/corefcn/cellfun.cc, libinterp/corefcn/data.cc,
libinterp/corefcn/filter.cc, libinterp/corefcn/find.cc,
libinterp/corefcn/kron.cc, libinterp/corefcn/ls-mat5.cc,
libinterp/corefcn/luinc.cc, libinterp/corefcn/mappers.cc,
libinterp/corefcn/oct-fstrm.cc, libinterp/corefcn/oct-fstrm.h,
libinterp/corefcn/oct-iostrm.cc, libinterp/corefcn/oct-iostrm.h,
libinterp/corefcn/oct-stdstrm.h, libinterp/corefcn/oct-strstrm.h,
libinterp/corefcn/spparms.cc, libinterp/corefcn/toplev.cc,
libinterp/corefcn/utils.cc, libinterp/dldfcn/symrcm.cc,
libinterp/octave-value/ov-bool-mat.cc, liboctave/array/CSparse.cc,
liboctave/array/Sparse.cc, liboctave/array/Sparse.h,
liboctave/array/dSparse.cc, liboctave/numeric/randmtzig.c,
liboctave/operators/Sparse-op-defs.h, scripts/help/get_first_help_sentence.m,
scripts/miscellaneous/edit.m, scripts/plot/draw/pie.m,
scripts/plot/draw/pie3.m, scripts/sparse/colperm.m, scripts/sparse/nonzeros.m,
scripts/sparse/spdiags.m, scripts/sparse/spfun.m, scripts/sparse/spones.m,
scripts/sparse/sprand.m, scripts/sparse/sprandn.m, scripts/sparse/sprandsym.m,
scripts/sparse/spstats.m, scripts/sparse/svds.m,
scripts/special-matrix/gallery.m, scripts/statistics/base/moment.m,
scripts/statistics/tests/cor_test.m:
Replace "non-zero" with "nonzero" to match existing usage.
author | Rik <rik@octave.org> |
---|---|
date | Sun, 08 Jun 2014 17:59:59 -0700 |
parents | 200851c87444 |
children | 0850b5212619 |
line wrap: on
line diff
--- a/doc/interpreter/diagperm.txi +++ b/doc/interpreter/diagperm.txi @@ -489,21 +489,18 @@ right and the consequent usage of smarter algorithms for certain operations implies, as a side effect, small differences in treating zeros. The contents of this section apply also to sparse matrices, discussed in -the following chapter. (@pxref{Sparse Matrices}) +the following chapter. (@pxref{Sparse Matrices}) -The IEEE floating point standard defines the result of the expressions @code{0*Inf} and -@code{0*NaN} as @code{NaN}. This is widely agreed to be a good -compromise. -Numerical software dealing with structured and sparse matrices (including -Octave) however, almost always makes a distinction between a "numerical zero" -and an "assumed zero". -A "numerical zero" is a zero value occurring in a place where any floating-point -value could occur. It is normally stored somewhere in memory as an explicit -value. -An "assumed zero", on the contrary, is a zero matrix element implied by the -matrix structure (diagonal, triangular) or a sparsity pattern; its value is -usually not stored explicitly anywhere, but is implied by the underlying -data structure. +The IEEE floating point standard defines the result of the expressions +@code{0*Inf} and @code{0*NaN} as @code{NaN}. This is widely agreed to be a +good compromise. Numerical software dealing with structured and sparse matrices +(including Octave) however, almost always makes a distinction between a +"numerical zero" and an "assumed zero". A "numerical zero" is a zero value +occurring in a place where any floating-point value could occur. It is +normally stored somewhere in memory as an explicit value. An "assumed zero", on +the contrary, is a zero matrix element implied by the matrix structure +(diagonal, triangular) or a sparsity pattern; its value is usually not stored +explicitly anywhere, but is implied by the underlying data structure. The primary distinction is that an assumed zero, when multiplied by any number, or divided by any nonzero number,