
BoostCommit : 
From: john_at_[hidden]
Date: 20070922 13:06:43
Author: johnmaddock
Date: 20070922 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 20070922 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 20070922 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 128bit long doubles for example), or because
literature methods were unavailable or under nonBSL
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 illconditioned (the coefficients can give a
theoretically good solution, but the resulting rational function
BoostCommit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk