boost_mirror/geometry
1
0
Fork 0
mirror of https://github.com/boostorg/geometry.git synced 2025-05-11 05:24:02 +00:00
Code Issues Packages Projects Releases Wiki Activity

[geometry] Add basic draft of the Robustness topic for docs

Browse Source 
[SVN r86434]
This commit is contained in:
Mateusz Loskot 2013-10-26 00:18:47 +00:00
parent 6d3586c612
commit 55cf84daf5
1 changed files with 43 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

43
doc/robustness.qbk Normal file
View File

@ -0,0 +1,43 @@
[/============================================================================
Boost.Geometry (aka GGL, Generic Geometry Library)
Copyright (c) 2013 Mateusz Loskot, London, UK.
Use, modification and distribution is subject to the Boost Software License,
Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at
http://www.boost.org/LICENSE_1_0.txt)
=============================================================================/]
[/ TODO: this is a basic draft only, should NOT be built into final docs yet ]
[/ TODO: discuss numerical stability per algorithm (at least for line intersection and point in polygon) ]
[section Robustness]
A numerical stability issues are a common problem in implementations of
computational geometry algorithms.
They lead to variety of unexpected sitautions at run-time: an application
randomly throws segmentation faults, output computed by an algorithm
contains degeneracies, unexpected artefacts or completely invalid.
For example, according to the OpenGIS Simple Feature Specification,
["A Polygon may not have cut lines, spikes or punctures]
From mathematical point of view such condition is easy to verify.
However, depending on computational method and in the presence of round-off
or truncation errors, it is not easy to decided how "sharp" must be a part
of polygon in order to consider it a spike.
A 100% robust implementation of an algorithm gives expected result in 100% of cases. Achieving complete floating point robustness implies use of certain set of algorithms as well as platform specific assumptions about floating point representations.
Despite Boost.Geometry does not promise absolute numerical stability,
it attempts to offer balanced efficiency and robustness by:
# selection of algorithms, often solved at case-by-case basis
# compile-time selection of most precise and capacious C++ type on which to perform computations.
# support for arbitrary precision numeric types
[endsect]