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