<div>
hmm, I see what you mean. The `i` in `all.i = TRUE/FALSE` (in addition to having T/F instead of 0/NA) kind of delineates the behaviour of X[Y] against "merge" sufficiently that users don't fall into the "unexpected output" scenario.
</div><div><br></div>
<div><div>I vote for this change, if there's one :).</div><div>Arun</div><div><br></div></div>
<p style="color: #A0A0A8;">On Saturday, May 4, 2013 at 1:40 PM, Gabor Grothendieck wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div><div>I am not sure but I think that could be handled as a separate issue if</div><div>it becomes important. By using all.i= it makes it sufficiently</div><div>different from all.y= that users won't expect the same default and</div><div>further they will not necessarily expect that there be an all argument</div><div>for the left participant in the merge.</div><div><br></div><div>On Sat, May 4, 2013 at 7:35 AM, Arunkumar Srinivasan</div><div><<a href="mailto:aragorn168b@gmail.com">aragorn168b@gmail.com</a>> wrote:</div><blockquote type="cite"><div><div>Gabor,</div><div>Both points I agree with. It brings enough clarity and consistency to the</div><div>syntax.</div><div>Does this mean that you don't mind X[Y] not having all functionalities of</div><div>`merge`? Because this takes care of the confusion of `nomatch` but still</div><div>does not do all merges, iiuc.</div><div><br></div><div>Arun</div><div><br></div><div>On Saturday, May 4, 2013 at 1:26 PM, Gabor Grothendieck wrote:</div><div><br></div><div>The proposal at this point would be:</div><div><br></div><div>1. nomatch= would be replaced by all.i= such that</div><div>X[Y,,nomatch=NA] is the same as X[Y,,all.i=TRUE]</div><div>X[Y,,nomatch=0] is the same as X[Y,,all.i=FALSE]</div><div>nomatch= would be deprecated and ultimately removed.</div><div><br></div><div>Note that #1 is simple to implement as it only involves changing names</div><div>and values of arguments and does not really change any behavior;</div><div>however, its easier to think about because X[Y,,all.i=Z] now has the</div><div>same behavior as merge(X, Y, all.y=Z) and so can be quickly understood</div><div>by anyone who knows merge in R. In contrast nomatch= did not even</div><div>have the same meaning as in match() since match matches the first</div><div>occurrence whereas with mult="all", the default, matching in</div><div>data.table matches all occurrences. Note that the default of merge's</div><div>all.y= is all.y=FALSE but the default of all.i= is all.i=TRUE in order</div><div>that the default behave as indices do. Also note that this solves the</div><div>problem that nomatch= can only be 0 or NA since a logical can only</div><div>have two non-NA values anyways.</div><div><br></div><div>2. If Y were a numeric index vector then all.i= will have the same</div><div>effect as if Y were a data.table with Y as its column and is merged</div><div>with the row numbers of X. e.g. X[1:4,,all.i=FALSE] would be the</div><div>same as X[1:3] if X only had 3 rows since 4 does not match a row</div><div>number of X and is dropped because all.i=FALSE. If Y were a numeric</div><div>vector with negative values it would be converted to one with positive</div><div>values in such a way as to have the established meaning and then the</div><div>same strategy is applied. If Y were logical then its recycled giving</div><div>YY and the same strategy is applied to which(YY). This description is</div><div>intended to be conceptual and the actual internal mechanism could be</div><div>different.</div><div><br></div><div>Thus #2 allows one to think of **all** i indexing as merging rather</div><div>than as multiple separate concepts (which I believe is consistent with</div><div>the original intention of data.table).</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div>On Fri, May 3, 2013 at 8:02 PM, Eduard Antonyan</div><div><<a href="mailto:eduard.antonyan@gmail.com">eduard.antonyan@gmail.com</a>> wrote:</div><div><br></div><div>I think I like this proposal - maybe you should write up a few examples of</div><div>what current behavior is, vs the proposed behavior.</div><div><br></div><div><br></div><div>On Fri, May 3, 2013 at 6:54 PM, Gabor Grothendieck <<a href="mailto:ggrothendieck@gmail.com">ggrothendieck@gmail.com</a>></div><div>wrote:</div><div><br></div><div><br></div><div>data.table is supposed to generalize indexing and although not</div><div>explicitly stated the generalization seems to be that indexing is</div><div>merging with the row numbers so there is indeed merging going on and</div><div>that merging should respect nomatch= for consistency.</div><div><br></div><div>On Fri, May 3, 2013 at 6:54 PM, Eduard Antonyan</div><div><<a href="mailto:eduard.antonyan@gmail.com">eduard.antonyan@gmail.com</a>> wrote:</div><div><br></div><div>There is no join'ing happening here, thus nomatch=0 has no effect.</div><div><br></div><div><br></div><div>On Fri, May 3, 2013 at 5:52 PM, Gabor Grothendieck</div><div><<a href="mailto:ggrothendieck@gmail.com">ggrothendieck@gmail.com</a>></div><div>wrote:</div><div><br></div><div><br></div><div>The definition of DT was left out by mistake. It should be:</div><div><br></div><div>DT <- data.table(a=letters[1:3])</div><div><br></div><div><br></div><div>On Fri, May 3, 2013 at 6:50 PM, Gabor Grothendieck</div><div><<a href="mailto:ggrothendieck@gmail.com">ggrothendieck@gmail.com</a>> wrote:</div><div><br></div><div>Consider this example:</div><div><br></div><div>DT[1:4,,nomatch=0]</div><div><br></div><div>a</div><div>1: a</div><div>2: b</div><div>3: c</div><div>4: NA</div><div><br></div><div>Should it not return only the first 3 rows? It seems to be ignoring</div><div>the nomatch=0.</div><div><br></div><div>--</div><div>Statistics & Software Consulting</div><div>GKX Group, GKX Associates Inc.</div><div>tel: 1-877-GKX-GROUP</div><div>email: ggrothendieck at <a href="http://gmail.com">gmail.com</a></div><div><br></div><div><br></div><div><br></div><div><br></div><div>--</div><div>Statistics & Software Consulting</div><div>GKX Group, GKX Associates Inc.</div><div>tel: 1-877-GKX-GROUP</div><div>email: ggrothendieck at <a href="http://gmail.com">gmail.com</a></div><div>_______________________________________________</div><div>datatable-help mailing list</div><div><a href="mailto:datatable-help@lists.r-forge.r-project.org">datatable-help@lists.r-forge.r-project.org</a></div><div><br></div><div><br></div><div><a href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help">https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help</a></div><div><br></div><div><br></div><div><br></div><div><br></div><div>--</div><div>Statistics & Software Consulting</div><div>GKX Group, GKX Associates Inc.</div><div>tel: 1-877-GKX-GROUP</div><div>email: ggrothendieck at <a href="http://gmail.com">gmail.com</a></div><div><br></div><div><br></div><div><br></div><div><br></div><div>--</div><div>Statistics & Software Consulting</div><div>GKX Group, GKX Associates Inc.</div><div>tel: 1-877-GKX-GROUP</div><div>email: ggrothendieck at <a href="http://gmail.com">gmail.com</a></div><div>_______________________________________________</div><div>datatable-help mailing list</div><div><a href="mailto:datatable-help@lists.r-forge.r-project.org">datatable-help@lists.r-forge.r-project.org</a></div><div><a href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help">https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help</a></div></div></blockquote><div><br></div><div><br></div><div><br></div><div>--</div><div>Statistics & Software Consulting</div><div>GKX Group, GKX Associates Inc.</div><div>tel: 1-877-GKX-GROUP</div><div>email: ggrothendieck at <a href="http://gmail.com">gmail.com</a></div></div></div></span>
</blockquote>
<div>
<br>
</div>