title: Replacing NAs in R with nearest value
body: <p>I'm looking for something similar to <code>na.locf()</code> in the <code>zoo</code> package, but instead of always using the <em>previous</em> non-<code>NA</code> value I'd like to use the <em>nearest</em> non-<code>NA</code> value. Some example data:</p>
  
  <pre><code>dat &lt;- c(1, 3, NA, NA, 5, 7)
  </code></pre>
  
  <p>Replacing <code>NA</code> with <code>na.locf</code> (3 is carried forward):</p>
  
  <pre><code>library(zoo)
  na.locf(dat)
  # 1 3 3 3 5 7
  </code></pre>
  
  <p>and <code>na.locf</code> with <code>fromLast</code> set to <code>TRUE</code> (5 is carried backwards):</p>
  
  <pre><code>na.locf(dat, fromLast = TRUE)
  # 1 3 5 5 5 7
  </code></pre>
  
  <p>But I wish the <em>nearest</em> non-<code>NA</code> value to be used. In my example this means that the 3 should be carried forward to the first <code>NA</code>, and the 5 should be carried backwards to the second <code>NA</code>:</p>
  
  <pre><code>1 3 3 5 5 7
  </code></pre>
  
  <p>I have a solution coded up, but wanted to make sure that I wasn't reinventing the wheel. Is there something already floating around?</p>
  
  <p>FYI, my current code is as follows. Perhaps if nothing else, someone can suggest how to make it more efficient. I feel like I'm missing an obvious way to improve this:</p>
  
  <pre><code>  na.pos &lt;- which(is.na(dat))
    if (length(na.pos) == length(dat)) {
      return(dat)
    }
    non.na.pos &lt;- setdiff(seq_along(dat), na.pos)
    nearest.non.na.pos &lt;- sapply(na.pos, function(x) {
      return(which.min(abs(non.na.pos - x)))
    })
    dat[na.pos] &lt;- dat[non.na.pos[nearest.non.na.pos]]
  </code></pre>
  
  <p>To answer smci's questions below:</p>
  
  <ol>
  <li>No, any entry can be NA</li>
  <li>If all are NA, leave them as is</li>
  <li>No. My current solution defaults to the lefthand nearest value, but it doesn't matter</li>
  <li>These rows are a few hundred thousand elements typically, so in theory the upper bound would be a few hundred thousand. In reality it'd be no more than a few here &amp; there, typically a single one.</li>
  </ol>
  
  <p><strong>Update</strong> So it turns out that we're going in a different direction altogether but this was still an interesting discussion. Thanks all!</p>