00001 /* 00002 ------------------------------------------------------------------- 00003 00004 Copyright (C) 2006, 2007, 2008, Andrew W. Steiner 00005 00006 This file is part of O2scl. 00007 00008 O2scl is free software; you can redistribute it and/or modify 00009 it under the terms of the GNU General Public License as published by 00010 the Free Software Foundation; either version 3 of the License, or 00011 (at your option) any later version. 00012 00013 O2scl is distributed in the hope that it will be useful, 00014 but WITHOUT ANY WARRANTY; without even the implied warranty of 00015 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 00016 GNU General Public License for more details. 00017 00018 You should have received a copy of the GNU General Public License 00019 along with O2scl. If not, see <http://www.gnu.org/licenses/>. 00020 00021 ------------------------------------------------------------------- 00022 */ 00023 /** 00024 \mainpage O2scl User's Guide 00025 00026 \htmlonly 00027 <div align="right"><a href="dl_page.html"><b>Download 00028 O<span style='position: relative; top: 0.3em; 00029 font-size: 0.8em'>2</span>scl</b></a></div> 00030 \endhtmlonly 00031 00032 \o2 is a C++ class library for object-oriented numerical 00033 programming. It includes 00034 - Classes based on numerical routines from GSL and CERNLIB 00035 - Vector and matrix classes which are fully compatible with 00036 \c gsl_vector and \c gsl_matrix, yet offer indexing with 00037 \c operator[] and other object-oriented features 00038 - The CERNLIB-based classes are rewritten in C++ and are often 00039 faster than their GSL counterparts 00040 - Classes which require function inputs are designed to accept 00041 (public or private) member functions, even if they are virtual. 00042 - Classes use templated vector types, which allow the use of 00043 object-oriented vectors or C-style arrays. 00044 - Highly compatible - Recent versions have been tested on 00045 Linux (32- and 64-bit systems, with Intel and AMD chips), 00046 Windows XP with Cygwin, and MacOSX. 00047 - Free! \o2 is provided under Version 3 of the GNU 00048 Public License 00049 - Two mini-libraries 00050 <ul> 00051 <li>Thermodynamics of ideal and nearly-ideal particles with 00052 quantum statistics</li> 00053 <li>Equations of state for finite density relevant for 00054 neutron stars</li> 00055 </ul> 00056 00057 This is a beta version. The library should install and 00058 test successfully, and most of the classes are ready 00059 for production use. Some of the interfaces may change 00060 slightly in future versions. There are a few classes 00061 which are more experimental, and this is clearly stated 00062 at the top of the documentation for these classes. 00063 00064 See licensing information at \ref license_section. 00065 00066 \htmlonly 00067 <hr /> 00068 <a href="dl_page.html">Download 00069 O<span style='position: relative; top: 0.3em; font-size: 00070 0.8em'>2</span>scl</a> 00071 <a href="../latex/refman.pdf">PDF documentation</a> 00072 \endhtmlonly 00073 00074 \hline 00075 \section toc_section Quick Reference to User's Guide 00076 00077 - \ref install_section 00078 - \ref usage_section 00079 - \ref examples_section 00080 - \ref related_section 00081 - \ref cplxnum_section 00082 - \ref vecmat_section 00083 - \ref permute_section 00084 - \ref linalg_section 00085 - \ref intp_section 00086 - \ref const_section 00087 - \ref funct_section 00088 - \ref table_section 00089 - \ref string_section 00090 - \ref diff_section 00091 - \ref inte_section 00092 - \ref poly_section 00093 - \ref solve_section 00094 - \ref min_section 00095 - \ref conmin_section 00096 - \ref mcarlo_section 00097 - \ref anneal_section 00098 - \ref fit_section 00099 - \ref ode_section 00100 - \ref rng_section 00101 - \ref tintp_section 00102 - \ref gslcheb_section 00103 - \ref unitconv_section 00104 - \ref other_section 00105 - \ref lset_section 00106 - \ref io_section 00107 - \ref source_section 00108 - \ref design_section 00109 - \ref license_section 00110 - \ref ack_section 00111 - \ref ref_section 00112 - \ref todo 00113 - \ref bug 00114 00115 \htmlonly 00116 <UL><LI>Other mini-libraries 00117 <UL> 00118 <LI><B><a href="../part/html/index.html">Particles</a></b> 00119 <LI><B><a href="../eos/html/index.html">Equations of State</a></b> 00120 </UL> 00121 </LI> 00122 <br /> 00123 <li>Add-on library: There is also a related library, 00124 <a href='../../o2scl_ext/html/index.html'>O<span style='position: relative; top: 0.3em; font-size: 0.8em'>2</span>scl_ext</a>, 00125 which has a separate source distribution. 00126 </li> 00127 </UL> 00128 \endhtmlonly 00129 00130 \hline 00131 \section install_section Installation 00132 00133 The rules for installation are generally the same as that for 00134 other GNU libraries. The file \c INSTALL has some details on this 00135 procedure. Generally, you should be able to run 00136 <tt>./configure</tt> and then type \c make and \c make \c 00137 install. More information on the \c configure command can also be 00138 obtained from <tt>./configure --help</tt>. \o2 requires the GSL 00139 libraries. If the <tt>configure</tt> script cannot find them, you 00140 may have to specify their location in the <tt>CPPFLAGS</tt> and 00141 <tt>LDFLAGS</tt> environment variables (<tt>./configure 00142 --help</tt> shows some information on this). The documentation is 00143 automatically installed by \c make \c install. 00144 00145 After \c make \c install, you may test the library with \c make \c 00146 o2scl-test. At the moment, testing \o2 requires that you have 00147 <tt>grep, awk, tail, cat,</tt> and <tt>wc</tt> on your machine to 00148 summarize the test results, but this will hopefully be improved in 00149 later version. 00150 00151 This library requires GSL and is designed to work with GSL 00152 versions 1.12 or greater. Some classes may work with older 00153 versions of GSL, but this cannot be guaranteed. 00154 00155 Range-checking for vectors and matrices is performed similar to 00156 the GSL approach, and is turned on by default. You can 00157 disable range-checking by defining -DO2SCL_NO_RANGE_CHECK 00158 \code 00159 CPPFLAGS="-DO2SCL_NO_RANGE_CHECK" ./configure 00160 \endcode 00161 00162 The separate libraries \o2e and \o2p are installed by default. To 00163 disable the installation of these libraries and their associated 00164 documentation, run <tt>./configure</tt> with the flags \c 00165 --disable-eoslib or \c --disable-partlib. Note that \o2e depends 00166 on \o2p so using \c --disable-partlib without \c --disable-eoslib 00167 will not work. 00168 00169 There are several warning flags that are useful when configuring 00170 and compiling with \o2. See the GSL documentation for an 00171 excellent discussion, and also see the generic installation 00172 documentation in the file <tt>INSTALL</tt> in the \o2 top-level 00173 directory. For running \c configure, for example, if you do 00174 not have privileges to write to <tt>/usr/local</tt>, 00175 \code 00176 CPPFLAGS="-O3" -I/home/asteiner/install/include" \ 00177 LDFLAGS="-L/home/asteiner/install/lib" ./configure -C \ 00178 --prefix=/home/asteiner/install 00179 \endcode 00180 In this example, specifying 00181 <tt>-I/home/asteiner/install/include</tt> and 00182 <tt>-L/home/asteiner/install/lib</tt> above ensures that the GSL 00183 libraries can be found (this is where they are installed on my 00184 machine). The <tt>--prefix=/home/asteiner/install</tt> argument to 00185 <tt>./configure</tt> ensures that \o2 is installed there as well. 00186 00187 The documentation is generated with \doxygen. In principle, the 00188 documentation can be regenerated by the end-user, but this is 00189 not supported and requires several external applications 00190 not included in the distribution. 00191 00192 \b Un-installation: While there is no explicit "uninstall" 00193 procedure, there are only a couple places to check. Installation 00194 creates directories named <tt>o2scl</tt> in the include, doc and shared 00195 files directory (which default to \c /usr/local/include, \c 00196 /usr/local/doc, and \c /usr/local/share) which can be 00197 removed. Finally, all of the libraries are named with the prefix 00198 \c libo2scl and are created by default in /usr/local/lib. As 00199 configured with the settings above, the files are in \c 00200 /home/asteiner/install/include/o2scl, \c /home/asteiner/install/lib, 00201 \c /home/asteiner/install/share/o2scl, and \c 00202 /home/asteiner/install/doc/o2scl. 00203 00204 \hline 00205 \section usage_section General Usage 00206 00207 \subsection namespace_subsect Namespaces 00208 00209 Most of the classes reside in the namespace \c o2scl (this 00210 namespace has been removed from the documentation for 00211 clarity). Numerical constants (many of them based on the GSL 00212 constants) are placed in separate namespaces (gsl_cgs, gsl_cgsm, 00213 gsl_mks, gsl_mksa, gsl_num, o2scl_const, and o2scl_fm). There are 00214 also two namespaces which hold integration coefficients, 00215 o2scl_inte_qag_coeffs and o2scl_inte_qng_coeffs. 00216 00217 \subsection docconv_subsect Documentation conventions 00218 00219 In the following documentation, function parameters are denoted by 00220 \c parameter, except when used in mathematical formulas as in \f$ 00221 \mathrm{variable} \f$ . 00222 00223 \subsection nomen_subsect Nomenclature 00224 00225 Classes directly derived from the GNU Scientific Library are 00226 preceeded by the prefix \c gsl_ and classes derived from CERNLIB 00227 are preceeded by the prefix \c cern_. Some of those classes 00228 derived from GSL and CERNLIB operate slightly differently 00229 from the original versions. The differences are detailed 00230 in the corresponding class documentation. 00231 00232 \subsection errorhand_subsect Basic error handling 00233 00234 Error handling is similar to GSL. When an error occurs, functions 00235 and/or classes call a GSL-like error handler and (when 00236 appropriate) return a non-zero value. When functions succeed they 00237 return 0 (\ref gsl_success). The error handler, \ref err_hnd is a 00238 global pointer to an object of type \ref err_base. There is a 00239 global default error handler of type \ref err_class. The list of 00240 error codes is given in the documentation for the file \ref 00241 err_hnd.h. The default error handler can be replaced by simply 00242 assigning the address of a descendant of \ref err_base to \ref 00243 err_hnd. Most of the time, if a function returns an integer value, 00244 and the returned value is nonzero, then the error handler was 00245 called (at least once). Functions can return success even when the 00246 error handler was called during execution, and this happens 00247 particularly in template classes where templated methods are 00248 beyond the direct control of the function using them. Also, \o2 00249 functions never reset the error handler. 00250 00251 The default behavior for all errors is to store the error 00252 information, print the information to <tt>cout</tt> and call 00253 <tt>exit(error_number)</tt>. You can modify the behavior of the 00254 default error handler with the err_class::set_mode() function, 00255 Mode '2' is the default, mode '1' just prints the information, 00256 and mode '0' ignores the error. 00257 00258 Although \o2 does not yet have this functionality by default, it 00259 is striaghtforward to define an error handler which throws a C++ 00260 exception. Also, object destructors do not generally call the 00261 error handler. Internally, \o2 does not use <tt>try</tt> blocks, 00262 but these can easily be effectively employed by an \o2 user. 00263 00264 Errors can be set by the user through the macros \ref O2SCL_ERR, 00265 which sets an error, and \ref O2SCL_ERR_RET, which sets an error 00266 and returns the error number. 00267 00268 Functionality similar to assert() is provided with the macro 00269 \ref O2SCL_ASSERT, which exits if its argument is non-zero, and 00270 \ref O2SCL_BOOL_ASSERT which exits if its argument is false. 00271 00272 Note that the GSL function <tt>gsl_set_error_handler()</tt> is 00273 called in the abstract base class err_base to set the GSL error 00274 handler any time a new instance of \ref err_base is created. If 00275 the user creates a new handler, that new handler will be used by 00276 GSL functions as well. 00277 00278 \subsection errorhand2_subsect What is an error? 00279 00280 \o2 assumes that errors are events which should 00281 happen infrequently. Error handling strategies are often 00282 time-consuming and they are not a replacement for normal code 00283 flow. However, even with this in mind, one can still distinguish a 00284 large spectrum of posibillities from "fatal" errors, those likely 00285 to corrupt the stack and/or cause a dreaded "segmentation fault" 00286 and "non-fatal" errors, those errors which might cause incorrect 00287 results, but might be somehow recoverable. One of the purposes of 00288 error handling is to decide if and how these different types of 00289 errors should be handled differently. Most errors in \o2 result 00290 in a call to the error handler by default. Some of the classes 00291 which attempt to reach numerical convergence have an option (e.g. 00292 mroot::err_nonconv) to turn this default behavior off for 00293 convergence errors (which are not necessarily "fatal" errors). To 00294 set these "convergence" errors, the macros \ref O2SCL_CONV and 00295 \ref O2SCL_CONV_RET can be used. 00296 00297 Another related issue is that \o2 often calls functions which are 00298 supplied by the user, these user-designed functions may create 00299 errors, and the library needs to decide how to deal with them, 00300 even though it knows little about what is actually happening 00301 inside these user-defined functions. Most of the time, \o2 assumes 00302 that if a function returns a nonzero value, then an error has 00303 occured and the present calculation should abort. 00304 00305 \subsection objscope_subsect Objects and scope 00306 00307 \o2 objects frequently take inputs which are of the form of a 00308 reference to a smaller object. This is particularly convenient 00309 because it allows a lot of flexibility, while providing a certain 00310 degree of safety. However, the user retains the responsibility of 00311 ensuring that input objects do not go out of scope before they are 00312 utilized by objects which require them. (This is actually no 00313 different than the requirements on the user imposed by GSL, for 00314 example.) 00315 00316 A simple example of this is provided by the simulated annealing 00317 class \ref gsl_anneal. Simulated annealing works by providing a 00318 temperature annealing schedule, which slowly decreases the 00319 temperature. However, if the temperature schedule object goes out 00320 of scope before the annealing is done, a segmentation fault will 00321 result. For example, the following code will fail: 00322 \include scope_doc.cpp 00323 00324 This will fail because the temperature schedule object goes out of 00325 scope (it's a local variable in the function and its destructor is 00326 called before the <tt>set_schedule()</tt> function exits) before 00327 the <tt>mmin()</tt> function is called. 00328 00329 \hline 00330 \section examples_section Compiling examples 00331 00332 The example programs are in the \c examples directory. After 00333 installation, they can be compiled and executed by running \c make 00334 \c o2scl-examples in that directory. This will also test the 00335 output of the examples to make sure it is correct and summarize 00336 these tests in \c examples-summary.txt. The output for each 00337 example is placed in the corresponding file with a <tt>.scr</tt> 00338 extension. 00339 00340 Alternatively, you can make the executable for each example in the 00341 \c examples directory individually using, e.g. <tt>make 00342 ex_mroot</tt>. 00343 00344 See \ref source_section for the documented source code 00345 of the individual examples 00346 00347 Also, the testing code for each class is sometimes useful for 00348 providing examples of their usage. The testing source code for 00349 each source file is named with an \c _ts.cpp prefix in the same 00350 directory as the class source. 00351 00352 \hline 00353 \section related_section Related projects 00354 00355 Several noteworthy related projects: 00356 00357 - GSL - The GNU Scientific Library \n The first truly free, 00358 ANSI-compliant, fully tested, and well-documented scientific 00359 computing library. The GSL is located at 00360 http://www.gnu.org/software/gsl . Manual is available at 00361 http://www.gnu.org/software/gsl/manual/html_node/ . Many GSL 00362 routines are included and reworked in \o2 (the corresponding 00363 classes begin with the \c gsl_ prefix) and \o2 was specifically 00364 designed to be used with GSL. GSL is a must-have for most serious 00365 numerical work in C or C++ and is required for installation of 00366 \o2. 00367 00368 - CERNLIB - The gold standard in FORTRAN computing libraries \n 00369 Several CERNLIB routines are rewritten completely in C++ and 00370 included in \o2 (they begin with the \c cern_ prefix). CERNLIB is 00371 located at http://cernlib.web.cern.ch/cernlib/mathlib.html 00372 00373 - LAPACK and ATLAS - The gold standard for linear algebra \n 00374 Available at http://www.netlib.org/lapack and 00375 http://www.netlib.org/atlas . See also 00376 http://www.netlib.org/clapack . 00377 00378 - QUADPACK - FORTRAN adaptive integration library \n This is the 00379 library on which the GSL integration routines are based (prefix \c 00380 gsl_inte_). It is available at http://www.netlib.org/quadpack . 00381 00382 - TNT - Template numerical toolkit (http://math.nist.gov) \n TNT 00383 provides vector and matrix types and basic arithmetic operations. 00384 Most of the classes in \o2 which use vector and matrix types are 00385 templated to allow compatbility with TNT. (Though there are a few 00386 small differences.) This software is in the public domain. 00387 00388 - Blitz++ - http://www.oonumerics.org/blitz \n Another linear 00389 algebra library designed in C++ which includes vector and matrix 00390 types and basic arithmetic. As the name implies, Blitz++ has the 00391 capability to be particularly fast. Distributed with a Perl-like 00392 artistic license "or the GPL". 00393 00394 - Boost - http://www.boost.org \n Free (license is compatible with 00395 GPL) peer-reviewed portable C++ source libraries that work well 00396 with the C++ Standard Library. Boost also contains uBlas, 00397 for linear algebra computing. For examples of how to use 00398 \o2 with uBlas vector and matrices, see \ref ex_ublas_sect. 00399 00400 - FLENS - http://flens.sourceforge.net \n A C++ library with 00401 object-oriented linear algebra types and an interface to BLAS 00402 and LAPACK. 00403 00404 - MESA - Modules for Experiments in Stellar Astrophysics 00405 (http://mesa.sourceforge.net) \n An excellent FORTRAN library with 00406 accurate low-density equations of state, interpolation, opacities 00407 and other routines useful in stellar physics. Work is currently 00408 under way to rewrite some of the MESA routines in C/C++ for \o2. 00409 Licensed with LGPL (not GPL). 00410 00411 - OOL - Open Optimization Library (http://ool.sourceforge.net) \n 00412 Constrained minimization library designed with GSL in mind. The 00413 \o2 constrained minimization classes are derived from this 00414 library. See \ref conmin_section . 00415 00416 - Root - CERN's new C++ analysis package (http://root.cern.ch) \n 00417 A gargantuan library for data analysis, focused mostly on 00418 high-energy physics. Their histograms, graphics, file I/O and 00419 support for large data sets is particuarly good. 00420 00421 \hline 00422 \section cplxnum_section Complex Numbers 00423 00424 Several arithmetic operations for \c gsl_complex are 00425 defined in cx_arith.h, but no constructor has been written. The 00426 object \c gsl_complex is still a \c struct, not a \c class. For 00427 example, 00428 \include cx_arith_doc.cpp 00429 00430 In case the user needs to convert between \c gsl_complex and \c 00431 std::complex<double>, two conversion functions gsl_to_complex() 00432 and complex_to_gsl() are also provided in \ref cx_arith.h. 00433 00434 \hline 00435 \section vecmat_section Arrays, Vectors, Matrices and Tensors 00436 00437 \subsection vmintro_subsect Introduction 00438 00439 The \o2 library uses a standard nomenclature to distinguish 00440 a couple different concepts. The word "array" is always used to 00441 refer to C-style arrays, i.e. \c double[]. If there are two 00442 dimensions in the array, it is a "two-dimensional array", i.e. \c 00443 double[][] . The word "vector" is reserved generic objects with 00444 array-like semantics, i.e. any type of object or class which can 00445 be treated similar to an array in that it has an function \c 00446 operator[] which gives array-like indexing. Thus arrays are 00447 vectors, but not all vectors are arrays. There are a couple 00448 specific vector types defined in \o2 like \ref ovector and \ref 00449 uvector . The STL vector <tt>std::vector<double></tt> is also a 00450 vector type in this language. The word "matrix" is reserved for 00451 the a generic object which has matrix-like semantics and can be 00452 accessed using either \c operator() or two successive applications 00453 of \c operator[] (or sometimes both). The \o2 objects \ref omatrix 00454 and \ref umatrix are matrix objects, as is a C-style 00455 two-dimensional array, \c double[][] . The header files are named 00456 in this spirit also: functions and classes which operate on 00457 generic vector types are in \ref vector.h and functions and 00458 classes which work only with C-style arrays are in \ref array.h . 00459 The word "tensor" is used for a generic object which has 00460 rank \c n and then has \c n associated indices. A vector is just 00461 a \tensor of rank 1 and a matrix is just a \tensor of rank 2. 00462 00463 Most of the classes in \o2 which use vectors and/or matrices are 00464 designed so that they can be used with any appropriately-defined 00465 vector or matrix types. This is a major part of the design goals 00466 for \o2 and most of the classes are compatible with matrix and 00467 vector objects from GSL, TNT, MV++, uBlas, and Blitz++. 00468 00469 The first index of a matrix type is defined always to be the index 00470 associated with "rows" and the second is associated with 00471 "columns". The \o2 matrix output functions respect this notation 00472 as well, so that all of the elements of the first row is sent to 00473 the screen, then all of the elements in the second row, and so on. 00474 With this in mind, one can make the distinction between 00475 "row-major" and "column-major" matrix storage. C-style 00476 two-dimensional arrays are "row-major" in that the elements 00477 of the first row occupy the first locations in memory as 00478 opposed "column-major" where the first column occupies the 00479 first locations in memory. It is important to note that the 00480 majority of the classes in \o2 do not care about the details 00481 of the underlying memory structure, so long as two 00482 successive applications of <tt>operator[]</tt> (or 00483 in some cases <tt>operator(,)</tt> ) works properly. The storage 00484 format used by \ref omatrix and \ref umatrix is row-major, and there 00485 are no column-major matrix classes in \o2 (yet). 00486 00487 \subsection index_subsect Matrix indexing with [][] vs. (,) 00488 00489 While vector indexing with \c operator[] is very compatible with 00490 almost any vector type, matrix indexing is a bit more difficult. 00491 There are two options: assume matrix objects provide an \c 00492 operator[] method which can be applied twice, i.e. 00493 <tt>m[i][j]</tt>, or assume that matrix elements should be 00494 referred to with <tt>m(i,j)</tt>. Most of the \o2 classes use the 00495 former approach so that they are also compatible with 00496 two-dimensional arrays. However, there are sometimes good reasons 00497 to want to use <tt>operator()</tt> for matrix-intensive operations 00498 from linear algebra. For this reason, some of the functions given 00499 in the <tt>linalg</tt> directory are specified in two forms: the 00500 first default form which assumes <tt>[][]</tt>, and the second 00501 form with the same name, but in a namespace which has a suffix 00502 <tt>_paren</tt> and assumes matrix types use <tt>(,)</tt>. 00503 00504 \subsection rowcol_subsect Rows and columns vs. x and y 00505 00506 Sometimes its useful to think about the rows and columns in a 00507 matrix as referring to a elements of a grid, and the matrix 00508 indices refer to points in a grid in \f$ (x,y) \f$. It might seem 00509 intuitive to think of a matrix as \c A[ix][iy] where \c ix and \c 00510 iy are the \f$ x \f$ and \f$ y \f$ indices because the ordering of 00511 the indices is alphabetical. However, it is useful to note that 00512 because functions like \ref matrix_out print the first "row" first 00513 rather than the first column, a matrix constructed as \c A[ix][iy] 00514 will be printed out with x on the "vertical axis" and y on the 00515 "horizontal axis", so it is sometimes useful to store data 00516 in the form \c A[iy][ix] (for example, in the two dimensional 00517 interpolation class, twod_intp). In any case, all classes 00518 which take matrix data as input will document how the matrix 00519 ought to be arranged. 00520 00521 \subsection genvec_subsection Generic vector functions 00522 00523 There are a couple functions which operate on generic vectors of 00524 any type in \ref vector.h . They perform sorting, summing, 00525 rotating, copying, and computations of minima and maxima. For 00526 more statistically-oriented operations, see also \ref vec_stats.h . 00527 00528 \subsection nativetypes_subsect Native matrix and vector types 00529 00530 The rest of this section in the User's guide is dedicated to 00531 describing the \o2 implementations of vector, matrix, 00532 and \tensor types. 00533 00534 Vectors and matrices are designed using the templates \ref 00535 ovector_tlate and \ref omatrix_tlate, which are compatible with \c 00536 gsl_vector and \c gsl_matrix. Vectors and matrices with unit 00537 stride are provided in \ref uvector_tlate and \ref umatrix_tlate. 00538 The most commonly used double-precision versions of these template 00539 classes are \ref ovector, \ref omatrix, \ref uvector and \ref 00540 umatrix, and their associated "views" (analogous to GSL vector and 00541 matrix views) which are named with a \c _view suffix. The classes 00542 \ref ovector_tlate and \ref omatrix_tlate offer the syntactic 00543 simplicity of array-like indexing, which is easy to apply to 00544 vectors and matrices created with GSL. 00545 00546 The following sections primarily discuss the operation objects of 00547 type \ref ovector. The generalizations to objects of type \ref 00548 uvector, \ref omatrix, and the complex vector and matrix objects 00549 \ref ovector_cx, \ref omatrix_cx, \ref uvector_cx, and \ref 00550 umatrix_cx are straightforward. 00551 00552 \subsection view_subsect Vector and matrix views 00553 00554 Vector and matrix views are provided as parents of the vector and 00555 matrix classes which do not have methods for memory allocation. As 00556 in GSL, it is simple to "view" normal C-style arrays or pointer 00557 arrays (see \ref ovector_array), parts of vectors (\ref 00558 ovector_subvector), and rows and columns of matrices (\ref 00559 omatrix_row and \ref omatrix_col). Several operations are defined, 00560 including addition, subtraction, and dot products. 00561 00562 \subsection typedef_subsect Vector and matrix typedefs 00563 00564 Several typedefs are used to give smaller names to often used 00565 templates. Vectors and matrices of double-precision numbers all 00566 begin with the prefixes \ref ovector and \ref omatrix. Integer 00567 versions begin with the prefixes \ref ovector_int and \ref 00568 omatrix_int. Complex versions have an additional \c "_cx", 00569 e.g. \ref ovector_cx. See \ref ovector_tlate.h, \ref 00570 ovector_cx_tlate.h, \ref omatrix_tlate.h, and \ref 00571 omatrix_cx_tlate.h. 00572 00573 \subsection unit_subsect Unit-stride vectors 00574 00575 The \ref uvector_tlate objects are naturally somewhat faster 00576 albeit less flexible than their finite-stride counterparts. 00577 Conversion to GSL vectors and matrices is not trivial for \ref 00578 uvector_tlate objects, but demands copying the entire 00579 vector. Vector views, operators, and the nomenclature is similar 00580 to that of \ref ovector. 00581 00582 \subsection memalloc_subsect Memory allocation 00583 00584 Memory for vectors can be allocated using ovector::allocate() and 00585 ovector::free(). Allocation can also be performed by the 00586 constructor, and the destructor automatically calls <tt>free()</tt> if 00587 necessary. In contrast to \c gsl_vector_alloc(), 00588 ovector::allocate() will call ovector::free(), if necessary, to 00589 free previously allocated space. Allocating memory does not clear 00590 the recently allocated memory to zero. You can use \ref 00591 ovector::set_all() with a zero argument to clear a vector 00592 (and similarly for a matrix). 00593 00594 If the memory allocation fails, either in the constructor or in 00595 allocate(), then the error handler will be called, partially 00596 allocated memory will be freed, and the size will be reset to 00597 zero. 00598 00599 Although memory allocation in \o2 vectors is very similar to 00600 that in GSL, the user must not mix allocation and deallocation 00601 between GSL and \o2. 00602 00603 \subsection getset_subsect Get and set 00604 00605 Vectors and matrices can be modified using ovector::get() and 00606 ovector::set() methods analogous to \c gsl_vector_get() and \c 00607 gsl_vector_set(), or they can be modified through 00608 ovector::operator[] (or ovector::operator() ), e.g. 00609 \comment 00610 For some reason the references to ovector::operator have been 00611 failing in the Doxygen compilation. 00612 \endcomment 00613 \code 00614 ovector a(4); 00615 a.set(0,2.0); 00616 a.set(1,3.0); 00617 a[2]=4.0; 00618 a[3]=2.0*a[1]; 00619 \endcode 00620 00621 If you want to set all of the values in an \ref ovector or an \ref 00622 omatrix at the same time, then use ovector::set_all() or 00623 omatrix::set_all(). 00624 00625 \subsection rangecheck_subsect Range checking 00626 00627 Range checking is performed depending on whether or not \c 00628 O2SCL_NO_RANGE_CHECK is defined. It can be defined in the 00629 arguments to \c ./configure upon installation to turn off range 00630 checking. Note that this is completely separate from the GSL range 00631 checking mechanism, so range checking may be on in \o2 even if 00632 it has been turned off in GSL. Range checking is used primarily 00633 in the vector, matrix, and \tensor \c get() and \c set() methods. 00634 00635 To see if range checking was turned on during installation 00636 (without calling the error handler), use 00637 lib_settings_class::range_check(). 00638 00639 Note that range checking in \o2 code is most often present in 00640 header files, rather than in source code. This means that range 00641 checking can be turned on or off in user-defined functions 00642 separately from whether or not it was used in the library classes 00643 and functions. 00644 00645 \subsection copy_subsect Shallow and deep copy 00646 00647 Copying \o2 vectors using constructors or the \c = operator 00648 is performed according to what kind of object is 00649 on the left-hand side (LHS) of the equals sign. If the LHS is a 00650 view, then a shallow copy is performed, and if the LHS is a \ref 00651 ovector, then a deep copy is performed. If an attempt is made to 00652 perform a deep copy onto a vector that has already been allocated, 00653 then that previously allocated memory is automatically freed. 00654 The user must be careful to ensure that information is not lost 00655 this way, even though no memory leak will occur. 00656 00657 For generic deep vector and matrix copying, you can use the 00658 template functions \ref vector_copy(), \ref matrix_copy(). These 00659 would allow you, for example, to copy an \ref ovector to a \c 00660 std::vector<double> object. These functions do not do any 00661 memory allocation so that must be handled beforehand by the user. 00662 00663 \subsection vecarith_subsect Vector and matrix arithmetic 00664 00665 Several operators are available as member functions of the 00666 corresponding template: 00667 00668 Vector_view unary operators: 00669 - vector_view += vector_view 00670 - vector_view -= vector_view 00671 - vector_view += scalar 00672 - vector_view -= scalar 00673 - vector_view *= scalar 00674 - scalar = norm(vector_view) 00675 00676 Matrix_view unary operators: 00677 - matrix_view += matrix_view 00678 - matrix_view -= matrix_view 00679 - matrix_view += scalar 00680 - matrix_view -= scalar 00681 - matrix_view *= scalar 00682 00683 Binary operators like addition, subtraction, and matrix 00684 multiplication are also defined for \ref ovector, \ref uvector, 00685 and related objects. The generic template for a binary operator, 00686 e.g. 00687 \code 00688 template<class vec_t> vec_t &operator+(vec_t &v1, vec_t &v2); 00689 \endcode 00690 is difficult because the compiler has no way of distinguishing vector 00691 and non-vector classes. At the moment, this is solved by 00692 creating a define macro for the binary operators. In addition 00693 to the predefined operators for native classes, the user may 00694 also define binary operators for other classes using the same 00695 macros. For example, 00696 \code 00697 O2SCL_OP_VEC_VEC_ADD(o2scl::ovector,std::vector<double>, 00698 std::vector<double>) 00699 \endcode 00700 would provide an addition operator for \ref ovector and vectors 00701 from the Standard Template Library. A full list of the 00702 operators which are defined by default and the associated macros 00703 are detailed in the documentation for \ref vec_arith.h. 00704 00705 The GSL BLAS routines can also be used directly with \ref ovector 00706 and \ref omatrix objects. 00707 00708 Note that some of these arithmetic operations succeed even with 00709 non-matching vector and matrix sizes. For example, adding a 3x3 00710 matrix to a 4x4 matrix will result in a 3x3 matrix and the 7 outer 00711 elements of the 4x4 matrix are ignored. 00712 00713 \subsection gslconv_subsect Converting to and from GSL forms 00714 00715 Because of the way \ref ovector is constructed, you may use 00716 type conversion to convert to and from objects of type \c gsl_vector. 00717 \code 00718 ovector a(2); 00719 a[0]=1.0; 00720 a[1]=2.0; 00721 gsl_vector *g=(gsl_vector *)(&a); 00722 cout << gsl_vector_get(g,0) << " " << gsl_vector_get(g,1) << endl; 00723 \endcode 00724 Or, 00725 \code 00726 gsl_vector *g=gsl_vector_alloc(2); 00727 gsl_vector_set(0,1.0); 00728 gsl_vector_set(1,2.0); 00729 ovector &a=(ovector &)(*g); 00730 cout << a[0] << " " << a[1] << endl; 00731 \endcode 00732 This sort of type-casting is discouraged among unrelated classes, 00733 but is permissible here because ovector_tlate is a descendant of 00734 gsl_vector. In particular, this will not generate "type-punning" 00735 warnings in later gcc versions. If this bothers your 00736 sensibilities, however, then you can use the following approach: 00737 \code 00738 ovector a(2); 00739 gsl_vector *g=a.get_gsl_vector(); 00740 \endcode 00741 The ease of converting between these two kind of objects makes it 00742 easy to use gsl functions on objects of type \ref ovector, i.e. 00743 \code 00744 ovector a(2); 00745 a[0]=2.0; 00746 a[1]=1.0; 00747 gsl_vector_sort((gsl_vector *)(&a)); 00748 cout << a[0] << " " << a[1] << endl; 00749 \endcode 00750 00751 \subsection stlconv_subsect Converting from STL form 00752 00753 To "view" a \c std::vector<double>, you can use \ref ovector_array 00754 \code 00755 std::vector<double> d; 00756 d.push_back(1.0); 00757 d.push_back(3.0); 00758 ovector_array aa(d.size,&(d[0])); 00759 cout << aa[0] << " " << aa[1] << endl; 00760 \endcode 00761 00762 However, you should note that if the memory for the \c std::vector 00763 is reallocated (for example because of a call to \c push_back()), 00764 then a previously created \ref ovector_view will be incorrect. 00765 00766 \subsection pushpop_subsect push_back() and pop() methods 00767 00768 These two functions give a behavior similar to the corresponding 00769 methods for \c std::vector<>. This will work in \o2 classes, 00770 but may not be compatible with all of the GSL functions. This 00771 will break if the address of a \ref ovector_tlate is given 00772 to a GSL function which accesses the \c block->size parameter 00773 instead of the \c size parameter of a \c gsl_vector. Please 00774 contact the author of \o2 if you find a GSL function with this 00775 behavior. 00776 00777 \subsection view_subsect Views 00778 00779 Views are slightly different than in GSL in that they are now 00780 implemented as parent classes. Effectively, this means that vector 00781 views are just the same as normal vectors, except that they have 00782 no memory allocation functions (because the memory is presumably 00783 owned by a different object or scope). The code 00784 \code 00785 double x[2]={1.0,2.0}; 00786 gsl_vector_view_array v(2,x); 00787 gsl_vector *g=&(v.vector); 00788 gsl_vector_set(g,0,3.0); 00789 cout << gsl_vector_get(g,0) << " " << gsl_vector_get(g,1) << endl; 00790 \endcode 00791 can be replaced by 00792 \code 00793 double x[2]={1.0,2.0}; 00794 ovector_array a(2,x); 00795 a[0]=3.0; 00796 cout << a << endl; 00797 \endcode 00798 00799 \subsection vecparm_subsect Passing ovector parameters 00800 00801 It is often best to pass an \ref ovector as a const reference 00802 to an \ref ovector_view, i.e. 00803 \code 00804 void function(const ovector_view &a); 00805 \endcode 00806 If the function may change the values in the \ref ovector, 00807 then just leave out \c const 00808 \code 00809 void function(ovector_view &a); 00810 \endcode 00811 This way, you ensure that the function is not allowed to modify 00812 the memory for the vector argument. 00813 00814 If you intend for a function (rather than the user) to handle 00815 the memory allocation, then some care is necessary. The 00816 following code 00817 \include ovector_doc1.cpp 00818 is confusing because the user may have already allocated memory 00819 for \c a. To avoid this, you may want to ensure that the user 00820 sends an empty vector. For example, 00821 \include ovector_doc2.cpp 00822 In lieu of this, it is often preferable to use a local variable for 00823 the storage and offer a \c get() function, 00824 \include ovector_doc3.cpp 00825 The \o2 classes run into this situation quite frequently, but 00826 the vector type is specified through a template 00827 \include ovector_doc4.cpp 00828 00829 \subsection eqoper_subsect Vectors and operator=() 00830 00831 An "operator=(value)" method for setting all vector elements to 00832 the same value is not included because it leads to confusion 00833 between, \c ovector_tlate::operator=(const data_t &val) and 00834 ovector_tlate::ovector_tlate(size_t val) For example, after 00835 implementing \c operator=() and executing the following 00836 \code 00837 ovector_int o1=2; 00838 ovector_int o2; 00839 o2=2; 00840 \endcode 00841 \c o1 will be a vector of size two, and \c o2 will be an 00842 empty vector! 00843 00844 To set all of the vector elements to the same value, use 00845 ovector_tlate::set_all(). Because of the existence of 00846 constructors like ovector_tlate::ovector_tlate(size_t val), the 00847 following code 00848 \code 00849 ovector_int o1=2; 00850 \endcode 00851 still compiles, and is equivalent to 00852 \code 00853 ovector_int o1(2); 00854 \endcode 00855 while the code 00856 \code 00857 ovector_int o1; 00858 o1=2; 00859 \endcode 00860 will not compile. As a matter of style, \c ovector_int \c o1(2); 00861 is preferable to \c ovector_int \c o1=2; to avoid confusion. 00862 00863 \subsection matstruct_subsect Matrix structure 00864 00865 The matrices from \ref omatrix_tlate 00866 are structured in exactly the same way as in GSL. 00867 For a matrix with 2 rows, 4 colums, and a "tda" or "trailing 00868 dimension" of 7, the memory for the matrix is structured in the 00869 following way: 00870 00871 \verbatim 00872 00 01 02 03 XX XX XX 00873 10 11 12 13 XX XX XX 00874 \endverbatim 00875 00876 where \c XX indicates portions of memory that are unreferenced. The tda 00877 can be accessed through, for example, the method 00878 omatrix_view_tlate::tda(). The \c get(size_t,size_t) methods 00879 always take the row index as the first argument and the column 00880 index as the second argument. The matrices from \ref umatrix_tlate 00881 have a trailing dimension which is always equal to the number of 00882 columns. 00883 00884 \subsection rev_subsect Reversing the order of vectors 00885 00886 You can get a reversed vector view from \ref 00887 ovector_reverse_tlate, or uvector_reverse_tlate. For these 00888 classes, \c operator[] and related methods are redefined to 00889 perform the reversal. If you want to make many calls to these 00890 indexing methods for a reversed vector, then simply copying the 00891 vector to a reversed version may be faster. 00892 00893 \subsection constvec_subsect Const-correctness with vectors 00894 00895 Vector objects, like \ref ovector, can be const in the usual way. 00896 However because vector views, like \ref ovector_view are like 00897 pointers to vectors, there are two ways in which they can be 00898 const. The view can point to a const vector, or the view can be a 00899 'const view' which is fixed to point only to one vector (whether 00900 or not the vector pointed to happens to be const). This is exactly 00901 analogous to the distinction between const double *p, double * 00902 const p, and const double * const p. The first is a non-const 00903 pointer to const data, the second is a const pointer to non-const 00904 data, and the third is a const pointer to const data. The 00905 equivalent expressions in \o2 are 00906 \code 00907 ovector_const_view v1; 00908 const ovector_view v2; 00909 const ovector_const_view v3; 00910 \endcode 00911 Explicitly, 00912 - <tt>ovector_const_view</tt> is a view of a const vector, the 00913 view may change, but the vector may not. 00914 - <tt>const ovector_const_view</tt> is a const view of a const 00915 vector, the view may not point to a different vector and the 00916 vector may not change. 00917 - <tt>const ovector_view</tt> is a const view of a normal vector, 00918 the view may not change, but the vector can. 00919 This same distinction is also present, for example, in ublas vectors 00920 views within boost. 00921 00922 A reference of type \ref ovector_base is often used as a function 00923 argument, and can hold either a \ref ovector or a \ref 00924 ovector_view. The important rule to remember with \ref ovector_base 00925 is that, a const reference, i.e. 00926 \code 00927 const ovector_base &v; 00928 \endcode 00929 is always a const reference to data which cannot be changed. A 00930 normal \ref ovector_base reference does not refer to const data. 00931 00932 \comment 00933 00934 Vector objects, like \ref ovector, can be const in the usual 00935 way. However, in order to properly prevent the user from 00936 making a non-const view of a const vector, A separate 00937 view class \ref ovector_const_view was created. To demonstrate, 00938 the following code is allowed 00939 \code 00940 ovector x(2); 00941 const ovector_view y=x; 00942 \endcode 00943 However, if the original vector is <tt>const</tt>, then the 00944 \ref ovector_const_view class should be used 00945 \code 00946 const ovector x(2); 00947 const ovector_const_view y=x; 00948 \endcode 00949 00950 \endcomment 00951 00952 \subsection vmout_subsect Vector and matrix output 00953 00954 Both the \ref ovector_view_tlate and \ref omatrix_view_tlate 00955 classes have an << operator defined for each class. For 00956 writing generic vectors to a stream, you can use \ref vector_out() 00957 which is defined in \ref vector.h . Pretty matrix output is 00958 performed by global template functions \ref matrix_out(), \ref 00959 matrix_cx_out_paren(), and \ref matrix_out_paren() which are 00960 defined in \ref columnify.h . 00961 00962 \subsection tensor_subsect Tensors 00963 00964 Some preliminary support is provided for tensors of arbitrary rank 00965 and size in the class \ref tensor. Classes \ref tensor1, \ref 00966 tensor2, \ref tensor3, and \ref tensor4 are rank-specific versions 00967 for 1-, 2-, 3- and 4-rank tensors. For n-dimsional data defined on 00968 a grid, \ref tensor_grid provides a space to define a hyper-cubic 00969 grid in addition to the the tensor data. This class \ref 00970 tensor_grid also provides n-dimensional interpolation of the data 00971 defined on the specified grid. 00972 00973 \hline 00974 \section permute_section Permutations 00975 00976 Permutations are implemented through the \ref permutation class. 00977 This class is fully compatible with gsl_permutation objects since 00978 it is inherited from gsl_permutation_struct. The class also 00979 contains no new data members, so upcasting and downcasting can 00980 always be performed. It is perfectly permissible to call 00981 GSL permutation functions from \ref permutation objects by 00982 simply passing the address of the permutation, i.e. 00983 \code 00984 permutation p(4); 00985 p.init(); 00986 gsl_permutation_swap(&p,2,3); 00987 \endcode 00988 00989 The functions which apply a permutation to a 00990 user-specified vector are member template functions in the \ref 00991 permutation class (see \ref permutation::apply() ). 00992 00993 Memory allocation/deallocation between the class and the 00994 gsl_struct is compatible in many cases, but mixing these forms is 00995 strongly discouraged, i.e. avoid using 00996 <tt>gsl_permutation_alloc()</tt> on a \ref permutation object, but 00997 rather use \ref permutation::allocate() instead. The use of \ref 00998 permutation::free() is encouraged, but any remaining memory will 00999 be deallocated in the object destructor. 01000 01001 \hline 01002 \section linalg_section Linear algebra 01003 01004 There is a small set of linear algebra routines. These are not 01005 intended to be a replacement for higher performance linear algebra 01006 libraries, but are designed for use by \o2 routines so that they 01007 work for generic matrix and vector types. For vector and matrix 01008 types using \c operator[], the BLAS and linear algebra routines 01009 are inside the \ref o2scl_cblas and \ref o2scl_linalg namespaces. 01010 For vector and matrix types using \c operator(), the BLAS and 01011 linear algebra routines routines are inside the \ref 01012 o2scl_cblas_paren and \ref o2scl_linalg_paren namespaces. 01013 01014 The linear algebra classes and functions include: 01015 - Householder transformations (\ref householder.h) 01016 - Householder solver (\ref hh.h) 01017 - LU decomposition and solver (\ref lu.h) 01018 - QR decomposition and solver (\ref qr.h) 01019 - Solve tridiagonal systems (\ref tridiag.h) 01020 - Lanczos diagonalization is inside class \ref lanczos, which 01021 also can compute the eigenvalues of a tridiagonal matrix. 01022 - Givens rotations (\ref givens.h) 01023 01024 There is also a set of linear solvers for generic matrix and 01025 vector types which descend from \ref o2scl_linalg::linear_solver. 01026 These classes provide GSL-like solvers, but are generalized so 01027 that they are compatible with vector and matrix types which allow 01028 access through <tt>operator[]</tt>. 01029 01030 For users who require high-performance linear algebra, the \ref 01031 ovector and \ref omatrix objects can be used to call LAPACK 01032 routines directly, just as can be done with GSL. For an example of 01033 how to do this, see 01034 http://sourceware.org/ml/gsl-discuss/2001/msg00326.html . For 01035 uBlas users, there is an example of how to use uBlas vectors with 01036 \o2 in \ref ex_ublas_sect. Finally, there are also a couple of 01037 examples, <tt>gesvd.cpp</tt> and <tt>zheev.cpp</tt> in the 01038 <tt>src/internal</tt> directory which show how to call LAPACK with 01039 \o2 objects which may be adaptable for your platform and 01040 configuration. 01041 01042 \hline 01043 \section intp_section Interpolation 01044 01045 The classes o2scl_interp and o2scl_interp_vec allow basic 01046 interpolation, lookup, differentiation, and integration of data 01047 given in two ovectors or ovector views. In contrast to the GSL 01048 routines, data which is presented with a decreasing independent 01049 variable is handled automatically. For interpolation with 01050 arrays rather than ovectors, use array_interp or array_interp_vec. 01051 01052 For fast interpolation of arrays where the independent variable 01053 is strictly increasing and without error-checking, you can directly 01054 use the children of \ref base_interp. 01055 01056 \subsection twoint_subsect The two interpolation interfaces 01057 01058 The difference between the two classes, o2scl_interp and 01059 o2scl_interp_vec, analogous to the difference between using \c 01060 gsl_interp_eval() and \c gsl_spline_eval() in \c GSL. You can 01061 create a o2scl_interp object and use it to interpolate among any 01062 pair of chosen vectors, i.e. 01063 \code 01064 ovector x(20), y(20); 01065 // fill x and y with data 01066 o2scl_interp oi; 01067 double y_half=oi.interp(0.5,20,x,y); 01068 \endcode 01069 Alternatively, you can create a o2scl_interp_vec object which can be 01070 optimized for a pair of vectors that you specify in advance 01071 \code 01072 ovector x(20), y(20); 01073 // fill x and y with data 01074 o2scl_interp_vec oi(20,x,y); 01075 double y_half=oi.interp(0.5); 01076 \endcode 01077 01078 \subsection search_subsect Lookup and binary search 01079 01080 The class search_vec contains a searching functions for objects of 01081 type \ref ovector which are monotonic. Note that if you want to 01082 find the index of an \ref ovector where a particular value is 01083 located without any assumptions with regard to the ordering, you 01084 can use ovector::lookup() which performs an exhaustive search. 01085 01086 \subsection smintp_subsect "Smart" interpolation 01087 01088 The classes smart_interp and smart_interp_vec allow interpolation, 01089 lookup, differentiation, and integration of data which is 01090 non-monotonic or multiply-valued outside the region of interest. 01091 As with o2scl_interp above, the corresponding array versions are 01092 given in sma_interp and sma_interp_vec. 01093 01094 \subsection lowinterp_subsect Lower-level interpolation objects 01095 01096 There are five lower-level interpolation objects which 01097 specify the basic \o2 interpolation types. They are 01098 - \ref linear_interp 01099 - \ref cspline_interp 01100 - \ref cspline_peri_interp 01101 - \ref akima_interp 01102 - \ref akima_peri_interp 01103 01104 \subsection interp_mgr_subsect Interpolation manager objects 01105 01106 Many \o2 classes require the ability to create and destroy 01107 interpolation objects at will, given one of the lower-level 01108 interpolation types described above. For this purpose, 01109 interpolation managers have been created, which allow the user to 01110 provide a class with an interpolation manager associated with a 01111 low-level interpolation type (and thus free the user from having 01112 to worry about the associated memory management). The abstract 01113 base interpolation manager type is \ref base_interp_mgr, and the 01114 default interpolation manager object is \ref def_interp_mgr . The 01115 \ref def_interp_mgr class has two template arguments: the first is 01116 the vector type to be interpolated, and the second is the 01117 lower-lever interpolation type. 01118 01119 For an example usage of the default interpolation manager, see 01120 the \ref ex_contour_sect , which specifies an interpolation manager 01121 for the \ref contour class. The \ref table class also works with 01122 interpolation manager objects (see \ref table::set_interp() ). 01123 01124 \subsection highdintp_subsect Two and higher dimensional interpolation 01125 01126 Support for two-dimensional interpolation (by successive 01127 one-dimensional interpolations) is given in \ref twod_intp (see 01128 \ref tintp_section, and a simple version of n-dimensional 01129 interpolation in \ref tensor_grid. 01130 01131 \hline 01132 \section const_section Physical constants 01133 01134 The constants from GSL are reworked with the type \c const \c 01135 double and placed in namespaces called gsl_cgs, gsl_cgsm, gsl_mks, 01136 gsl_mksa, and gsl_num. Some additional constants are given in the 01137 namespace o2scl_const. Some of the numerical values have been 01138 updated from recently released data from NIST. 01139 01140 \hline 01141 \section funct_section Function Objects 01142 01143 Functions are passed to numerical routines using template-based 01144 function classes, sometimes called "functors". There are several 01145 basic kinds of function 01146 objects: 01147 - \ref funct : One function of one variable 01148 - \ref multi_funct : One function of several variables 01149 - \ref mm_funct : \c n functions of \c n variables 01150 - \ref fit_funct : One function of one variable with \c n 01151 fitting parameters 01152 - \ref ode_funct : \c n derivatives as a function of \c n function 01153 values and the value of the independent variable 01154 - \ref jac_funct : Jacobian function for solver 01155 - \ref grad_funct : Gradient function for minimizers 01156 - \ref ool_hfunct : Hessian product for constrained minimization 01157 01158 For each of these classes (except \ref funct), there is a version 01159 named \c _vfunct instead of \c _funct which is designed to be used 01160 with C-style arrays instead of vector classes. 01161 01162 The class name suffixes denote children of a generic function type 01163 which are created using different kinds of inputs: 01164 - _fptr: function pointer for a static or global function 01165 - _gsl: GSL-like function pointer 01166 - _mfptr: function pointer template for a class member function 01167 - _cmfptr: function pointer template for a class member function which 01168 is const 01169 - _strings: functions specified using strings, e.g. "x^2-2", 01170 which are in the separate \o2x package. 01171 - _noerr: (for \ref funct and multi_funct) a function which 01172 directly returns the function value rather than returning 01173 an integer error value 01174 - _nopar: (for \ref funct) a function which has no parameters and 01175 directly returns the function value. 01176 01177 See the \ref ex_fptr_sect and the \ref ex_mroot_sect which 01178 provide detailed examples of how functions can be specified 01179 to classes through these function objects. 01180 01181 There is a small overhead associated with the indirection: a "user 01182 class" accesses the function class which then calls function which 01183 was specified in the constructor of the function class. In many 01184 problems, the overhead associated with the indirection is small. 01185 Some of this overhead can always be avoided by inheriting directly 01186 from the function class and thus the user class will make a direct 01187 virtual function call. To eliminate the overhead entirely, one can 01188 specify a new type for the template parameter in the user class. 01189 01190 Note that virtual functions can be specified through 01191 this mechanism as well. For example, if \ref cern_mroot 01192 is used to solve a set of equations specified as 01193 \include fptr_doc.cpp 01194 Then the solver will solve the member function in the derived 01195 type, not the parent type. 01196 01197 Note also that providing a user access to a function object 01198 instantiatied with a protected or private member function is 01199 (basically) the same as providing them access to that function. 01200 01201 \hline 01202 \section table_section Data tables 01203 01204 The class \ref table is a container to hold and perform operations 01205 on related columns of data. It supports column operations, 01206 interpolation, column reference by either name or index, binary 01207 searching (in the case of ordered columns), sorting, and fitting 01208 two columns to a user-specified function. 01209 01210 \hline 01211 \section string_section String manipulation 01212 01213 There are a couple classes and functions to help manipulate 01214 strings of text. Conversion routines for \c std::string 01215 objects are given in \ref string_conv.h and include 01216 - \ref ptos() - pointer to string 01217 - \ref itos() - integer to string 01218 - \ref dtos() - double to string 01219 - \ref stoi() - string to integer 01220 - \ref stod() - string to double 01221 01222 See also \ref size_of_exponent(), \ref format_float, 01223 and \ref double_to_ieee_string(). 01224 01225 A class called \ref columnify converts a set of 01226 strings into nicely formatted columns by padding with the 01227 necessary amount of spaces. This class operates on string objects 01228 of type \c std::string, and also works will for formatting columns 01229 of floating-point numbers. This class is used to provide output 01230 for matrices in the functions \ref matrix_out(), \ref 01231 matrix_out_paren(), and \ref matrix_cx_out_paren(). For output 01232 of vectors, see \ref vector_out() in \ref array.h. 01233 01234 A related function, \ref screenify(), reformats a column of 01235 strings into many columns stored row-by-row in a new string 01236 array. It operates very similar to the way the classic Unix 01237 command \c ls organizes files and directories in multiple columns 01238 in order to save screen space. 01239 01240 The function \ref count_words() counts the number of "words" 01241 in a string, which are delimited by whitespace. 01242 01243 \hline 01244 \section diff_section Differentiation 01245 01246 Differentiation is performed by descendants of \ref deriv and the 01247 classes are provided. These allow one to calculate either first, 01248 second, and third derivatives. The GSL approach is used in \ref 01249 gsl_deriv, and the CERNLIB routine is used in \ref 01250 cern_deriv. Both of these compute derivatives for a function 01251 specified using a descendant of \ref funct. For functions which 01252 are tabulated over equally-spaced abscissas, the class \ref 01253 eqi_deriv is provided which applies the formulas from Abramowitz 01254 and Stegun at a specified order. 01255 01256 \b Warning: For gsl_deriv and cern_deriv, the second and third 01257 derivatives are calculated by naive repeated application of the 01258 code for the first derivative and can be particularly troublesome 01259 if the function is not sufficiently smooth. Error estimation is 01260 also incorrect for second and third derivatives. 01261 01262 \hline 01263 \section inte_section Integration 01264 01265 Integration is performed by descendants of \ref inte and is 01266 provided in the library \c o2scl_inte. 01267 01268 There are several routines for one-dimensional integration. 01269 - General integration over a finite interval: cern_adapt, 01270 cern_gauss, cern_gauss56, gsl_inte_qag, and gsl_inte_qng. 01271 - General integration from 0 to \f$ \infty \f$ : gsl_inte_qagiu 01272 - General integration from \f$ -\infty \f$ to 0: gsl_inte_qagil 01273 - General integration from \f$ -\infty \f$ to \f$ \infty \f$ : 01274 gsl_inte_qagi 01275 - General integration over a finite interval for a function with 01276 singularities: gsl_inte_qags and gsl_inte_qagp 01277 - Cauchy principal value integration over a finite interval: 01278 cern_cauchy and gsl_inte_qawc 01279 - Integration over a function weighted by \c cos(x) or \c sin(x): 01280 \ref gsl_inte_qawo_cos and \ref gsl_inte_qawo_sin 01281 - Fourier integrals: \ref gsl_inte_qawf_cos and \ref 01282 gsl_inte_qawf_sin 01283 - Integration over a weight function 01284 \f[ 01285 W(x)=(x-a)^{\alpha}(b-x)^{\beta}\log^{\mu}(x-a)\log^{\nu}(b-x) 01286 \f] 01287 is performed by \ref gsl_inte_qaws. 01288 01289 For the GSL-based integration routines, the variables inte::tolx 01290 and inte::tolf have the same role as the quantities usually 01291 denoted in the GSL integration routines by \c epsabs and \c 01292 epsrel. In particular, the integration classes attempt to ensure 01293 that 01294 \f[ 01295 |\mathrm{result}-I| \leq \mathrm{Max}(\mathrm{tolx}, 01296 \mathrm{tolf}|I|) 01297 \f] 01298 and returns an error to attempt to ensure that 01299 \f[ 01300 |\mathrm{result}-I| \leq \mathrm{abserr} \leq 01301 \mathrm{Max}(\mathrm{tolx},\mathrm{tolf}|I|) 01302 \f] 01303 where \c I is the integral to be evaluated. Even when the 01304 corresponding descendant of inte::integ() returns success, these 01305 inequalities may fail for sufficiently difficult functions. All 01306 of the GSL integration routines except for gsl_inte_qng use 01307 a workspace given in gsl_inte_table which holds the results 01308 of the various subdivisions of the original interval. The 01309 size of this workspace (and thus then number of subdivisions) can 01310 be controlled with gsl_inte_table::set_wkspace(). 01311 01312 The GSL routines were originally based on QUADPACK, which is 01313 available at http://www.netlib.org/quadpack . 01314 01315 \note The GSL integration routines can sometimes lose precision 01316 if the integrand is everywhere much smaller than unity. Some 01317 rescaling is required in these cases. 01318 01319 Multi-dimensional hypercubic integration is performed by \ref 01320 composite_inte, the sole descendant of multi_inte. \ref 01321 composite_inte allows you to specify a set of one-dimensional 01322 integration routines (objects of type \ref inte) and apply them to 01323 a multi-dimensional problem. 01324 01325 General multi-dimensional integration is performed by \ref 01326 comp_gen_inte, the sole descendant of \ref gen_inte. The user is 01327 allowed to specify a upper and lower limits which are functions of 01328 the variables for integrations which have not yet been performed, 01329 i.e. the n-dimensional integral 01330 \f[ 01331 \int_{x_0=a_0}^{x_0=b_0} f(x_0) \int_{x_1=a_1(x_0)}^{x_1=b_1(x_0)} 01332 f(x_0, x_1) ... 01333 \int_{x_{\mathrm{n}-1}=a_{\mathrm{n}-1}(x_0,x_1,..,x_{\mathrm{n}-2})}^ 01334 {x_{\mathrm{n}-1}=b_{\mathrm{n}-1}(x_0,x_1,..,x_{\mathrm{n}-2})} 01335 f(x_0,x_1,...,x_{\mathrm{n-1}})~d x_{\mathrm{n}-1}~...~d x_1~d x_0 01336 \f] 01337 Again, one specifies a set of \ref inte objects to apply to 01338 each variable to be integrated over. 01339 01340 Monte Carlo integration is also provided (see \ref mcarlo_section). 01341 01342 \hline 01343 \section poly_section Roots of Polynomials 01344 01345 Classes are provided for solving quadratic, cubic, and quartic 01346 equations as well as general polynomials. There is a standard 01347 nomenclature: classes which handle polynomials with real 01348 coefficients and real roots end with the suffix <tt>_real</tt> 01349 (quadratic_real, cubic_real and quartic_real), classes which 01350 handle real coefficients and complex roots end with the suffix 01351 <tt>_real_coeff</tt> (quadratic_real_coeff, cubic_real_coeff, 01352 quartic_real_coeff, and poly_real_coeff), and classes which handle 01353 complex polynomials with complex coefficients end with the suffix 01354 <tt>_complex</tt> (quadratic_complex, cubic_complex, 01355 quartic_complex, and poly_complex). As a reminder, complex roots 01356 may not occur in conjugate pairs if the coefficients are not 01357 real. Most of these routines will return an error if the leading 01358 coefficient is zero. 01359 01360 In the public interfaces to the polynomial solvers, the 01361 complex type <tt>std::complex<double></tt> is used. These can 01362 be converted to and from the GSL complex type using the 01363 \ref complex_to_gsl() and \ref gsl_to_complex() functions. 01364 01365 At present, the polynomial routines work with complex numbers as 01366 objects of type \c std::complex<double> and are located in library 01367 \c o2scl_other. 01368 01369 For quadratics, \ref gsl_quadratic_real_coeff is the best if the 01370 coefficients are real, while if the coefficients are complex, use 01371 \ref quadratic_std_complex. For cubics with real coefficients, 01372 \ref cern_cubic_real_coeff is the best, while if the coefficients 01373 are complex, use \ref cubic_std_complex. 01374 01375 For a quartic polynomial with real coefficients, \ref 01376 cern_quartic_real_coeff is the best, unless the coefficients of 01377 odd powers happen to be small, in which case, \ref 01378 gsl_quartic_real2 tends to work better. For quartics, generic 01379 polynomial solvers such as \ref gsl_poly_real_coeff can provide 01380 more accurate (but slower) results. If the coefficients are 01381 complex, then you can use \ref simple_quartic_complex. 01382 01383 \hline 01384 \section solve_section Equation Solving 01385 01386 \subsection onedsolve_subsect One-dimensional solvers 01387 01388 Solution of one equation in one variable is accomplished by 01389 children of the class \ref root. 01390 01391 For one-dimensional solving, use cern_root or gsl_root_brent if 01392 you have the root bracketed, or gsl_root_stef if you have the 01393 derivative available. If you have neither a bracket or a 01394 derivative, you can use cern_mroot_root. 01395 01396 The \ref root base class provides the structure for three 01397 different solving methods: 01398 - \ref root::solve() which solves a function given an initial 01399 guess \c x 01400 - \ref root::solve_bkt() which solves a function given a solution 01401 bracketed between \c x1 and \c x2. The values of the function at 01402 \c x1 and \c x2 should have different signs. 01403 - \ref root::solve_de() which solves a function given an initial 01404 guess \c x and the derivative of the function \c df. 01405 01406 If not all of these three functions are overloaded, then the 01407 source code in the \ref root base class is designed to try to 01408 automatically provide the solution using the remaining 01409 functions. Most of the one-dimensional solving routines, in their 01410 original form, are written in the second or third form above. For 01411 example, gsl_root_brent is originally a bracketing routine of the 01412 form root::solve_bkt(), but calls to either root::solve() or 01413 root::solve_de() will attempt to automatically bracket the 01414 function given the initial guess that is provided. Of 01415 course, it is frequently most efficient to use the solver in the 01416 way it was intended. 01417 01418 \subsection multisolve_subsect Multi-dimensional solvers 01419 01420 Solution of more than one equation is accomplished by descendants 01421 of the class \ref mroot . The higher-level interface is provided 01422 by the function \ref mroot::msolve() . 01423 01424 For multi-dimensional solving, you can use either cern_mroot or 01425 gsl_mroot_hybrids. While cern_mroot cannot utilize user-supplied 01426 derivatives, gsl_mroot_hybrids can use user-supplied derivative 01427 information (as in the GSL hybridsj method) using the function 01428 \ref gsl_mroot_hybrids::msolve_de() . 01429 01430 \hline 01431 \section min_section Minimization 01432 01433 One-dimensional minimization is performed by descendants of \ref 01434 minimize . There are two one-dimensional minimization algorithms, 01435 \ref cern_minimize and \ref gsl_min_brent, and they are both 01436 bracketing algorithms type where an interval and an initial guess 01437 must be provided. If only an initial guess and no bracket is 01438 given, these two classes will attempt to find a suitable bracket 01439 from the initial guess. While the \ref minimize base class is 01440 designed to allow future descendants to optionally use derivative 01441 information, this is not yet supported for any one-dimensional 01442 minimizers. 01443 01444 Multi-dimensional minimization is performed by descendants of 01445 multi_min: \ref gsl_mmin_simp2, \ref gsl_mmin_conp, \ref 01446 gsl_mmin_conf, and \ref gsl_mmin_bfgs2. (The class \ref 01447 gsl_mmin_simp2 has been updated with the new "simplex2" method 01448 from GSL-1.12. The older "simplex" method is also available in 01449 \ref gsl_mmin_simp .) The classes \ref gsl_mmin_simp and \ref 01450 gsl_mmin_simp2 do not require any derivative information. The 01451 remaining minimization classes are intended for use when the 01452 gradient of the function is available, but they can also 01453 automaticallly compute the \gradient numerically. The standard way 01454 to provide the \gradient is to use a child of \ref grad_funct (or 01455 \ref grad_vfunct). Finally, the user may specify the automatic 01456 gradient object of type \ref gradient (or \ref gradient_array) 01457 which is used by the minimizer to compute the gradient numerically 01458 when a function is not specified. 01459 01460 See an example for the usage of the multi-dimensional minimizers 01461 in \ref ex_mmin_sect . 01462 01463 Simulated annealing methods are also provided for multi-dimensional 01464 minimization (see \ref anneal_section). 01465 01466 It is important to note that not all of the minimization routines 01467 test the second derivative to ensure that it doesn't vanish to 01468 ensure that we have indeed found a true minimum. 01469 01470 The class \ref multi_min_fix provides a convenient way of 01471 fixing some of the parameters and minimizing over others, 01472 without requiring a the function interface to be rewritten. An 01473 example is given in \ref ex_mmin_fix_sect. 01474 01475 A naive way of implementing constraints is to add a function to 01476 the original which increases the value outside of the allowed 01477 region. This can be done with the functions \ref constraint() and 01478 \ref lower_bound(). There are two analogous functions, \ref 01479 cont_constraint() and \ref cont_lower_bound(), which continuous 01480 and differentiable versions. Where possible, it is better to use 01481 the constrained minimization routines described below. 01482 01483 \hline 01484 \section conmin_section Constrained Minimization 01485 01486 \o2 reimplements the Open Optimization Library (OOL) available at 01487 http://ool.sourceforge.net. The associated classes allow 01488 constrained minimization when the constraint can be expressed as a 01489 hyper-cubic constraint on all of the independent variables. The 01490 routines have been rewritten and reformatted for C++ in order to 01491 facilitate the use of member functions and user-defined vector 01492 types as arguments. The base class is ool_constr_mmin and there 01493 are two different constrained minimzation algorithms implemented 01494 in ool_mmin_pgrad, ool_mmin_spg. (The ool_mmin_gencan minimizer is 01495 not yet finished). The \o2 implementation should be essentially 01496 identical to the most recently released version of OOL. 01497 01498 The constrained minimization classes operate in a similar way 01499 to the other multi-dimensional minimization classes (which are 01500 derived from multi_min). The constraints are specified with 01501 the function 01502 \code 01503 ool_constr_mmin::set_constraints(size_t nc, vec_t &lower, 01504 vec_t &upper); 01505 \endcode 01506 and the minimization can be performed by calling either 01507 multi_min::mmin() or multi_min::mmin_de() (if the \gradient is 01508 provided by the user). The method in \ref ool_mmin_gencan requires 01509 a Hessian vector product and the user can specify this product for 01510 the minimization by using \ref ool_constr_mmin::mmin_hess(). The 01511 Hessian product function can be specified as an object of type 01512 \ref ool_hfunct or \ref ool_hvfunct in a similar way to the other 01513 function objects in \o2. 01514 01515 There are five error codes defined in \ref ool_constr_mmin 01516 which are specific to the OOL classes. 01517 01518 \hline 01519 \section mcarlo_section Monte Carlo Integration 01520 01521 Monte Carlo integration is performed by descendants of mcarlo_inte 01522 (\ref gsl_monte, \ref gsl_miser, and \ref gsl_vegas). These 01523 routines are generally superior to the direct methods for 01524 integrals over regions with large numbers of spatial dimensions. 01525 01526 \hline 01527 \section anneal_section Simulated Annealing 01528 01529 Minimization by simulated annealing is performed by descendants of 01530 sim_anneal (see \ref gsl_anneal). Because simulated annealing is 01531 particularly well-suited to parallelization, a multi-threaded 01532 minimizer analogous to \ref gsl_anneal is given in \ref anneal_mt. 01533 This header-only class uses the Boost libraries and requires it 01534 for use. 01535 01536 \hline 01537 \section fit_section Non-linear Least-Squares Fitting 01538 01539 Fitting is performed by descendants of \ref fit_base and fitting 01540 functions can be specifed using \ref fit_funct. The GSL fitting 01541 routines (scaled and unscaled) are implemented in gsl_fit. A 01542 generic fitting routine using a minimizer object specified as a 01543 child of multi_min is implemented in min_fit. When the multi_min 01544 object is (for example) a sim_anneal object, min_fit can avoid 01545 local minima which can occur when fitting noisy data. 01546 01547 \hline 01548 \section ode_section Solution of Ordinary Differential Equations 01549 01550 Classes for non-adaptive integration are provided as descendents 01551 of \ref odestep and classes for adaptive integration are 01552 descendants of \ref adapt_step. To specify a set of functions 01553 to these classes, use a child of ode_funct for a generic 01554 vector type or a child of ode_vfunct when using arrays. 01555 01556 Solution of simple initial value problems is performed by \ref 01557 ode_iv_solve. This class contains a couple different methods, 01558 depending on whether the user needs only the final value or the 01559 solution on a fixed grid. 01560 01561 The solution of boundary-value problems is based on the abstract 01562 base class \ref ode_bv_solve. At the moment, a simple shooting method 01563 is the only implementation of this base class and is given 01564 in \ref ode_bv_shoot . An experimental multishooting class is 01565 given in \ref ode_bv_multishoot . 01566 01567 An experimental application of linear solvers to solve the 01568 finite-difference equations for a boundary value problem 01569 is given in \ref ode_it_solve . 01570 01571 \hline 01572 \section rng_section Random Number Generation 01573 01574 Random number generators are descendants of \ref rnga . While the 01575 base object \ref rnga is created to allow user-defined random 01576 number generators, the only random number generator presently 01577 included are from GSL. The GSL random number generator code is 01578 reimplemented in the class \ref gsl_rnga to avoid an additional 01579 performance penalty. This may not be a truly "object-oriented" 01580 interface in that it does not use virtual functions, but it avoids 01581 any possible performance penalty. Random number generators are 01582 implemented as templates in \ref sim_anneal and \ref mcarlo_inte. 01583 In these classes, the random number generator is a template type, 01584 rather than a member data pointer, in order to ensure fast 01585 execution. 01586 01587 \hline 01588 \section tintp_section Two-dimensional Interpolation 01589 01590 Successive use of \ref smart_interp is implemented in \ref 01591 twod_intp, which is useful for interpolating data presented 01592 on a two-dimensional grid (though the spacings between grid points 01593 need not be equal). Also, one can compute \contour lines from 01594 data represented on a grid using the \ref contour class. 01595 01596 If data is arranged without a grid, then \ref planar_intp can 01597 be used. At present, the only way to compute \contour lines on 01598 data which is not defined on a grid is to use \ref planar_intp to 01599 recast the data on a grid and then use \ref contour afterwards. 01600 01601 Higher-dimensional interpolation is possible with \ref tensor_grid. 01602 01603 \hline 01604 \section gslcheb_section Chebyshev Approximation 01605 01606 A class implementing the Chebyshev approximations based on GSL is 01607 given in \ref gsl_chebapp. This class has its own copy 01608 constructor, so that Chebyshev approximations can be copied and 01609 passed as arguments to functions. 01610 01611 \hline 01612 \section unitconv_section Unit Conversions 01613 01614 There is a class which performs conversion between units specified 01615 with strings in \ref convert_units. The \ref convert_units 01616 class also uses a system call to the GNU units command (if it's 01617 installed in the path) to obtain the proper conversion factors. 01618 01619 \hline 01620 \section other_section Other classes and functions 01621 01622 The \o2 library contains several classes which are still under 01623 development and are to be considered experimental. While it is 01624 expected that the testing code associated with these classes will 01625 succeed on most any system, the interface, structure, and basic 01626 approaches used by these classes may change in future versions of 01627 \o2. 01628 01629 \b Three-dimensional data tables - \ref table3d \n 01630 \b Two-dimensional Gaussian distribution - \ref gaussian_2d \n 01631 \b Series \b acceleration - \ref gsl_series \n 01632 \b Command-line interface - \ref cli \n 01633 \b Automatic bin sizing - \ref bin_size \n 01634 \b Fourier \b transforms - \ref gsl_fft \n 01635 \b Polylogarithms - \ref polylog \n 01636 01637 \hline 01638 \section lset_section Library settings 01639 01640 There are a couple library settings which are handled by 01641 a global object \ref lib_settings of type \ref lib_settings_class. 01642 01643 There are several data files that are used by various classes in 01644 the library. The installation procedure should ensure that these 01645 files are automatically found. However, if these data files are 01646 moved after installation, then a call to 01647 lib_settings_class::set_data_dir() can adjust the library to use 01648 the new directory. It is assumed that the directory structure 01649 within the data directory has not changed. 01650 01651 \hline 01652 \section io_section Object I/O 01653 01654 The I/O portion of the library is still experimental. 01655 01656 Collections of objects can be stored in a \ref collection class, 01657 and these collections can be written to or read from text or 01658 binary files. User-defined classes may be added to the collections 01659 and may be read and written to files as long as a descendant of 01660 \ref io_base is provided. 01661 01662 Every type has an associated I/O type which is a descendant of 01663 \ref io_base. In order to perform any sort of input/output on any 01664 type, an object of the corresponding I/O type must be instantiated 01665 by the user. This is not done automatically by the library. (Since 01666 it doesn't know which objects are going to be used ahead of time, 01667 the library would have to instantiate <em>all</em> of the I/O 01668 objects, which is needlessly slow.) This makes the I/O slightly 01669 less user-friendly, but much more efficient. For convenience, each 01670 subsection of the library has a class (named with an \c _ioc 01671 suffix) which will automatically allocate all I/O types for that 01672 subsection. 01673 01674 <b>Level 1 functions:</b> Functions that input/output data from 01675 library-defined objects and internal types from files and combine 01676 these objects in collections. These are primarily member functions 01677 of the class \ref collection. 01678 01679 <b>Level 2 functions:</b> Functions which are designed to allow 01680 the user to input or output data for user-generated objects. These 01681 are primarily member functions of classes \ref cinput and \ref 01682 coutput. 01683 01684 <b>Level 3 functions:</b> Functions which allow low-level 01685 modifications on how input and output is performed. Usage of 01686 level 3 functions is not immediately recommended for the casual 01687 user. 01688 01689 <b>Level 1 usage</b>: 01690 01691 For adding an object to a collection when you have a pointer 01692 to the I/O object for the associated type: 01693 \code 01694 int collection::add(std::string name, io_base *tio, void *vec, 01695 int sz=0, int sz2=0, bool overwrt=true, bool owner=false); 01696 \endcode 01697 For adding an object to a collection otherwise: 01698 \code 01699 int collection::add(std::string name, std::string stype, 01700 void *vec, int sz=0, int sz2=0, 01701 bool overwrt=true, bool owner=false); 01702 \endcode 01703 01704 To retrieve an object as a <pre>void *</pre> from a collection 01705 use one of: 01706 \code 01707 int get(std::string tname, void *&vec); 01708 int get(std::string tname, void *&vec, int &sz); 01709 int get(std::string tname, void *&vec, int &sz, int &sz2); 01710 int get(std::string tname, std::string &stype, void *&vec); 01711 int get(std::string tname, std::string &stype, void *&vec, int &sz); 01712 int get(std::string tname, std::string &stype, void *&vec, int &sz, 01713 int &sz2); 01714 \endcode 01715 When retrieving a scalar object without error- and type-checking you 01716 can use the shorthand version: 01717 \code 01718 void *get(std::string name); 01719 \endcode 01720 01721 To output one object to a file: 01722 \code 01723 int collection::out_one(out_file_format *outs, std::string stype, 01724 std::string name, void *vp, int sz=0, int sz2=0); 01725 \endcode 01726 01727 To input one object from a file with a given type and name: 01728 \code 01729 int collection::in_one_name(in_file_format *ins, std::string stype, 01730 std::string name, void *&vp, int &sz, int &sz2); 01731 \endcode 01732 To input the first object of a given type from a file: 01733 \code 01734 int collection::in_one(in_file_format *ins, std::string stype, 01735 std::string &name, void *&vp, int &sz, int &sz2); 01736 \endcode 01737 01738 <b>Level 2 usage (string-based)</b>: 01739 01740 If you don't have a pointer to the io_base child object corresponding 01741 to the type of subobject that you are manipulating, then you can use 01742 the following functions, which take the type name as a string. 01743 01744 To input a sub-object in an io_base template for which memory 01745 has already been allocated use one of: 01746 \include io_doc1.cpp 01747 01748 To automatically allocate memory and input a sub-object of a 01749 io_base template use one of: 01750 \include io_doc2.cpp 01751 01752 To output a subobject in an io_base template use: 01753 \code 01754 int collection::object_out(std::string type, out_file_format *outs, 01755 void *op, int sz=0, int sz2=0, std::string name=""); 01756 \endcode 01757 01758 <b>Level 2 usage (with io_base pointer)</b>: 01759 01760 To input a sub-object in an io_base template for which memory 01761 has already been allocated use one of: 01762 \include io_doc4.cpp 01763 01764 To automatically allocate memory and input a sub-object of a 01765 io_base template use one of: 01766 \include io_doc5.cpp 01767 01768 To output a subobject in an io_base template use: 01769 \include io_doc6.cpp 01770 01771 To automatically allocate/deallocate memory for an object, use: 01772 \code 01773 virtual int mem_alloc(object *&op); 01774 virtual int mem_alloc_arr(object *&op, int sz); 01775 virtual int mem_alloc_2darr(object **&op, int sz, int sz2); 01776 virtual int mem_free(object *op); 01777 virtual int mem_free_arr(object *op); 01778 virtual int mem_free_2darr(object **op, int sz); 01779 \endcode 01780 01781 \subsection iotlate_subsect Usage of io_tlate 01782 01783 The functions io_tlate::input() and io_tlate::output() need to be 01784 implemented for every class has information for I/O. For 01785 subobjects of the class, cinput::object_in() and 01786 cinput::object_out() can be called to input or output the 01787 information associated with the subobject. For input, 01788 cinput::object_in_name(), cinput::object_in_mem(), and 01789 cinput::object_in_mem_name() allow the freedom to input an object 01790 with a name or with memory allocation. The function 01791 coutput::object_out_name() allows one to output an object with a 01792 name. If the class contains a pointer to the subobject, then 01793 io_base::pointer_in() or io_base::pointer_out() can be used. 01794 01795 \hline 01796 \section source_section Example source code 01797 01798 \subsection exlist_subsect Example list 01799 01800 - \ref ex_fptr_sect shows how member functions and external 01801 parameters are supplied to \o2 numerical routines. In this case, a 01802 member function representing an equation with one unknown 01803 is solved using a one-dimesional solver. 01804 - \ref ex_mroot_sect demonstrates the multidimensional function 01805 solver and several different methods of specifying the function to 01806 be solved. 01807 - \ref ex_mmin_sect 01808 - \ref ex_mmin_fix_sect 01809 - \ref ex_deriv_sect 01810 - \ref ex_inte_sect 01811 - \ref ex_ode_sect 01812 - \ref ex_anneal_sect demonstrates multidimensional 01813 minimization by simulated annealing 01814 - \ref ex_minte_sect demonstrates several ways to compute a 01815 multidimensional integral including Monte Carlo and direct methods 01816 - \ref ex_contour_sect 01817 - \ref ex_twod_intp_sect 01818 - \ref ex_ublas_sect demonstrates the use of interpolation 01819 and solver classes with ublas vectors 01820 01821 \comment 01822 \c ex_diff.cpp computes the derivative of a tabulated function 01823 01824 \c ex_table.cpp demonstrates the use of the \ref table class 01825 01826 \c ex_file.cpp demonstrates the file I/O 01827 \endcomment 01828 01829 \subsection ex_fptr_sect Function and solver example 01830 01831 \dontinclude ex_fptr.cpp 01832 \skip Example: 01833 \until End of example 01834 01835 The image below shows how the solver progresses to the 01836 solution of the example function. 01837 \image html ex_fptr.png "ex_fptr.png" 01838 \image latex ex_fptr.eps "ex_fptr.eps" width=9cm 01839 01840 \subsection ex_mroot_sect Multidimensional solver example 01841 01842 \dontinclude ex_mroot.cpp 01843 \skip Example: 01844 \until End of example 01845 01846 \subsection ex_mmin_sect Multidimensional minimizer example 01847 01848 \dontinclude ex_mmin.cpp 01849 \skip Example: 01850 \until End of example 01851 01852 \subsection ex_mmin_fix_sect Minimizer fixing variables example 01853 01854 \dontinclude ex_mmin_fix.cpp 01855 \skip Example: 01856 \until End of example 01857 01858 \subsection ex_deriv_sect Numerical differentiation example 01859 01860 \dontinclude ex_deriv.cpp 01861 \skip Example: 01862 \until End of example 01863 01864 \subsection ex_inte_sect Numerical integration example 01865 01866 \dontinclude ex_inte.cpp 01867 \skip Example: 01868 \until End of example 01869 01870 \subsection ex_ode_sect Ordinary differential equations example 01871 01872 \dontinclude ex_ode.cpp 01873 \skip Example: 01874 \until End of example 01875 01876 \subsection ex_anneal_sect Simulated annealing example 01877 01878 \dontinclude ex_anneal.cpp 01879 \skip Example: 01880 \until End of example 01881 01882 \subsection ex_minte_sect Multidimensional integration example 01883 01884 \dontinclude ex_minte.cpp 01885 \skip Example: 01886 \until End of example 01887 01888 \subsection ex_contour_sect Contour lines example 01889 01890 \dontinclude ex_contour.cpp 01891 \skip Example: 01892 \until End of example 01893 01894 \subsection ex_twod_intp_sect Two-dimensional interpolation example 01895 01896 \dontinclude ex_twod_intp.cpp 01897 \skip Example: 01898 \until End of example 01899 01900 \subsection ex_ublas_sect ublas vector example 01901 01902 \dontinclude ex_ublas.cpp 01903 \skip Example: 01904 \until End of example 01905 01906 \hline 01907 \section design_section Design Considerations 01908 01909 The design goal is to create an object-oriented computing library 01910 with classes that perform common numerical tasks. The most 01911 important principle is that the library should add functionality 01912 to the user while at the same time retaining as much freedom for 01913 the user as possible and allowing for ease of use and extensibility. 01914 To that end, 01915 - The classes which utilize user-specified functions 01916 should be able to operate on member functions without requiring 01917 a particular inheritance structure, 01918 - The interfaces ought to be generic so that the user 01919 can create new classes which perform related numerical 01920 tasks through inheritance, 01921 - The classes should not use static variables or functions 01922 - Const-correctness and type-safety should be used wherever possible, and 01923 - The design should be somewhat compatible with GSL. 01924 Also, the library provides higher-level routines 01925 for situations which do not require lower-level access. 01926 01927 <b>Header file dependencies</b> 01928 01929 For reference, it's useful to know how the top-level header files 01930 depend on each other, since it can be difficult to trace 01931 everything down. In the \c base directory, the following are some 01932 of the most "top-level" header files and their associated 01933 dependencies within \o2 (there are other dependencies on GSL and 01934 the C standard library not listed here). 01935 \code 01936 err_hnd.h : (none) 01937 lib_settings.h : (none) 01938 array.h: err_hnd.h 01939 vector.h: err_hnd.h 01940 sring_conv.h : lib_settings.h 01941 misc.h : err_hnd.h lib_settings.h 01942 test_mgr.h : string_conv.h 01943 uvector_tlate.h: err_hnd.h string_conv.h array.h vector.h 01944 ovector_tlate.h: err_hnd.h string_conv.h 01945 uvector_tlate.h array.h vector.h 01946 \endcode 01947 01948 <B>The use of templates</b> 01949 01950 Templates are used extensively, and this makes for longer 01951 compilation times so any code that can be removed conveniently 01952 from the header files should be put into source code files 01953 instead. 01954 01955 \subsection errdesign_subsect Error handling 01956 01957 <b>Thread safety</b> 01958 01959 Two approaches to thread-safe error handling which are worth 01960 comparing: the first is GSL which uses return codes and global 01961 function for an error handler, and the second is the Math/Special 01962 Functions section of Boost, which uses a separate policy type for 01963 each function. One issue is thread safety: the GSL approach is 01964 thread safe only in the sense that one can in principle use the 01965 return codes in different threads to track errors. What one cannot 01966 do in GSL is use different user-defined error handlers for 01967 different threads. The Special Functions library allows one to 01968 choose a different Policy for every special function call, and 01969 thus allows quite a bit more flexibility in designing 01970 multi-threaded error handling. 01971 01972 \subsection vecdesign_subsect Vector design 01973 01974 \o2 vector and matrix types are a hybrid approach: creating objects 01975 compatibile with GSL, while providing syntactic simplicity and 01976 object-oriented features common to C++ vector classes. In terms 01977 of their object-oriented nature, they are not as elegant as 01978 the ublas vector types from ublas, but for many applications they 01979 are also faster (and they are always at least as fast). 01980 01981 However, ensuring const-correctness makes the design a bit thorny, 01982 and this is still in progress. 01983 01984 \subsection typecase_subsect Type-casting in vector and matrix design 01985 01986 \o2 uses a GSL-like approach where viewing const double * 01987 arrays is performed by explicitly casting aways const'ness 01988 internally and then preventing the user from changing the data. 01989 01990 In GSL, the preprocessor output for \c vector/view_source.c is: 01991 \include gsl_vector_doc.cpp 01992 Note the explicit cast from const double * to double *. This 01993 is similar to what is done in \c src/base/ovector_tlate.h. 01994 01995 \subsection define_subsect Define constants and macros 01996 01997 There are a couple define constants and macros that \o2 01998 understands, they are all in upper case and begin with the prefix 01999 <tt>O2SCL_</tt>. 02000 02001 Range-checking for arrays and matrices is turned on by default, 02002 but can be turned off by defining <tt>O2SCL_NO_RANGE_CHECK</tt> 02003 during the initial configuration of the library. To see how the 02004 library was configured at runtime, use the \ref lib_settings 02005 class. 02006 02007 There are several macros for error handling defined in \ref 02008 err_hnd.h, and several for vector/matrix arithmetic in \ref 02009 vec_arith.h . 02010 02011 There is a define constant O2SCL_NO_SYSTEM_FUNC which permanently 02012 disables the shell command <tt>'!'</tt> in \ref cli (when the 02013 constant is defined, the shell command doesn't work even if 02014 \ref cli::shell_cmd_allowed is <tt>true</tt>). 02015 02016 The constant O2SCL_DATA_DIR is defined internally to provide 02017 the directory which contains the \o2 data files. After installation, 02018 this can be accessed in \ref lib_settings. 02019 02020 All of the header files have their own define constant of 02021 the form <tt>O2SCL_HEADER_FILE_NAME</tt> which ensures that 02022 the header file is only included once. 02023 02024 Finally, I sometimes comment out sections of code with 02025 \code 02026 #ifdef O2SCL_NEVER_DEFINED 02027 ... 02028 #endif 02029 \endcode 02030 This constant should not be defined by the user as it will cause 02031 compilation to fail. 02032 02033 \comment 02034 These are makefile constants not source code define constants 02035 02036 The two define constants O2SCL_PARTLIB and O2SCL_EOSLIB are used 02037 internally to control which sublibraries are compiled together 02038 with the main library (see \ref install_section ). The end-user 02039 shouldn't have to worry about these. 02040 \endcomment 02041 02042 \subsection global_subsect Global objects 02043 02044 There are three global objects that are created in 02045 libo2scl: 02046 - \ref def_err_hnd is the default error handler 02047 - \ref err_hnd is the pointer to the error handler (points to 02048 def_err_hnd by default) 02049 - \ref lib_settings to control a few library settings 02050 02051 All other global objects are to be avoided. 02052 02053 \subsection thread_subsect Thread safety 02054 02055 Most of the classes are thread-safe, meaning that two instances of 02056 the same class will not clash if their methods are called 02057 concurrently since static variables are only used for compile-time 02058 constants. However, two threads cannot, in general, safely access 02059 the same instance of a class. In this respect, \o2 is no 02060 different from GSL. 02061 02062 \subsection docdesign_subsect Documentation design 02063 02064 The commands \\comment and \\endcomment delineate comments about 02065 the documentation that are present in the header files but don't 02066 ever show up in the HTML or LaTeX documentation. 02067 02068 \subsection crightfoo_subsect Copyright notices 02069 02070 For files where it is appropriate to do so, I have followed the 02071 prescription suggested in 02072 http://lists.gnu.org/archive/html/help-gsl/2008-11/msg00017.html 02073 retaining the GSL copyright notices and putting the \o2 notices at 02074 the top. CERNLIB has no such standard, but their licensing information 02075 is outlined at 02076 http://cernlib.web.cern.ch/cernlib/conditions.html . 02077 02078 \subsection futurework_subsect Design plans 02079 02080 <b>Exception classes:</b> \n Eventually I'd like to create a sensible 02081 hierarchy of exception classes to be thrown by the handler 02082 if the user would prefer (this is already in progress). 02083 02084 <b>Boost and linear algebra:</b> \n I would like to ensure this 02085 class is compatible with boost, and start integrating things 02086 accordingly. IMHO object-oriented linear algebra is in a rather 02087 sad state at the moment. uBlas and MTL are both promising, 02088 however, and I'd like to start implementing some sort of 02089 compatibility with uBlas vectors and matrices soon. The uBlas 02090 documentation is pretty sparse, but that's the pot calling the 02091 kettle a cheap piece of metal. 02092 02093 <b>Other Improvements:</b> \n I'm particularly interested in 02094 improving the ODE and fitting classes, as well as updating the 02095 BFGS2 minimizer. Of course, more examples and better documentation 02096 are also a must. 02097 02098 <b>Algorithms to include</b> 02099 - Method of lines for PDEs 02100 - Some of the MESA interpolation routines. 02101 - C++ translation of MINUIT (done already by ROOT, but quite difficult). 02102 - Creating closed regions from contour lines (I have no idea how to 02103 do this at the moment, though I'm sure someone has solved this 02104 problem already somewhere.) 02105 02106 <b>Complex numbers</b> \n I'm not sure where to go with complex 02107 numbers. My guess is that <tt>std::complex</tt> is not 02108 significantly slower (or is faster) than <tt>gsl_complex</tt>, but 02109 it would be good to check this. Then there's the C99 standard, 02110 which is altogether different. Unfortunately the interfaces may be 02111 sufficiently different that it's impossible to make templated 02112 classes which operate on generic complex number types. 02113 02114 <b>I/O</b> \n The I/O classes are (admittedly) not structured very 02115 well, and there are a lot of things which could be done there. 02116 There are a lot of alternative solutions out there, but most of 02117 them work on binary file formats (which I find difficult to use). 02118 - On a shorter time scale I'd like to replace the inner workings 02119 of the \ref collection class with a mechanism using 02120 <tt>boost::any</tt>, which will avoid the silly <tt>void *</tt>s 02121 all over the place. This is already in progress. 02122 - On a longer time scale, I'd like to replace the file format I/O 02123 classes with something using Boost pipes. 02124 02125 \hline 02126 \section license_section License Information 02127 02128 \o2 (as well as CERNLIB and the Gnu Scientific Library (GSL)) is 02129 licensed under version 3 of the GPL as provided in the files \c 02130 COPYING and in \c doc/o2scl/extras/gpl_license.txt. After 02131 installation, it is included in the documentation in \c 02132 PREFIX/doc/extras/gpl_license.txt where the default \c PREFIX is 02133 \c /usr/local. 02134 02135 \verbinclude gpl_license.txt 02136 02137 This documentation is provided under the GNU Free Documentation 02138 License, as given below and provided in \c 02139 doc/o2scl/extras/fdl_license.txt. After installation, it is included 02140 in the documentation in \c PREFIX/doc/extras/fdl_license.txt where 02141 the default \c PREFIX is \c /usr/local. 02142 02143 \verbinclude fdl_license.txt 02144 02145 \hline 02146 \section ack_section Acknowledgements 02147 02148 I would like to thank the creators of GSL and Doxygen for their 02149 excellent work! Thanks also to Julien Garaud for contributing the 02150 ODE multishooting class and for the <tt>ex_hydrogen</tt> example. 02151 02152 \hline 02153 \section ref_section Bibliography 02154 02155 Some of the references which contain links should direct you to 02156 the work referred to directly through dx.doi.org. 02157 02158 \anchor Bader83 Bader83: 02159 G. Bader and P. Deuflhard, Numer. Math. \b 41 (1983) 373. 02160 02161 \anchor Bus75 Bus75: 02162 J.C.P. Bus and T.J. Dekker, ACM 02163 Trans. Math. Software \b 1 (1975) 330. 02164 02165 \anchor Cash90 Cash90: 02166 Cash, J.R., Karp, A.H., ACM Transactions of Mathematical 02167 Software, vol. 16 (1990) 201-222. 02168 02169 \anchor Fletcher87 Fletcher87: 02170 R. Fletcher, Practical methods of optimization (John Wiley & Sons, 02171 Chichester 1987) p. 39. 02172 02173 \anchor Hairer00 Hairer00: 02174 Hairer, E., Norsett S.P., Wanner, G. Solving ordinary 02175 differential equations I, Nonstiff Problems, 2nd revised edition, 02176 Springer, 2000. 02177 02178 \anchor Krabs83 Krabs83: 02179 W. Krabs, Einfuhrung in die lieare und nictlineare Optimierung 02180 fur Ingenieure (BSB B.G. Teubner, Leipzig 1983) p. 84. 02181 02182 \anchor Lepage78 Lepage78: 02183 G. P. Lepage, originally described in J. Comp. Phys. 27 (1978) 02184 192. 02185 02186 \anchor Lewin83 Lewin83: 02187 L. Lewin, Polylogarithms and Associated Functions (North-Holland, 02188 New York, 1983). 02189 02190 \anchor Longman58 Longman58: 02191 I.M. Longman, MTAC (later renamed Math. Comp.) \b 12 (1958) 205. 02192 02193 \anchor More79 More79: 02194 J.J. More' and M.Y. Cosnard, ACM Trans. Math. Software, 02195 \b 5 (1979) 64-85. 02196 02197 \anchor More80 More80: 02198 J.J. More' and M.Y. Cosnard, Algoright 554 BRENTM, 02199 Collected Algorithms from CACM (1980). 02200 02201 \anchor Nelder65 Nelder65: 02202 Nelder, J.A., Mead, R., Computer Journal 7 (1965) pp. 308-313. 02203 02204 \anchor Press90 Press90: 02205 W.H. Press, G.R. Farrar, "Recursive Stratified Sampling for 02206 Multidimensional Monte Carlo Integration", Computers in Physics, 02207 v4 (1990), pp. 190-195. 02208 02209 \anchor Prince81 Prince81: 02210 P.J. Prince and J.R. Dormand J. Comp. Appl. Math., 7 (1981) 67. 02211 02212 \anchor Rutishauser63 Rutishauser63: 02213 H. Rutishauser, Ausdehnung des Rombergschen Prinzips 02214 (Extension of Romberg's Principle), Numer. Math. \b 5 (1963) 48-54. 02215 02216 */ 02217 /* 02218 --------- 02219 This section has been removed from the documentation since the 02220 vector classes have been updated. 02221 --------- 02222 02223 \page cvn_page Notes on const vectors 02224 02225 The code 02226 02227 \code 02228 const ovector x; 02229 //ovector_const_base &cb=x; 02230 \endcode 02231 02232 doesn't complile, which is a bit weird (you have to use a 02233 const ovector_const_base reference instead). 02234 02235 Also, ovector_base has a function like 02236 02237 \code 02238 double &operator[](size_t i) 02239 \endcode 02240 02241 which in principle could be actually const, i.e. 02242 02243 \code 02244 double &operator[](size_t i) const 02245 \endcode 02246 02247 but isn't. Also annoying is that "const ovector_base &x" is not a 02248 perfectly generic base, since it's not a base for 02249 "ovector_const_base &y" or "const ovector_const_base &y2" (last one 02250 I'm not sure about). I had thought about making ovector_const_base a 02251 child of ovector_base instead, but that means that the interpolation 02252 routines which have ovector_const_base as a default template 02253 parameter will have to be changed. (Is this a problem?) Even worse, 02254 ovector_const_base classes could be upcasted easily to ovector_base 02255 removing const correctness. 02256 02257 Finally, the meaning of "const ovector_view" vs. "ovector_view" is 02258 kind of confusing, though maybe we just have to explain to the 02259 user that "const" means const where-ever it appears. 02260 02261 Happily, this new branch removes the need for "ovector_view_assign", 02262 in the trunk which was kind of frustrating. 02263 02264 Probably the best new solution is to rework the hierarchy altogether 02265 and admit that ovector and ovector_view aren't really related 02266 objects. There is no such thing as a generic base for both ovector 02267 and ovector_view. This of course might require a redesign of the 02268 solver classes, for example, as they treat these two classes as 02269 necessarily related (alloc_vec_t is supposed to be related to 02270 vec_t). Maybe not though, I need to think about this more. 02271 02272 */ 02273 /** 02274 \page dl_page Download O2scl 02275 02276 The current version is 0.904. The source distribution can 02277 be obtained from \n 02278 - \c http://sourceforge.net/project/showfiles.php?group_id=206918 02279 02280 You may also download \o2 from version from the Subversion 02281 repository. To obtain the bleeding-edge developer version, use 02282 something like 02283 \verbatim 02284 svn co https://o2scl.svn.sourceforge.net/svnroot/o2scl/trunk o2scl 02285 \endverbatim 02286 The checkout process is a bit more time consuming than directly 02287 downloading the source distribution. 02288 02289 Version 0.904 corresponds with version 40 in the svn repository. 02290 02291 Version 0.903 does not exist (this number was skipped to help 02292 coordinate numbering with \o2x). 02293 02294 Version 0.902 corresponds with version 37 in the svn respository. 02295 02296 Version 0.901 corresponds with version 31 in the svn respository. 02297 02298 Version 0.9 corresponds with version 26 in the svn respository. 02299 02300 Version 0.806 was a quick release to fix some issues with 02301 compilations in Mac OS X and does not correspond exactly 02302 with a version in the repository. 02303 02304 Version 0.805 corresponds with version 16 in the svn respository. 02305 02306 */ 02307 /* 02308 \htmlonly 02309 <table border=0> 02310 <tr><td>Release version number</td><td>SVN repository number</td></tr> 02311 <tr><td>0.901</td><td>31</td></tr> 02312 <tr><td>0.9</td><td>26</td></tr> 02313 <tr><td>0.806</td><td>none</td></tr> 02314 <tr><td>0.805</td><td>16</td></tr> 02315 </table> 02316 \endhtmlonly 02317 02318 */ 02319 /** 02320 \brief An empty class to add some items to the todo and bug lists 02321 02322 \todo 02323 - The o2scl-test and o2scl-examples targets require grep, awk, 02324 tail, cat, and wc. It would be good to reduce this list 02325 to ensure better compatibility. 02326 - More examples and benchmarks 02327 - There are a couple classes which Doxygen doesn't yet parse 02328 properly for the class hierarchy: gsl_root_stef, 02329 and ool_mmin_gencan. Also should double check 02330 smart_interp, etc. 02331 - Make sure abs(-double) isn't allowed by the O2scl and 02332 GSL headers with the correct flags 02333 02334 \future 02335 - Fix the PNG images so that they're smaller and repair the 02336 transparency issue (probably can be done just using different 02337 arguments to 'convert' in the pngfix target) 02338 - Make sure we have a uvector_cx_alloc, 02339 ovector_cx_const_reverse, ovector_cx_const_subvector_reverse, 02340 uvector_reverse, uvector_const_reverse, uvector_subvector_reverse, 02341 uvector_const_subvector_reverse, omatrix_cx_diag, blah_const_diag, 02342 umatrix_diag, and umatrix_cx_diag 02343 - ovector_cx_view::operator=(uvector_cx_view &) is missing 02344 - ovector_cx::operator=(uvector_cx_view &) is missing 02345 - uvector_c_view::operator+=(complex) is missing 02346 - uvector_c_view::operator-=(complex) is missing 02347 - uvector_c_view::operator*=(complex) is missing 02348 02349 \todo At present, the testing code assumes that shared libraries are 02350 installed. Can this be improved? (12/3/08 - I'm not sure what the 02351 status is on this...this should be checked.) 02352 02353 \todo Make sure default template parameters are documented 02354 in each class, and make sure default template parameters exist 02355 where they should. 02356 02357 \future Consider breaking documentation up into sections? 02358 02359 \bug 02360 - BLAS libraries not named \c libblas or \c libgslblas are not 02361 properly detected in ./configure and will have to be added 02362 manually. 02363 - The -lm flag may not be added properly by ./configure 02364 (1/4/09 - I'm not sure I remember why this is a problem, 02365 but it probably has to do with the detection of libraries 02366 which is done in configure.ac). 02367 02368 */ 02369 class other_todos_and_bugs { 02370 } 02371
Documentation generated with Doxygen and provided under the GNU Free Documentation License. See License Information for details.
Project hosting provided by
,
O2scl Sourceforge Project Page