148fb7bfaSmrg<chapter xmlns="http://docbook.org/ns/docbook" version="5.0" 248fb7bfaSmrg xml:id="std.numerics" xreflabel="Numerics"> 34fee23f9Smrg<?dbhtml filename="numerics.html"?> 44fee23f9Smrg 548fb7bfaSmrg<info><title> 64fee23f9Smrg Numerics 74fee23f9Smrg <indexterm><primary>Numerics</primary></indexterm> 84fee23f9Smrg</title> 948fb7bfaSmrg <keywordset> 1048fb7bfaSmrg <keyword>ISO C++</keyword> 1148fb7bfaSmrg <keyword>library</keyword> 1248fb7bfaSmrg </keywordset> 1348fb7bfaSmrg</info> 1448fb7bfaSmrg 1548fb7bfaSmrg 164fee23f9Smrg 174fee23f9Smrg<!-- Sect1 01 : Complex --> 1848fb7bfaSmrg<section xml:id="std.numerics.complex" xreflabel="complex"><info><title>Complex</title></info> 194fee23f9Smrg<?dbhtml filename="complex.html"?> 2048fb7bfaSmrg 214fee23f9Smrg <para> 224fee23f9Smrg </para> 2348fb7bfaSmrg <section xml:id="numerics.complex.processing" xreflabel="complex Processing"><info><title>complex Processing</title></info> 2448fb7bfaSmrg 254fee23f9Smrg <para> 264fee23f9Smrg </para> 274fee23f9Smrg <para>Using <code>complex<></code> becomes even more comple- er, sorry, 284fee23f9Smrg <emphasis>complicated</emphasis>, with the not-quite-gratuitously-incompatible 294fee23f9Smrg addition of complex types to the C language. David Tribble has 304fee23f9Smrg compiled a list of C++98 and C99 conflict points; his description of 314fee23f9Smrg C's new type versus those of C++ and how to get them playing together 324fee23f9Smrg nicely is 3348fb7bfaSmrg<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://david.tribble.com/text/cdiffs.htm#C99-complex">here</link>. 344fee23f9Smrg </para> 354fee23f9Smrg <para><code>complex<></code> is intended to be instantiated with a 364fee23f9Smrg floating-point type. As long as you meet that and some other basic 374fee23f9Smrg requirements, then the resulting instantiation has all of the usual 384fee23f9Smrg math operators defined, as well as definitions of <code>op<<</code> 394fee23f9Smrg and <code>op>></code> that work with iostreams: <code>op<<</code> 404fee23f9Smrg prints <code>(u,v)</code> and <code>op>></code> can read <code>u</code>, 414fee23f9Smrg <code>(u)</code>, and <code>(u,v)</code>. 424fee23f9Smrg </para> 4348fb7bfaSmrg <para>As an extension to C++11 and for increased compatibility with C, 4448fb7bfaSmrg <code><complex.h></code> includes both <code><complex></code> 4548fb7bfaSmrg and the C99 <code><complex.h></code> (if the C library provides 4648fb7bfaSmrg it). 4748fb7bfaSmrg </para> 484fee23f9Smrg 4948fb7bfaSmrg </section> 5048fb7bfaSmrg</section> 514fee23f9Smrg 524fee23f9Smrg<!-- Sect1 02 : Generalized Operations --> 5348fb7bfaSmrg<section xml:id="std.numerics.generalized_ops" xreflabel="Generalized Ops"><info><title>Generalized Operations</title></info> 544fee23f9Smrg<?dbhtml filename="generalized_numeric_operations.html"?> 5548fb7bfaSmrg 564fee23f9Smrg <para> 574fee23f9Smrg </para> 584fee23f9Smrg 594fee23f9Smrg <para>There are four generalized functions in the <numeric> header 604fee23f9Smrg that follow the same conventions as those in <algorithm>. Each 614fee23f9Smrg of them is overloaded: one signature for common default operations, 624fee23f9Smrg and a second for fully general operations. Their names are 634fee23f9Smrg self-explanatory to anyone who works with numerics on a regular basis: 644fee23f9Smrg </para> 654fee23f9Smrg <itemizedlist> 664fee23f9Smrg <listitem><para><code>accumulate</code></para></listitem> 674fee23f9Smrg <listitem><para><code>inner_product</code></para></listitem> 68*4d5abbe8Smrg <listitem><para><code>partial_sum</code></para></listitem> 694fee23f9Smrg <listitem><para><code>adjacent_difference</code></para></listitem> 704fee23f9Smrg </itemizedlist> 714fee23f9Smrg <para>Here is a simple example of the two forms of <code>accumulate</code>. 724fee23f9Smrg </para> 734fee23f9Smrg <programlisting> 744fee23f9Smrg int ar[50]; 754fee23f9Smrg int someval = somefunction(); 764fee23f9Smrg 774fee23f9Smrg // ...initialize members of ar to something... 784fee23f9Smrg 794fee23f9Smrg int sum = std::accumulate(ar,ar+50,0); 804fee23f9Smrg int sum_stuff = std::accumulate(ar,ar+50,someval); 814fee23f9Smrg int product = std::accumulate(ar,ar+50,1,std::multiplies<int>()); 824fee23f9Smrg </programlisting> 834fee23f9Smrg <para>The first call adds all the members of the array, using zero as an 844fee23f9Smrg initial value for <code>sum</code>. The second does the same, but uses 854fee23f9Smrg <code>someval</code> as the starting value (thus, <code>sum_stuff == sum + 864fee23f9Smrg someval</code>). The final call uses the second of the two signatures, 874fee23f9Smrg and multiplies all the members of the array; here we must obviously 884fee23f9Smrg use 1 as a starting value instead of 0. 894fee23f9Smrg </para> 904fee23f9Smrg <para>The other three functions have similar dual-signature forms. 914fee23f9Smrg </para> 924fee23f9Smrg 9348fb7bfaSmrg</section> 944fee23f9Smrg 954fee23f9Smrg<!-- Sect1 03 : Interacting with C --> 9648fb7bfaSmrg<section xml:id="std.numerics.c" xreflabel="Interacting with C"><info><title>Interacting with C</title></info> 974fee23f9Smrg<?dbhtml filename="numerics_and_c.html"?> 984fee23f9Smrg 9948fb7bfaSmrg 10048fb7bfaSmrg <section xml:id="numerics.c.array" xreflabel="Numerics vs. Arrays"><info><title>Numerics vs. Arrays</title></info> 10148fb7bfaSmrg 1024fee23f9Smrg 1034fee23f9Smrg <para>One of the major reasons why FORTRAN can chew through numbers so well 1044fee23f9Smrg is that it is defined to be free of pointer aliasing, an assumption 1054fee23f9Smrg that C89 is not allowed to make, and neither is C++98. C99 adds a new 1064fee23f9Smrg keyword, <code>restrict</code>, to apply to individual pointers. The 1074fee23f9Smrg C++ solution is contained in the library rather than the language 1084fee23f9Smrg (although many vendors can be expected to add this to their compilers 1094fee23f9Smrg as an extension). 1104fee23f9Smrg </para> 1114fee23f9Smrg <para>That library solution is a set of two classes, five template classes, 11248fb7bfaSmrg and "a whole bunch" of functions. The classes are required 1134fee23f9Smrg to be free of pointer aliasing, so compilers can optimize the 1144fee23f9Smrg daylights out of them the same way that they have been for FORTRAN. 1154fee23f9Smrg They are collectively called <code>valarray</code>, although strictly 1164fee23f9Smrg speaking this is only one of the five template classes, and they are 1174fee23f9Smrg designed to be familiar to people who have worked with the BLAS 1184fee23f9Smrg libraries before. 1194fee23f9Smrg </para> 1204fee23f9Smrg 12148fb7bfaSmrg </section> 1224fee23f9Smrg 12348fb7bfaSmrg <section xml:id="numerics.c.c99" xreflabel="C99"><info><title>C99</title></info> 12448fb7bfaSmrg 1254fee23f9Smrg 1264fee23f9Smrg <para>In addition to the other topics on this page, we'll note here some 1274fee23f9Smrg of the C99 features that appear in libstdc++. 1284fee23f9Smrg </para> 1294fee23f9Smrg <para>The C99 features depend on the <code>--enable-c99</code> configure flag. 1304fee23f9Smrg This flag is already on by default, but it can be disabled by the 1314fee23f9Smrg user. Also, the configuration machinery will disable it if the 1324fee23f9Smrg necessary support for C99 (e.g., header files) cannot be found. 1334fee23f9Smrg </para> 1344fee23f9Smrg <para>As of GCC 3.0, C99 support includes classification functions 1354fee23f9Smrg such as <code>isnormal</code>, <code>isgreater</code>, 1364fee23f9Smrg <code>isnan</code>, etc. 1374fee23f9Smrg The functions used for 'long long' support such as <code>strtoll</code> 1384fee23f9Smrg are supported, as is the <code>lldiv_t</code> typedef. Also supported 1394fee23f9Smrg are the wide character functions using 'long long', like 1404fee23f9Smrg <code>wcstoll</code>. 1414fee23f9Smrg </para> 1424fee23f9Smrg 14348fb7bfaSmrg </section> 14448fb7bfaSmrg</section> 1454fee23f9Smrg 1464fee23f9Smrg</chapter> 147