--- /dev/null
+<?xml version='1.0'?>
+<!DOCTYPE part PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+ "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
+[ ]>
+
+<part id="manual.numerics" xreflabel="Numerics">
+<?dbhtml filename="numerics.html"?>
+
+<partinfo>
+ <keywordset>
+ <keyword>
+ ISO C++
+ </keyword>
+ <keyword>
+ library
+ </keyword>
+ </keywordset>
+</partinfo>
+
+<title>
+ Numerics
+ <indexterm><primary>Numerics</primary></indexterm>
+</title>
+
+<!-- Chapter 01 : Complex -->
+<chapter id="manual.numerics.complex" xreflabel="complex">
+<?dbhtml filename="complex.html"?>
+ <title>Complex</title>
+ <para>
+ </para>
+ <sect1 id="numerics.complex.processing" xreflabel="complex Processing">
+ <title>complex Processing</title>
+ <para>
+ </para>
+ <para>Using <code>complex<></code> becomes even more comple- er, sorry,
+ <emphasis>complicated</emphasis>, with the not-quite-gratuitously-incompatible
+ addition of complex types to the C language. David Tribble has
+ compiled a list of C++98 and C99 conflict points; his description of
+ C's new type versus those of C++ and how to get them playing together
+ nicely is
+<ulink url="http://david.tribble.com/text/cdiffs.htm#C99-complex">here</ulink>.
+ </para>
+ <para><code>complex<></code> is intended to be instantiated with a
+ floating-point type. As long as you meet that and some other basic
+ requirements, then the resulting instantiation has all of the usual
+ math operators defined, as well as definitions of <code>op<<</code>
+ and <code>op>></code> that work with iostreams: <code>op<<</code>
+ prints <code>(u,v)</code> and <code>op>></code> can read <code>u</code>,
+ <code>(u)</code>, and <code>(u,v)</code>.
+ </para>
+
+ </sect1>
+</chapter>
+
+<!-- Chapter 02 : Generalized Operations -->
+<chapter id="manual.numerics.generalized_ops" xreflabel="Generalized Ops">
+<?dbhtml filename="generalized_numeric_operations.html"?>
+ <title>Generalized Operations</title>
+ <para>
+ </para>
+
+ <para>There are four generalized functions in the <numeric> header
+ that follow the same conventions as those in <algorithm>. Each
+ of them is overloaded: one signature for common default operations,
+ and a second for fully general operations. Their names are
+ self-explanatory to anyone who works with numerics on a regular basis:
+ </para>
+ <itemizedlist>
+ <listitem><para><code>accumulate</code></para></listitem>
+ <listitem><para><code>inner_product</code></para></listitem>
+ <listitem><para><code>partial_sum</code></para></listitem>
+ <listitem><para><code>adjacent_difference</code></para></listitem>
+ </itemizedlist>
+ <para>Here is a simple example of the two forms of <code>accumulate</code>.
+ </para>
+ <programlisting>
+ int ar[50];
+ int someval = somefunction();
+
+ // ...initialize members of ar to something...
+
+ int sum = std::accumulate(ar,ar+50,0);
+ int sum_stuff = std::accumulate(ar,ar+50,someval);
+ int product = std::accumulate(ar,ar+50,1,std::multiplies<int>());
+ </programlisting>
+ <para>The first call adds all the members of the array, using zero as an
+ initial value for <code>sum</code>. The second does the same, but uses
+ <code>someval</code> as the starting value (thus, <code>sum_stuff == sum +
+ someval</code>). The final call uses the second of the two signatures,
+ and multiplies all the members of the array; here we must obviously
+ use 1 as a starting value instead of 0.
+ </para>
+ <para>The other three functions have similar dual-signature forms.
+ </para>
+
+</chapter>
+
+<!-- Chapter 03 : Interacting with C -->
+<chapter id="manual.numerics.c" xreflabel="Interacting with C">
+<?dbhtml filename="numerics_and_c.html"?>
+ <title>Interacting with C</title>
+
+ <sect1 id="numerics.c.array" xreflabel="Numerics vs. Arrays">
+ <title>Numerics vs. Arrays</title>
+
+ <para>One of the major reasons why FORTRAN can chew through numbers so well
+ is that it is defined to be free of pointer aliasing, an assumption
+ that C89 is not allowed to make, and neither is C++98. C99 adds a new
+ keyword, <code>restrict</code>, to apply to individual pointers. The
+ C++ solution is contained in the library rather than the language
+ (although many vendors can be expected to add this to their compilers
+ as an extension).
+ </para>
+ <para>That library solution is a set of two classes, five template classes,
+ and "a whole bunch" of functions. The classes are required
+ to be free of pointer aliasing, so compilers can optimize the
+ daylights out of them the same way that they have been for FORTRAN.
+ They are collectively called <code>valarray</code>, although strictly
+ speaking this is only one of the five template classes, and they are
+ designed to be familiar to people who have worked with the BLAS
+ libraries before.
+ </para>
+
+ </sect1>
+
+ <sect1 id="numerics.c.c99" xreflabel="C99">
+ <title>C99</title>
+
+ <para>In addition to the other topics on this page, we'll note here some
+ of the C99 features that appear in libstdc++.
+ </para>
+ <para>The C99 features depend on the <code>--enable-c99</code> configure flag.
+ This flag is already on by default, but it can be disabled by the
+ user. Also, the configuration machinery will disable it if the
+ necessary support for C99 (e.g., header files) cannot be found.
+ </para>
+ <para>As of GCC 3.0, C99 support includes classification functions
+ such as <code>isnormal</code>, <code>isgreater</code>,
+ <code>isnan</code>, etc.
+ The functions used for 'long long' support such as <code>strtoll</code>
+ are supported, as is the <code>lldiv_t</code> typedef. Also supported
+ are the wide character functions using 'long long', like
+ <code>wcstoll</code>.
+ </para>
+
+ </sect1>
+</chapter>
+
+</part>
projects / msp430-gcc.git / blobdiff