<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><p>Hm, good point.  Is data.table consistent with SQL already, for both == and !=, and so no change needed?  </p></span></blockquote><div>Yes, I believe it's already consistent with SQL. However, the current interpretation of NA (documentation) being treated as FALSE is not needed / untrue, imho (Please see below).</div><div> </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><p>And it was correct for Frank to be mistaken.  </p></span></blockquote><div>Yes, it seems like he was mistaken.</div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><p>Maybe just some more documentation and examples needed then.</p></span></blockquote><div>It'd be much more appropriate if the documentation reflects the role of subsetting in data.table mimicking "subset" function (in order to be in line with SQL) by dropping NA evaluated logicals. From a couple of posts before, where I pasted the code where NAs are replaced to FALSE were not necessary as `irows <- which(i)` makes clear that `which` is being used to get indices and then subset, this fits perfectly well with the interpretation of NA in data.table. </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><p>Are you happy that DT[!(x==.)] and DT[x!=.] do treat NA inconsistently? :</p>
<p><a href="http://stackoverflow.com/questions/16239153/dtx-and-dtx-treat-na-in-x-inconsistently">http://stackoverflow.com/questions/16239153/dtx-and-dtx-treat-na-in-x-inconsistently</a></p></span></blockquote><div> Ha, I like the idea behind the use of () in evaluating expressions. It's another nice layer towards simplicity in data.table. But I still think there should not be an inconsistency in equivalent logical operations to provide different results. If !(x== .) and x != . are indeed different, then I'd suppose replacing `!` with a more appropriate name as it's much easier to get confused otherwise. </div><div><br></div><div>In essence, either !(x == .) must evaluate to (x != .) if the underlying meaning of these are the same, or the `!` in `!(x==.)` must be replaced to something that's more appropriate for what it's supposed to be. Personally, I prefer the former. It would greatly tighten the structure and consistency.</div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span>
<p>"na.rm = TRUE/FALSE" sounds good to me.  I'd only considered nomatch before in the context of joins, not logical subsets.</p></span></blockquote><div>Yes, I find this option would give more control in evaluating expressions with ease in `i`, by providing both "subset" (default) and the typical data.frame subsetting (na.rm = FALSE).</div><div><br></div><div>Best regards,</div><div> </div><div><div>Arun</div><div><br></div>
                </div>