EVOLUTION-MANAGER
Edit File: LongVectors.html
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><title>R: Long Vectors</title> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <link rel="stylesheet" type="text/css" href="R.css" /> </head><body> <table width="100%" summary="page for LongVectors {base}"><tr><td>LongVectors {base}</td><td style="text-align: right;">R Documentation</td></tr></table> <h2>Long Vectors</h2> <h3>Description</h3> <p>Vectors of <i>2^31</i> or more elements were added in <span style="font-family: Courier New, Courier; color: #666666;"><b>R</b></span> 3.0.0. </p> <h3>Details</h3> <p>Prior to <span style="font-family: Courier New, Courier; color: #666666;"><b>R</b></span> 3.0.0, all vectors in <span style="font-family: Courier New, Courier; color: #666666;"><b>R</b></span> were restricted to at most <i>2^31 - 1</i> elements and could be indexed by integer vectors. </p> <p>Currently all <a href="vector.html">atomic</a> (raw, logical, integer, numeric, complex, character) vectors, <a href="list.html">list</a>s and <a href="expression.html">expression</a>s can be much longer on 64-bit platforms: such vectors are referred to as ‘long vectors’ and have a slightly different internal structure. In theory they can contain up to <i>2^52</i> elements, but address space limits of current CPUs and OSes will be much smaller. Such objects will have a <a href="length.html">length</a> that is expressed as a double, and can be indexed by double vectors. </p> <p>Arrays (including matrices) can be based on long vectors provided each of their dimensions is at most <i>2^31 - 1</i>: thus there are no 1-dimensional long arrays. </p> <p><span style="font-family: Courier New, Courier; color: #666666;"><b>R</b></span> code typically only needs minor changes to work with long vectors, maybe only checking that <code>as.integer</code> is not used unnecessarily for e.g. lengths. However, compiled code typically needs quite extensive changes. Note that the <code><a href="Foreign.html">.C</a></code> and <code><a href="Foreign.html">.Fortran</a></code> interfaces do not accept long vectors, so <code><a href="CallExternal.html">.Call</a></code> (or similar) has to be used. </p> <p>Because of the storage requirements (a minimum of 64 bytes per character string), character vectors are only going to be usable if they have a small number of distinct elements, and even then factors will be more efficient (4 bytes per element rather than 8). So it is expected that most of the usage of long vectors will be integer vectors (including factors) and numeric vectors. </p> <h3>Matrix algebra</h3> <p>It is now possible to use <i>m x n</i> matrices with more than 2 billion elements. Whether matrix algebra (including <code><a href="matmult.html">%*%</a></code>, <code><a href="crossprod.html">crossprod</a></code>, <code><a href="svd.html">svd</a></code>, <code><a href="qr.html">qr</a></code>, <code><a href="solve.html">solve</a></code> and <code><a href="eigen.html">eigen</a></code>) will actually work is somewhat implementation dependent, including the Fortran compiler used and if an external BLAS or LAPACK is used. </p> <p>An efficient parallel BLAS implementation will often be important to obtain usable performance. For example on one particular platform <code>chol</code> on a 47,000 square matrix took about 5 hours with the internal BLAS, 21 minutes using an optimized BLAS on one core, and 2 minutes using an optimized BLAS on 16 cores. </p> <hr /><div style="text-align: center;">[Package <em>base</em> version 3.6.0 <a href="00Index.html">Index</a>]</div> </body></html>