mirror of https://github.com/CGAL/cgal
Documentation update in respect to code fragments
Update of documentation in respect of code fragments - making code fragments work in footnotes - placing some words in in code tags - completing some words to code tags - removing some `#` as they are not necessary - don't show obfuscation code in email
This commit is contained in:
albert-github
parent
d433b1d61e
commit
461dba692d
|
|
@ -1739,7 +1739,7 @@ expected to either coincide with an existing vertex or lie inside a
|
|||
face. It is possible to invoke one of the specialized insertion
|
||||
functions (see Section \ref aos_ssec-basic-arr_class), based on the
|
||||
query results, and insert \f$c\f$ at its proper
|
||||
location.\cgalFootnote{The `CGAL::insert_non_intersecting_curve<>()`
|
||||
location.\cgalFootnote{The \cgalFootnoteCode{CGAL::insert_non_intersecting_curve<>()}
|
||||
function template, as all other functions reviewed in this section, is
|
||||
parameterized by an arrangement type and a point-location type (The
|
||||
latter must be substituted with a model of the
|
||||
|
|
@ -1832,7 +1832,7 @@ consider vertical line-segments to be weakly \f$x\f$-monotone).
|
|||
|
||||
Consider an arrangement of circles. A circle is obviously not
|
||||
\f$x\f$-monotone, so `CGAL::insert<>()` cannot be used in this
|
||||
case.\cgalFootnote{A key operation performed by `CGAL::insert<>()` is
|
||||
case.\cgalFootnote{A key operation performed by \cgalFootnoteCode{CGAL::insert<>()} is
|
||||
to locate the left endpoint of the curve in the arrangement. A circle,
|
||||
however, does not have any endpoints!} , it is necessary to subdivide
|
||||
each circle into two \f$x\f$-monotone circular arcs, namely, its upper
|
||||
|
|
@ -4142,7 +4142,7 @@ class template and the `Arr_segment_traits_2<Kernel>` class template
|
|||
are both parameterized by a geometric kernel and model the concepts
|
||||
`ArrangementTraits_2` and `ArrangementLandmarkTraits_2`.
|
||||
\cgalFootnote{They also model the refined concept
|
||||
`ArrangementDirectionalXMonotoneTraits_2`, which enables Boolean set
|
||||
\cgalFootnoteCode{ArrangementDirectionalXMonotoneTraits_2}, which enables Boolean set
|
||||
operations; see Package \ref PkgBooleanSetOperations2Ref.} The class
|
||||
template `Arr_non_caching_segment_traits_2<Kernel>` derives from the
|
||||
instance `Arr_non_caching_segment_basic_traits_2<Kernel>`, which
|
||||
|
|
@ -4940,9 +4940,9 @@ template parameter is defined as the `Coefficient` type. This type
|
|||
cannot be algebraic. Moreover, it is recommended that this type is not
|
||||
made rational either, since using rational (as opposed to integral)
|
||||
coefficients does not extend the range of the rational arcs and is
|
||||
typically less efficient.\cgalFootnote{The `Algebraic_kernel_d_1`
|
||||
typically less efficient.\cgalFootnote{The \cgalFootnoteCode{Algebraic_kernel_d_1}
|
||||
class template uses the types provided by the \ref PkgPolynomial
|
||||
package to define its nested `Polynomial_1` type and conveniently
|
||||
package to define its nested \cgalFootnoteCode{Polynomial_1} type and conveniently
|
||||
expose it to the user.} The `Bound` type, however, can be algebraic. A
|
||||
point of type \link Arr_rational_function_traits_2::Point_2
|
||||
`Point_2`\endlink nested in the `Arr_rational_function_traits_2` class
|
||||
|
|
@ -6749,7 +6749,7 @@ and defines a simple textual input/output format.
|
|||
<!-- ========================================================================= -->
|
||||
|
||||
\boost\cgalFootnote{See also \boost's homepage at:
|
||||
<TT>www.boost.org</TT>.} is a collection of portable \cpp libraries
|
||||
\cgalFootnoteCode{www.boost.org}.} is a collection of portable \cpp libraries
|
||||
that extend the \cpp Standard Library. The \boost Graph Library
|
||||
(\bgl), which one of the libraries in the collection, offers an
|
||||
extensive set of generic graph algorithms parameterized through
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@
|
|||
* `ArrangementOpenBoundaryTraits_2` must have all the four categories
|
||||
* convertible to `CGAL::Arr_open_side_tag`.\cgalFootnote{We intend to introduce
|
||||
* more concepts that require only a subset of the categories to be convertible
|
||||
* to `CGAL::Arr_open_side_tag`.} In this case the \dcel of the arrangement
|
||||
* to \cgalFootnoteCode{CGAL::Arr_open_side_tag}.} In this case the \dcel of the arrangement
|
||||
* instantiated with the model is initialized with an implicit bounding
|
||||
* rectangle. When the parameter space is bounded, it is the exact geometric
|
||||
* embedding of the implicit bounding rectangle.
|
||||
|
|
|
|||
|
|
@ -168,7 +168,7 @@ Section \ref bso_secbso_gen.
|
|||
|
||||
The basic components of our package are the free (global) functions
|
||||
`complement()` that accepts a single `Polygon_2` object, and
|
||||
`intersection()`, `join()`,\cgalFootnote{The function that computes the union of two polygons is called `join()`, since the word `union` is reserved in \cpp.} `difference()`,
|
||||
`intersection()`, `join()`,\cgalFootnote{The function that computes the union of two polygons is called \cgalFootnoteCode{join()}, since the word \cgalFootnoteCode{union} is reserved in \cpp.} `difference()`,
|
||||
`symmetric_difference()` and the predicate `do_intersect()`
|
||||
that accept two `Polygon_2` objects as their input. We explain how
|
||||
these functions should be used through several examples in the
|
||||
|
|
@ -702,7 +702,7 @@ The traits classes `Arr_segment_traits_2`,
|
|||
`Arr_conic_traits_2` and `Arr_rational_function_traits_2`, which are
|
||||
bundled in the `Arrangement_2` package and distributed with \cgal,
|
||||
are all models of the refined concept
|
||||
`ArrangementDirectionalXMonotoneTraits_2`.\cgalFootnote{The `Arr_polyline_traits_2` class is <I>not</I> a model of the, `ArrangementDirectionalXMonotoneTraits_2` concept, as the \f$ x\f$-monotone curve it defines is always directed from left to right. Thus, an opposite curve cannot be constructed. However, it is not very useful to construct a polygon whose edges are polylines, as an ordinary polygon with linear edges can represent the same entity.}
|
||||
`ArrangementDirectionalXMonotoneTraits_2`.\cgalFootnote{The \cgalFootnoteCode{Arr_polyline_traits_2} class is <I>not</I> a model of the, \cgalFootnoteCode{ArrangementDirectionalXMonotoneTraits_2} concept, as the \f$ x\f$-monotone curve it defines is always directed from left to right. Thus, an opposite curve cannot be constructed. However, it is not very useful to construct a polygon whose edges are polylines, as an ordinary polygon with linear edges can represent the same entity.}
|
||||
|
||||
Just as with the case of computations using models of the
|
||||
`ArrangementXMonotoneTraits_2` concept, operations are robust only
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ TDS_2, which don't reside in their own packages in the SCM.
|
|||
### Footnotes ###
|
||||
|
||||
A JQuery footnotes plug-in jquery.footnotes is used to handle
|
||||
footnotes. The special doxygen command \cgalFootnote expands to the
|
||||
footnotes. The special doxygen command `\cgalFootnote` expands to the
|
||||
appropriate html marker. Some JavaScript in `header.html` is used to
|
||||
append the `<ol div="autoFootnotes0">` to the current doc-content
|
||||
div. It is not added to the footer because this would break when tree
|
||||
|
|
|
|||
|
|
@ -243,13 +243,13 @@ The first list of items are meant as rules, <I>i.e.</I>, you should follow them.
|
|||
modify the object to which it is applied,
|
||||
<I>e.g.</I>, `class A { int f( void) const; };`. This should also be
|
||||
done when it is only conceptually `const`.
|
||||
This means that the member function `f()` is `c`onst as seen from
|
||||
This means that the member function `f()` is `const` as seen from
|
||||
the outside, but internally it may modify some data members
|
||||
that are declared `m`utable. An example
|
||||
that are declared `mutable`. An example
|
||||
is the caching of results from expensive computations. For more
|
||||
information about conceptually `c`onst functions and mutable data
|
||||
members see \cgalCite{cgal:m-ec-97}.
|
||||
- Prefer \cpp-style to C-style casts, <I>e.g.</I>, use `static_cast<double>( i)` instead of `(`double)i.
|
||||
- Prefer \cpp-style to C-style casts, <I>e.g.</I>, use `static_cast<double>( i)` instead of `(double)i`.
|
||||
- Protect header files against multiple inclusion, <I>e.g.</I> the file <TT>This_is_an_example.h</TT> should begin/end with
|
||||
\code{.cpp}
|
||||
#ifndef CGAL_THIS_IS_AN_EXAMPLE_H
|
||||
|
|
|
|||
|
|
@ -86,9 +86,9 @@ struct iterator_traits<T*> {
|
|||
|
||||
\section secinput_and_output_iterators Input and output iterators
|
||||
|
||||
<B>Operator * for input and output iterators</B>
|
||||
<B>Operator `*` for input and output iterators</B>
|
||||
|
||||
The operator * of input and output iterators has a restricted semantics.
|
||||
The operator `*` of input and output iterators has a restricted semantics.
|
||||
Input iterators are designed for input operations, and it is not
|
||||
required that the value type `T`
|
||||
of an input iterator `it` be assignable.
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ basic geometric entities of constant size\cgalFootnote{In dimension \f$ d\f$, an
|
|||
primitive operations on them. Each entity is provided as both a
|
||||
stand-alone class, which is parameterized by a kernel class, and as a
|
||||
type in the kernel class. Each operation in the kernel is provided via
|
||||
a functor class\cgalFootnote{A class which defines a member `operator()`.} in the kernel
|
||||
a functor class\cgalFootnote{A class which defines a member \cgalFootnoteCode{operator()}.} in the kernel
|
||||
class and also as either a member function or a global function.
|
||||
See \cgalCite{hhkps-aegk-01} for more details about this design.
|
||||
Ideally, if the kernel provides all the primitives required, you can
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
|
||||
\section Developer_manualThreadlocal Thread Local Storage
|
||||
|
||||
The header file <CGAL/tss.h> provides a macro `CGAL_STATIC_THREAD_LOCAL_VARIABLE(TYPE,VAR,ARG1)`
|
||||
The header file `<CGAL/tss.h>` provides a macro `CGAL_STATIC_THREAD_LOCAL_VARIABLE(TYPE,VAR,ARG1)`
|
||||
that creates a thread local variable `VAR` of type `TYPE`, and passes `ARG1` to the
|
||||
constructor. The variable is either `threadlocal`, or a `boost::thread_specific_ptr`,
|
||||
or just a local variable if `CGAL_HAS_THREADS` is not defined.
|
||||
|
|
@ -15,6 +15,6 @@ or just a local variable if `CGAL_HAS_THREADS` is not defined.
|
|||
|
||||
\section Developer_manualMutex Mutex
|
||||
|
||||
The header file <CGAL/mutex.h> provides a macro `CGAL_MUTEX` and a macro `CGAL_SCOPED_LOCK(M)` that is either a `std::unique_lock<std::mutex>` or a `boost::mutex::scoped_lock`.
|
||||
The header file `<CGAL/mutex.h>` provides a macro `CGAL_MUTEX` and a macro `CGAL_SCOPED_LOCK(M)` that is either a `std::unique_lock<std::mutex>` or a `boost::mutex::scoped_lock`.
|
||||
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ and FLTK adds `fl`. \leda uses prefix `leda_`
|
|||
|
||||
to some extent,
|
||||
but you have to tell \leda not to make the corresponding unprefixed names
|
||||
available as well.\cgalFootnote{\cgal's makefile does this by setting `-DLEDA_PREFIX`.} Initially, \cgal used
|
||||
available as well.\cgalFootnote{\cgal's makefile does this by setting \cgalFootnoteCode{-DLEDA_PREFIX}.} Initially, \cgal used
|
||||
prefix `CGAL_`.
|
||||
At the beginning of 1999, it was decided to drop prefix `CGAL_` and to
|
||||
introduce namespace `CGAL`.
|
||||
|
|
|
|||
|
|
@ -25,9 +25,9 @@ UML class diagram for faked object hierarchies (since 2.2-I-4).
|
|||
|
||||
Functions having a polymorphic return type create an object of the actual
|
||||
result type and wrap it into an object of type `Object`.
|
||||
Refer to the documentation of `#CGAL::Object` class for more details.
|
||||
Refer to the documentation of `CGAL::Object` class for more details.
|
||||
|
||||
An alternative is to use a class handling several output iterators at the same time such as the classes `#CGAL::Dispatch_output_iterator`.
|
||||
and `#CGAL::Dispatch_or_drop_output_iterator`.
|
||||
An alternative is to use a class handling several output iterators at the same time such as the classes `CGAL::Dispatch_output_iterator`.
|
||||
and `CGAL::Dispatch_or_drop_output_iterator`.
|
||||
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -219,19 +219,19 @@ where <I>os-compiler</I> refers to a string describing your
|
|||
operating system and compiler that is defined as follows.
|
||||
|
||||
<CENTER>
|
||||
<I>\f$ <\f$arch\f$ >\f$</I><TT><I>_</I></TT><I>\f$ <\f$os\f$ >\f$</I><TT><I>-</I></TT><I>\f$ <\f$os-version\f$ >\f$</I><TT><I>_</I></TT><I>\f$ <\f$comp\f$ >\f$</I><TT><I>-</I></TT><I>\f$ <\f$comp-version\f$ >\f$</I>
|
||||
<I>`<arch>_<os>-<os-version>_<comp>-<comp-version>`</I>
|
||||
|
||||
</CENTER>
|
||||
|
||||
<DL>
|
||||
<DT><B>\f$ <\f$arch\f$ >\f$</B><DD> is the system architecture as defined by <TT>uname -p</TT> or <TT>uname -m</TT>,
|
||||
<DT><B>\f$ <\f$os\f$ >\f$</B><DD> is the operating system as defined by <TT>uname
|
||||
<DT><B>`<arch>`</B><DD> is the system architecture as defined by <TT>uname -p</TT> or <TT>uname -m</TT>,
|
||||
<DT><B>`<os>`</B><DD> is the operating system as defined by <TT>uname
|
||||
-s</TT>,
|
||||
<DT><B>\f$ <\f$os-version\f$ >\f$</B><DD> is the operating system version as defined by
|
||||
"<TT>uname -r</TT>",
|
||||
<DT><B>\f$ <\f$comp\f$ >\f$</B><DD> is the basename of the compiler executable (if it
|
||||
<DT><B>`<os-version>`</B><DD> is the operating system version as defined by
|
||||
<TT>uname -r</TT>,
|
||||
<DT><B>`<comp>`</B><DD> is the basename of the compiler executable (if it
|
||||
contains spaces, these are replaced by "-"), and
|
||||
<DT><B>\f$ <\f$comp-version\f$ >\f$</B><DD> is the compiler's version number (which
|
||||
<DT><B>`<comp-version>`</B><DD> is the compiler's version number (which
|
||||
unfortunately can not be derived in a uniform manner, since it is
|
||||
quite compiler specific).
|
||||
</DL>
|
||||
|
|
@ -251,12 +251,12 @@ These test programs reside in the directory
|
|||
where <TT>$(CGAL_ROOT)</TT> represents the installation directory for the library.
|
||||
The names of all testfiles, which correspond to the names of the flags,
|
||||
|
||||
start with "<TT>CGAL_CFG_</TT>" followed by
|
||||
start with <TT>CGAL_CFG_</TT> followed by
|
||||
<UL>
|
||||
<LI><I>either</I> a description of a bug ending with
|
||||
"<TT>_BUG</TT>"
|
||||
<TT>_BUG</TT>
|
||||
<LI><I>or</I> a description of a feature starting with
|
||||
"<TT>NO_</TT>".
|
||||
<TT>NO_</TT>.
|
||||
</UL>
|
||||
For any of these files a corresponding flag is set in the
|
||||
platform-specific configuration file, iff either compilation or execution
|
||||
|
|
@ -304,7 +304,7 @@ up-to-date version of this list.
|
|||
\subsection secworkaround_macros Macros connected to workarounds/compilers
|
||||
|
||||
Some macros are defined according to certain workaround flags. This is
|
||||
done to avoid some \#`ifdef`s in our actual code.
|
||||
done to avoid some `#ifdef`s in our actual code.
|
||||
|
||||
<DL>
|
||||
<DT><B><TT>CGAL_LITTLE_ENDIAN</TT></B><DD> set, iff
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ Here is what you need:
|
|||
- define the environment variable `CGAL_DIR`. It should be the directory where you built CGAL.
|
||||
- <i>optional:</i> define the environment variables for Boost, GMP, and any optional third party lib, e.g. Eigen.
|
||||
- <i>On Windows:</i> define the environment variable `MAKE_CMD` (put the line `export MAKE_CMD=nmake` in your `$HOME/.bashrc` for VC++)
|
||||
- <i>On Windows:</i> define the environment variable `CMAKE_GENERATOR` (put the line `export CMAKE_GENERATOR='-GNMake Makefiles'` in your `$HOME/.bashrc` for VC++)
|
||||
- <i>On Windows:</i> define the environment variable `CMAKE_GENERATOR` (put the line <tt>export CMAKE_GENERATOR='-GNMake Makefiles'</tt> in your `$HOME/.bashrc` for VC++)
|
||||
- go in the directory you want to test
|
||||
- Run `cgal_test_with_cmake` in the `test` and `examples` directories of the package. This should run CMake, compile and run, and you can see what happened in the generated file `error.txt`.
|
||||
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@ scope of the traits class in order for the algorithm to work.
|
|||
As you can guess, `Left_turn_2` is responsible for the orientation
|
||||
test, while `Less_xy_2` does the sorting. So, obviously, the traits class
|
||||
must provide these three identifiers. The requirements it has to satisfy
|
||||
beyond that are documented in full with the concept ConvexHullTraits_2.
|
||||
beyond that are documented in full with the concept `ConvexHullTraits_2`.
|
||||
|
||||
\subsection subsectraits_class_requirements Traits class requirements
|
||||
|
||||
|
|
@ -92,7 +92,7 @@ Whenever you write a function or class that is parameterized with a traits
|
|||
class, you must provide the requirements that class has to fulfill. These
|
||||
requirements should be documented as a concept. For the
|
||||
example above, if you look in the manual at the description of the concept
|
||||
`#ConvexHullTraits_2`, you will find that the
|
||||
`ConvexHullTraits_2`, you will find that the
|
||||
traits class itself and the identifiers that are mentioned have to meet the
|
||||
following specifications:
|
||||
|
||||
|
|
@ -157,7 +157,7 @@ to the default traits class, and the last function parameter defaults to
|
|||
a default instance of the default traits class. Of course, such behavior
|
||||
must be specified in the \ref CGAL::ch_graham_andrew() "description of the function".
|
||||
|
||||
The implication is that a user can call `ch_graham_andrews` with
|
||||
The implication is that a user can call `ch_graham_andrew` with
|
||||
just three parameters, which delimit the iterator range to be handled and
|
||||
supply the iterator for the result. The types
|
||||
and primitives used by the algorithm in this case are the ones from the \cgal 2D and 3D kernel.
|
||||
|
|
|
|||
|
|
@ -11,11 +11,11 @@ supporting <a href="https://isocpp.org/wiki/faq/cpp14">C++14</a> or later.
|
|||
|
||||
| Operating System | Compiler |
|
||||
| :---------- | :--------------- |
|
||||
| Linux | \gnu `g++` 10.2.1 or later\cgalFootnote{<A HREF="http://gcc.gnu.org/">`http://gcc.gnu.org/`</A>} |
|
||||
| | `Clang` \cgalFootnote{<A HREF="http://clang.llvm.org/">`http://clang.llvm.org/`</A>} compiler version 13.0.0 |
|
||||
| \ms Windows | \gnu `g++` 10.2.1 or later\cgalFootnote{<A HREF="http://gcc.gnu.org/">`http://gcc.gnu.org/`</A>} |
|
||||
| | \ms Visual `C++` 14.0, 15.9, 16.10, 17.0 (\visualstudio 2015, 2017, 2019, and 2022)\cgalFootnote{<A HREF="https://visualstudio.microsoft.com/">`https://visualstudio.microsoft.com/`</A>} |
|
||||
| MacOS X | \gnu `g++` 10.2.1 or later\cgalFootnote{<A HREF="http://gcc.gnu.org/">`http://gcc.gnu.org/`</A>} |
|
||||
| Linux | \gnu `g++` 10.2.1 or later\cgalFootnote{<A HREF="http://gcc.gnu.org/">\cgalFootnoteCode{http://gcc.gnu.org/}</A>} |
|
||||
| | `Clang` \cgalFootnote{<A HREF="http://clang.llvm.org/">\cgalFootnoteCode{http://clang.llvm.org/}</A>} compiler version 13.0.0 |
|
||||
| \ms Windows | \gnu `g++` 10.2.1 or later\cgalFootnote{<A HREF="http://gcc.gnu.org/">\cgalFootnoteCode{http://gcc.gnu.org/}</A>} |
|
||||
| | \ms Visual `C++` 14.0, 15.9, 16.10, 17.0 (\visualstudio 2015, 2017, 2019, and 2022)\cgalFootnote{<A HREF="https://visualstudio.microsoft.com/">\cgalFootnoteCode{https://visualstudio.microsoft.com/}</A>} |
|
||||
| MacOS X | \gnu `g++` 10.2.1 or later\cgalFootnote{<A HREF="http://gcc.gnu.org/">\cgalFootnoteCode{http://gcc.gnu.org/}</A>} |
|
||||
| | Apple `Clang` compiler versions 10.0.1, 12.0.5, and 13.0.0 |
|
||||
|
||||
<!-- Windows supported version are also listed on windows.html (must change both) -->
|
||||
|
|
|
|||
|
|
@ -130,7 +130,7 @@ For example, you can add the path to the \boost `.dll` to the
|
|||
|
||||
| Variable | Description | Type |
|
||||
| :- | :- | :- |
|
||||
| `BOOST_ROOT`\cgalFootnote{The environment variable can be spelled either `BOOST_ROOT` or `BOOSTROOT`} | Root directory of your \boost installation | Either CMake or Environment |
|
||||
| `BOOST_ROOT`\cgalFootnote{The environment variable can be spelled either \cgalFootnoteCode{BOOST_ROOT} or \cgalFootnoteCode{BOOSTROOT}} | Root directory of your \boost installation | Either CMake or Environment |
|
||||
| `Boost_INCLUDE_DIR` | Directory containing the `boost/version.hpp` file | CMake |
|
||||
| `BOOST_INCLUDEDIR` | Idem | Environment |
|
||||
| `Boost_LIBRARY_DIRS` | Directory containing the compiled \boost libraries | CMake |
|
||||
|
|
|
|||
|
|
@ -354,6 +354,7 @@ ALIASES = "cgal=%CGAL" \
|
|||
"cgalModifEnd=\htmlonly </div> \endhtmlonly \latexonly END MODIFICATIONS \endlatexonly" \
|
||||
"cgalPkgBib{1}=<B>BibTeX:</B> <a href=\"../Manual/how_to_cite_cgal.html#\1-${CGAL_RELEASE_YEAR_ID}\">\1-${CGAL_RELEASE_YEAR_ID}</a><BR>" \
|
||||
"cgalFootnote{1}=<span class=\"footnote\">\1</span>" \
|
||||
"cgalFootnoteCode{1}=<tt style='display:inline'>\1</tt>" \
|
||||
"cgalAutoToc=\htmlonly[block] <div id=\"autotoc\" class=\"toc\"></div> \endhtmlonly" \
|
||||
"cgalTagTrue=\link CGAL::Tag_true `CGAL::Tag_true`\endlink" \
|
||||
"cgalTagFalse=\link CGAL::Tag_false `CGAL::Tag_false`\endlink" \
|
||||
|
|
|
|||
|
|
@ -107,6 +107,10 @@ span.legend {
|
|||
text-align: center;
|
||||
}
|
||||
|
||||
span.obfuscator {
|
||||
display: none;
|
||||
}
|
||||
|
||||
h3.version {
|
||||
font-size: 90%;
|
||||
text-align: center;
|
||||
|
|
|
|||
|
|
@ -353,7 +353,7 @@ assert( p == q );
|
|||
|
||||
In order to obtain the point corresponding to a vector \f$ v\f$ you simply
|
||||
have to add \f$ v\f$ to \ref ORIGIN. If you want to determine
|
||||
the point \f$ q\f$ in the middle between two points \f$ p_1\f$ and \f$ p_2\f$, you can write\cgalFootnote{you might call `midpoint(p_1,p_2)` instead.}
|
||||
the point \f$ q\f$ in the middle between two points \f$ p_1\f$ and \f$ p_2\f$, you can write\cgalFootnote{you might call \cgalFootnoteCode{midpoint(p_1,p_2)} instead.}
|
||||
|
||||
\code{.cpp}
|
||||
q = p_1 + (p_2 - p_1) / 2.0;
|
||||
|
|
|
|||
|
|
@ -349,7 +349,7 @@ assert( p == q );
|
|||
In order to obtain the point corresponding to a vector \f$ v\f$ you simply
|
||||
have to add \f$ v\f$ to `ORIGIN`. If you want to determine
|
||||
the point \f$ q\f$ in the middle between two points \f$ p_1\f$ and \f$ p_2\f$, you can
|
||||
write\cgalFootnote{you might call `midpoint(p_1,p_2)` instead}
|
||||
write\cgalFootnote{you might call \cgalFootnoteCode{midpoint(p_1,p_2)} instead}
|
||||
|
||||
\code{.cpp}
|
||||
q = p_1 + (p_2 - p_1) / 2.0;
|
||||
|
|
|
|||
|
|
@ -297,7 +297,7 @@ is a pair of vertices `(v,w)` with incidence operations `v = source(e)`, `w = ta
|
|||
`v` is called the adjacency list `A(v)`.
|
||||
|
||||
Edges are paired into twins. For each edge `e = (v,w)` there's an
|
||||
edge `twin(e) = (w,v)` and `twin(twin(e)) == e`\cgalFootnote{The existence of the edge pairs makes `P` a bidirected graph, the `twin` links make `P` a map.}.
|
||||
edge `twin(e) = (w,v)` and `twin(twin(e)) == e`\cgalFootnote{The existence of the edge pairs makes \cgalFootnoteCode{P} a bidirected graph, the \cgalFootnoteCode{twin} links make \cgalFootnoteCode{P} a map.}.
|
||||
|
||||
An edge `e = (v,w)` knows two adjacent edges `en = next(e)`
|
||||
and `ep = previous(e)` where `source(en) = w`,
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ An instance of this class represents an extension of the type `NT` by *one* squa
|
|||
|
||||
For example, let `Integer` be some type representing \f$ \Z\f$, then
|
||||
`Sqrt_extension<Integer,Integer>` is able to represent \f$ \Z[\sqrt{\mathrm{root}}]\f$
|
||||
for some arbitrary Integer \f$\mathrm{root}\f$. \cgalFootnote{\f$ R[a]\f$ denotes the extension of a ring \f$ R\f$ by an element \f$ a\f$. See also: <A HREF="http://mathworld.wolfram.com/ExtensionRing.html"><TT>http://mathworld.wolfram.com/ExtensionRing.html</TT></A>}
|
||||
for some arbitrary Integer \f$\mathrm{root}\f$. \cgalFootnote{\f$ R[a]\f$ denotes the extension of a ring \f$ R\f$ by an element \f$ a\f$. See also: <A HREF="http://mathworld.wolfram.com/ExtensionRing.html">\cgalFootnoteCode{http://mathworld.wolfram.com/ExtensionRing.html}</A>}
|
||||
The value of \f$\mathrm{root}\f$ is set at
|
||||
construction time, or set to zero if it is not specified.
|
||||
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ structure concepts see Section \ref PkgAlgebraicFoundationsRef.
|
|||
The built-in number types `float`, `double` and `long double` have
|
||||
the required arithmetic and comparison operators. They lack some required
|
||||
routines though which are automatically included by \cgal.
|
||||
\cgalFootnote{The functions can be found in the header files <TT>CGAL/int.h</TT>, <TT>CGAL/float.h</TT>, <TT>CGAL/double.h</TT> and <TT>CGAL/long_long.h</TT>.}
|
||||
\cgalFootnote{The functions can be found in the header files \cgalFootnoteCode{CGAL/int.h}, \cgalFootnoteCode{CGAL/float.h}, \cgalFootnoteCode{CGAL/double.h} and \cgalFootnoteCode{CGAL/long_long.h}.}
|
||||
|
||||
All built-in number types of \cpp can represent a discrete (bounded)
|
||||
subset of the rational numbers only. We assume that the
|
||||
|
|
|
|||
|
|
@ -236,7 +236,7 @@ structure of the innermost coefficient, for instance, a gcd is available
|
|||
if and only if the innermost coefficient is a `Field` or a
|
||||
`UniqueFactorizationDomain`. Hence, we can not provide a \f$ gcd\f$ if the
|
||||
innermost coefficient is just an `IntegralDomain` since it is simply
|
||||
not well defined\cgalFootnote{An example for such a number type is the template `Sqrt_extension<NT,ROOT>` representing an algebraic extension of degree two. This is just an `IntegralDomain` if NT is not a `Field`. }.
|
||||
not well defined\cgalFootnote{An example for such a number type is the template S\cgalFootnoteCode{qrt_extension<NT,ROOT>} representing an algebraic extension of degree two. This is just an \cgalFootnoteCode{IntegralDomain} if NT is not a `Field`. }.
|
||||
However, if we would consider the polynomial over the quotient field of the
|
||||
integral domain the \f$ gcd\f$ would be well defined. The only problem is
|
||||
that the result can not be represented over the ring since it contains
|
||||
|
|
|
|||
|
|
@ -6,8 +6,8 @@ namespace CGAL {
|
|||
\brief computes all furthest neighbors for the vertices of the convex
|
||||
polygon described by the range [`points_begin`, `points_end`), writes
|
||||
their indices (relative to `points_begin`) to `o`\cgalFootnote{the
|
||||
furthest neighbor of `points_begin[i]` is `points_begin[i-th number
|
||||
written to o]`} and returns the past-the-end iterator of this
|
||||
furthest neighbor of \cgalFootnoteCode{points_begin[i]} is \cgalFootnoteCode{points_begin[i-th number
|
||||
written to o]}} and returns the past-the-end iterator of this
|
||||
sequence.
|
||||
|
||||
The function `all_furthest_neighbors_2()` computes all furthest
|
||||
|
|
|
|||
Loading…
Reference in New Issue