StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PODT[!(x == .)] and DT[x != .] treat NA in x inconsistently
primarykey
Id
16239153
data
AcceptedAnswerId
19387479
AnswerCount
4
ClosedDate
CommentCount
10
CommunityOwnedDate
CreationDate
2013-04-26T14:41:03.053
FavoriteCount
3
LastActivityDate
2013-10-15T17:35:45.633
LastEditDate
2017-05-23T12:02:26.530
LastEditorUserId
-1
OwnerUserId
559784
ParentId
0
PostTypeId
1
Score
20
ViewCount
590
LastEditorDisplayName
text
Body
This is something that I thought I should ask following <a href="https://stackoverflow.com/q/16221742/559784">this question</a>. I'd like to confirm if this is a bug/inconsistency before filing it as a such in the R-forge tracker. Consider this <code>data.table</code>: <pre><code>require(data.table) DT <- data.table(x=c(1,0,NA), y=1:3) </code></pre> Now, to access all rows of the DT that are not 0, we could do it in these ways: <pre><code>DT[x != 0] # x y # 1: 1 1 DT[!(x == 0)] # x y # 1: 1 1 # 2: NA 3 </code></pre> Accessing <code>DT[x != 0]</code> and <code>DT[!(x==0)]</code> gives different results when the underlying logical operation is equivalent. Note: Converting this into a data.frame and running these operations will give results that are identical with each other for both logically equivalent operations, but that result is different from both these data.table results. For an explanation of why, look at <code>?`[`</code> under the section <code>NAs in indexing</code>. Edit: Since some of you've stressed for equality with <code>data.frame</code>, here's the snippet of the output from the same operations on data.frame: <pre><code>DF <- as.data.frame(DT) # check ?`[` under the section `NAs in indexing` as to why this happens DF[DF$x != 0, ] # x y # 1 1 1 # NA NA NA DF[!(DF$x == 0), ] # x y # 1 1 1 # NA NA NA </code></pre> I think this is an inconsistency and both should provide the same result. But, which result? The documentation for <code>[.data.table</code> says: <blockquote> i ---> Integer, logical or character vector, expression of column names, list or data.table. integer and logical vectors work the same way they do in [.data.frame. Other than NAs in logical i are treated as FALSE and a single NA logical is not recycled to match the number of rows, as it is in [.data.frame. </blockquote> It's clear why the results are different from what one would get from doing the same operation on a <code>data.frame</code>. But still, within data.table, if this is the case, then both of them should return: <pre><code># x y # 1: 1 1 </code></pre> I went through <code>[.data.table</code> source code and now understand as to why this is happening. See <a href="https://stackoverflow.com/a/16222108/559784">this post</a> for a detailed explanation of why this is happening. Briefly, <code>x != 0</code> evaluates to "logical" and <code>NA</code> gets replaced to FALSE. However, <code>!(x==0)</code>, first <code>(x == 0)</code> gets evaluated to logical and <code>NA</code> gets replaced to FALSE. Then the negation happens, which results in <code>NA</code> basically becoming <code>TRUE</code>. So, my first (or rather main) question is, is this a bug/inconsistency? If so, I'll file it as one in data.table R-forge tracker. If not, I'd like to know the reason for this difference and I would like to suggest a correction to the documentation explaining this difference (to the already amazing documentation!). Edit: Following up with comments, the second question is, should <code>data.table</code>'s handling for subsetting by indexing with columns containing <code>NA</code> resemble that of <code>data.frame</code>?? (But I agree, following @Roland's comment that this may be very well lead to opinions and I'm perfectly fine with not answering this question at all).
Tags
<r><dataframe><data.table>
Title
DT[!(x == .)] and DT[x != .] treat NA in x inconsistently
singulars
PostAcceptedAnswerId
1. PO
 singulars
 PostTypePostTypeId
 PTAnswer
PostParentId
1. This table or related slice is empty.
PostTypePostTypeId
1. PTQuestion
UserLastEditorUserId
1. USCommunity
UserOwnerUserId
1. USArun
plurals
PostLinksPostIdRelatedPostId
1. PL
 singulars
 LinkTypeLinkTypeId
 LTLinked
2. PL
 singulars
 LinkTypeLinkTypeId
 LTLinked
PostLinksRelatedPostIdPostId
1. PL
 singulars
 LinkTypeLinkTypeId
 LTLinked
2. PL
 singulars
 LinkTypeLinkTypeId
 LTLinked
3. PL
 singulars
 LinkTypeLinkTypeId
 LTDuplicate
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. PO
 singulars
 PostTypePostTypeId
 PTAnswer
2. PO
 singulars
 PostTypePostTypeId
 PTAnswer
3. PO
 singulars
 PostTypePostTypeId
 PTAnswer
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PODT[!(x == .)] and DT[x != .] treat NA in x inconsistently
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PODT[!(x == .)] and DT[x != .] treat NA in x inconsistently
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PODT[!(x == .)] and DT[x != .] treat NA in x inconsistently
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.