[Boost-commit] svn:boost r39479 - sandbox/math_toolkit/libs/math/doc

From: john_at_[hidden]
Date: 2007-09-22 13:06:43

Author: johnmaddock
Date: 2007-09-22 13:06:41 EDT (Sat, 22 Sep 2007)
New Revision: 39479
URL: http://svn.boost.org/trac/boost/changeset/39479

Log:
More typos and other minor fixes.
Text files modified: 
   sandbox/math_toolkit/libs/math/doc/compilers.qbk      |     2 +-                                      
   sandbox/math_toolkit/libs/math/doc/implementation.qbk |    11 ++++++-----                             
   2 files changed, 7 insertions(+), 6 deletions(-)

Modified: sandbox/math_toolkit/libs/math/doc/compilers.qbk
==============================================================================
--- sandbox/math_toolkit/libs/math/doc/compilers.qbk	(original)
+++ sandbox/math_toolkit/libs/math/doc/compilers.qbk	2007-09-22 13:06:41 EDT (Sat, 22 Sep 2007)
@@ -18,7 +18,7 @@
 [[Borland 5.8.2][Windows][Almost works: some effort has been put into porting to this compiler.
       However, during testing a number of instances were encountered where this compiler
       generated incorrect code: completely omitting a function call seemingly at random.
-      For this reason, we cannot recoment using this library with this compiler, as the
+      For this reason, [*we cannot recoment using this library with this compiler], as the
       correct operation of the code cannot be guarenteed.]]
 [[MSVC 8.0][Windows][Warning free at level 4]]
 ]

Modified: sandbox/math_toolkit/libs/math/doc/implementation.qbk
==============================================================================
--- sandbox/math_toolkit/libs/math/doc/implementation.qbk	(original)
+++ sandbox/math_toolkit/libs/math/doc/implementation.qbk	2007-09-22 13:06:41 EDT (Sat, 22 Sep 2007)
@@ -145,8 +145,9 @@
 [h4 Handling of Functions that are Not Mathematically defined]
 
 Functions that are not mathematically defined,
-like the Cauchy mean, fail to compile by default .
-[__math_undefined A policy] allows control of this.
+like the Cauchy mean, fail to compile by default.
+[link math_toolkit.policy.pol_ref.assert_undefined A policy] 
+allows control of this.
 
 If the policy is to permit undefined functions, then calling them
 throws a domain error, by default.  But the error policy can be set
@@ -252,15 +253,15 @@
 
 Rational rather than Polynomial approximations are used to ensure
 accuracy: polynomial approximations are often wonderful up to
-a certain level of accuracy, but then fail to provide much greater
+a certain level of accuracy, but then quite often fail to provide much greater
 accuracy no matter how many more terms are added.
 
 Our own approximations were devised either for added accuracy
 (to support 128-bit long doubles for example), or because
 literature methods were unavailable or under non-BSL
 compatible license.  Our Remez code is known to produce good
-agreement with literature results in fairly simple "toy" cases,
-for more complex cases.  All approximations were checked 
+agreement with literature results in fairly simple "toy" cases.
+All approximations were checked 
 for convergence and to ensure that
 they were not ill-conditioned (the coefficients can give a 
 theoretically good solution, but the resulting rational function