|
Boost-Commit : |
Subject: [Boost-commit] svn:boost r77572 - sandbox/gtl/doc
From: sydorchuk.andriy_at_[hidden]
Date: 2012-03-26 17:43:18
Author: asydorchuk
Date: 2012-03-26 17:43:16 EDT (Mon, 26 Mar 2012)
New Revision: 77572
URL: http://svn.boost.org/trac/boost/changeset/77572
Log:
Adding Voronoi Basic tutorial
Text files modified:
sandbox/gtl/doc/voronoi_main.htm | 13 +++++++------
sandbox/gtl/doc/voronoi_predicates.htm | 3 ++-
2 files changed, 9 insertions(+), 7 deletions(-)
Modified: sandbox/gtl/doc/voronoi_main.htm
==============================================================================
--- sandbox/gtl/doc/voronoi_main.htm (original)
+++ sandbox/gtl/doc/voronoi_main.htm 2012-03-26 17:43:16 EDT (Mon, 26 Mar 2012)
@@ -24,6 +24,7 @@
+
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252"><title>Contents</title><meta http-equiv="content-type" content="text/html; charset=utf-8"><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body>
@@ -118,7 +119,7 @@
the second one may be waved in the future releases. Strong sides of the
library and main benefits comparing to other implementations are
discussed in the following paragraphs.<span style="font-weight: bold;"></span><br>
- <h1>Robustness and efficiency</h1>
+ <h1>Robustness and Efficiency</h1>
Lets explain a bit those terms. The efficiency is simply measured by
the time it takes the algorithm to execute. The robustness is a bit
@@ -141,7 +142,7 @@
Voronoi: we avoid multiprecision computations in 95% of cases using
extremely fast floating-point predicates. Yes, those are not always
exact, but we developed relative error arithmetic apparatus to identify them and switch to higher precision predicates when required.<br>
- <h1>Precision of output structures<br>
+ <h1>Precision of Output Structures<br>
</h1>
One of the extremely important results of using two types of predicates
is that library efficiently computes relatively precise coordinates of
@@ -180,7 +181,7 @@
consider vertices with both coordinates that are within 2^-17 meters (8
micrometers) distance to be equal. Come on that distance is equal to
the size of bacteria. Can you even see those?<br>
- <h1>Fully functional with segment inputs</h1>
+ <h1>Fully Functional with Segment Inputs</h1>
There are not many implementations of Voronoi diagrams that could
handle segment inputs, even considering commercial ones. Support of
segments allows to discretize any input geometry (circle, elipse,
@@ -190,7 +191,7 @@
medial axis transform of the arbitrary input geometry. So one may start
using it for the next generation pattern recognition or computer vision
project.<br>
- <h1>Basic and advanced usage cases</h1>The main library header <span style="font-family: Courier New,Courier,monospace;">voronoi.hpp</span> defines following static functions:<br>
+ <h1>Basic and Advanced Usage Cases</h1>The main library header <span style="font-family: Courier New,Courier,monospace;">voronoi.hpp</span> defines following static functions:<br>
<br>
<table style="text-align: left; width: 100%;" border="1" cellpadding="2" cellspacing="2">
<tbody>
@@ -236,14 +237,14 @@
<br>
Isn't that simple? The library also provides clear interfaces to associate user data with output geometries, efficiently traverse Voronoi graph and utilities to visualize output primitives (e.g. discretization of parabolic edges, clipping of linear edges). More details on those is covered in the basic Voronoi tutorial. Advanced usage of the library with configuration of the coordinate types is explained in the advanced Voronoi tutorial.<br>
- <h1>Extendable for user provided coordinate types</h1>
+ <h1>Extendable for User Provided Coordinate Types</h1>
Voronoi implementation is coordinate type agnostic. That means that as soon as user provided types satisfy set of Voronoi builder coordinate type traits restrictions
and implement library required methods no changes are requied neither
from algorithm, nor from predicates implementation. So it's possible to
construct Voronoi diagram for 256 bit integer input coordinate type and
512 bit output floating-pont type without changing any internal code.<br>
- <h1>Bright future<br>
+ <h1>Bright Future<br>
</h1>
Below one may find list of main directions for the future development of the library.<br>
<br>
Modified: sandbox/gtl/doc/voronoi_predicates.htm
==============================================================================
--- sandbox/gtl/doc/voronoi_predicates.htm (original)
+++ sandbox/gtl/doc/voronoi_predicates.htm 2012-03-26 17:43:16 EDT (Mon, 26 Mar 2012)
@@ -10,6 +10,7 @@
+
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252"><title>Contents</title></head><body>
@@ -145,7 +146,7 @@
come up with two decisions: 1) output the value; 2) recompute the
expression using multi precision type. The way relative errors are
evaluated is explained in the Voronoi Robust FPT section.<br>
-<h1>Multiple Precision arithmetic</h1>In the vast majority of cases
+<h1>Multiple Precision Arithmetic</h1>In the vast majority of cases
lazy arithmetic approach produces correct result thus furhter
processing is not required. In other cases Voronoi defined or user
provided multiple precision types are used to produce correct result.
Boost-Commit 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