numerics.xml revision 1.1.1.1
1<?xml version='1.0'?> 2<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" 3 "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" 4[ ]> 5 6<chapter id="std.numerics" xreflabel="Numerics"> 7<?dbhtml filename="numerics.html"?> 8 9<chapterinfo> 10 <keywordset> 11 <keyword> 12 ISO C++ 13 </keyword> 14 <keyword> 15 library 16 </keyword> 17 </keywordset> 18</chapterinfo> 19 20<title> 21 Numerics 22 <indexterm><primary>Numerics</primary></indexterm> 23</title> 24 25<!-- Sect1 01 : Complex --> 26<sect1 id="std.numerics.complex" xreflabel="complex"> 27<?dbhtml filename="complex.html"?> 28 <title>Complex</title> 29 <para> 30 </para> 31 <sect2 id="numerics.complex.processing" xreflabel="complex Processing"> 32 <title>complex Processing</title> 33 <para> 34 </para> 35 <para>Using <code>complex<></code> becomes even more comple- er, sorry, 36 <emphasis>complicated</emphasis>, with the not-quite-gratuitously-incompatible 37 addition of complex types to the C language. David Tribble has 38 compiled a list of C++98 and C99 conflict points; his description of 39 C's new type versus those of C++ and how to get them playing together 40 nicely is 41<ulink url="http://david.tribble.com/text/cdiffs.htm#C99-complex">here</ulink>. 42 </para> 43 <para><code>complex<></code> is intended to be instantiated with a 44 floating-point type. As long as you meet that and some other basic 45 requirements, then the resulting instantiation has all of the usual 46 math operators defined, as well as definitions of <code>op<<</code> 47 and <code>op>></code> that work with iostreams: <code>op<<</code> 48 prints <code>(u,v)</code> and <code>op>></code> can read <code>u</code>, 49 <code>(u)</code>, and <code>(u,v)</code>. 50 </para> 51 52 </sect2> 53</sect1> 54 55<!-- Sect1 02 : Generalized Operations --> 56<sect1 id="std.numerics.generalized_ops" xreflabel="Generalized Ops"> 57<?dbhtml filename="generalized_numeric_operations.html"?> 58 <title>Generalized Operations</title> 59 <para> 60 </para> 61 62 <para>There are four generalized functions in the <numeric> header 63 that follow the same conventions as those in <algorithm>. Each 64 of them is overloaded: one signature for common default operations, 65 and a second for fully general operations. Their names are 66 self-explanatory to anyone who works with numerics on a regular basis: 67 </para> 68 <itemizedlist> 69 <listitem><para><code>accumulate</code></para></listitem> 70 <listitem><para><code>inner_product</code></para></listitem> 71 <listitem><para><code>chapterial_sum</code></para></listitem> 72 <listitem><para><code>adjacent_difference</code></para></listitem> 73 </itemizedlist> 74 <para>Here is a simple example of the two forms of <code>accumulate</code>. 75 </para> 76 <programlisting> 77 int ar[50]; 78 int someval = somefunction(); 79 80 // ...initialize members of ar to something... 81 82 int sum = std::accumulate(ar,ar+50,0); 83 int sum_stuff = std::accumulate(ar,ar+50,someval); 84 int product = std::accumulate(ar,ar+50,1,std::multiplies<int>()); 85 </programlisting> 86 <para>The first call adds all the members of the array, using zero as an 87 initial value for <code>sum</code>. The second does the same, but uses 88 <code>someval</code> as the starting value (thus, <code>sum_stuff == sum + 89 someval</code>). The final call uses the second of the two signatures, 90 and multiplies all the members of the array; here we must obviously 91 use 1 as a starting value instead of 0. 92 </para> 93 <para>The other three functions have similar dual-signature forms. 94 </para> 95 96</sect1> 97 98<!-- Sect1 03 : Interacting with C --> 99<sect1 id="std.numerics.c" xreflabel="Interacting with C"> 100<?dbhtml filename="numerics_and_c.html"?> 101 <title>Interacting with C</title> 102 103 <sect2 id="numerics.c.array" xreflabel="Numerics vs. Arrays"> 104 <title>Numerics vs. Arrays</title> 105 106 <para>One of the major reasons why FORTRAN can chew through numbers so well 107 is that it is defined to be free of pointer aliasing, an assumption 108 that C89 is not allowed to make, and neither is C++98. C99 adds a new 109 keyword, <code>restrict</code>, to apply to individual pointers. The 110 C++ solution is contained in the library rather than the language 111 (although many vendors can be expected to add this to their compilers 112 as an extension). 113 </para> 114 <para>That library solution is a set of two classes, five template classes, 115 and "a whole bunch" of functions. The classes are required 116 to be free of pointer aliasing, so compilers can optimize the 117 daylights out of them the same way that they have been for FORTRAN. 118 They are collectively called <code>valarray</code>, although strictly 119 speaking this is only one of the five template classes, and they are 120 designed to be familiar to people who have worked with the BLAS 121 libraries before. 122 </para> 123 124 </sect2> 125 126 <sect2 id="numerics.c.c99" xreflabel="C99"> 127 <title>C99</title> 128 129 <para>In addition to the other topics on this page, we'll note here some 130 of the C99 features that appear in libstdc++. 131 </para> 132 <para>The C99 features depend on the <code>--enable-c99</code> configure flag. 133 This flag is already on by default, but it can be disabled by the 134 user. Also, the configuration machinery will disable it if the 135 necessary support for C99 (e.g., header files) cannot be found. 136 </para> 137 <para>As of GCC 3.0, C99 support includes classification functions 138 such as <code>isnormal</code>, <code>isgreater</code>, 139 <code>isnan</code>, etc. 140 The functions used for 'long long' support such as <code>strtoll</code> 141 are supported, as is the <code>lldiv_t</code> typedef. Also supported 142 are the wide character functions using 'long long', like 143 <code>wcstoll</code>. 144 </para> 145 146 </sect2> 147</sect1> 148 149</chapter> 150