<div dir="ltr">+1; I especially like #2 and the slight conceptual shift it implies</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, May 4, 2013 at 6:26 AM, Gabor Grothendieck <span dir="ltr"><<a href="mailto:ggrothendieck@gmail.com" target="_blank">ggrothendieck@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The proposal at this point would be:<br>
<br>
1. nomatch= would be replaced by all.i= such that<br>
     X[Y,,nomatch=NA] is the same as X[Y,,all.i=TRUE]<br>
     X[Y,,nomatch=0] is the same as X[Y,,all.i=FALSE]<br>
nomatch= would be deprecated and ultimately removed.<br>
<br>
Note that #1 is simple to implement as it only involves changing names<br>
and values of arguments and does not really change any behavior;<br>
however, its easier to think about because X[Y,,all.i=Z] now has the<br>
same behavior as merge(X, Y, all.y=Z) and so can be quickly understood<br>
by anyone who knows merge in R.  In contrast nomatch= did not even<br>
have the same meaning as in match() since match matches the first<br>
occurrence whereas with mult="all", the default, matching in<br>
data.table matches all occurrences.  Note that the default of merge's<br>
all.y= is all.y=FALSE but the default of all.i= is all.i=TRUE in order<br>
that the default behave as indices do.  Also note that this solves the<br>
problem that nomatch= can only be 0 or NA since a logical can only<br>
have two non-NA values anyways.<br>
<br>
2. If Y were a numeric index vector then all.i= will have the same<br>
effect as if Y were a data.table with Y as its column and is merged<br>
with the row numbers of X.  e.g.  X[1:4,,all.i=FALSE] would be the<br>
same as X[1:3] if X only had 3 rows since 4 does not match a row<br>
number of X and is dropped because all.i=FALSE.  If Y were a numeric<br>
vector with negative values it would be converted to one with positive<br>
values in such a way as to have the established meaning and then the<br>
same strategy is applied. If Y were logical then its recycled giving<br>
YY and the same strategy is applied to which(YY). This description is<br>
intended to be conceptual and the actual internal mechanism could be<br>
different.<br>
<br>
Thus #2 allows one to think of **all** i indexing as merging rather<br>
than as multiple separate concepts (which I believe is consistent with<br>
the original intention of data.table).<br>
<br>
<br>
<br>
<br>
<br>
<br>
On Fri, May 3, 2013 at 8:02 PM, Eduard Antonyan<br>
<div class="HOEnZb"><div class="h5"><<a href="mailto:eduard.antonyan@gmail.com">eduard.antonyan@gmail.com</a>> wrote:<br>
> I think I like this proposal - maybe you should write up a few examples of<br>
> what current behavior is, vs the proposed behavior.<br>
><br>
><br>
> On Fri, May 3, 2013 at 6:54 PM, Gabor Grothendieck <<a href="mailto:ggrothendieck@gmail.com">ggrothendieck@gmail.com</a>><br>
> wrote:<br>
>><br>
>> data.table is supposed to generalize indexing and although not<br>
>> explicitly stated the generalization seems to be that indexing is<br>
>> merging with the row numbers so there is indeed merging going on and<br>
>> that merging should respect nomatch= for consistency.<br>
>><br>
>> On Fri, May 3, 2013 at 6:54 PM, Eduard Antonyan<br>
>> <<a href="mailto:eduard.antonyan@gmail.com">eduard.antonyan@gmail.com</a>> wrote:<br>
>> > There is no join'ing happening here, thus nomatch=0 has no effect.<br>
>> ><br>
>> ><br>
>> > On Fri, May 3, 2013 at 5:52 PM, Gabor Grothendieck<br>
>> > <<a href="mailto:ggrothendieck@gmail.com">ggrothendieck@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> The definition of DT was left out by mistake.  It should be:<br>
>> >><br>
>> >> DT <- data.table(a=letters[1:3])<br>
>> >><br>
>> >><br>
>> >> On Fri, May 3, 2013 at 6:50 PM, Gabor Grothendieck<br>
>> >> <<a href="mailto:ggrothendieck@gmail.com">ggrothendieck@gmail.com</a>> wrote:<br>
>> >> > Consider this example:<br>
>> >> ><br>
>> >> >> DT[1:4,,nomatch=0]<br>
>> >> >     a<br>
>> >> > 1:  a<br>
>> >> > 2:  b<br>
>> >> > 3:  c<br>
>> >> > 4: NA<br>
>> >> ><br>
>> >> > Should it not return only the first 3 rows?  It seems to be ignoring<br>
>> >> > the nomatch=0.<br>
>> >> ><br>
>> >> > --<br>
>> >> > Statistics & Software Consulting<br>
>> >> > GKX Group, GKX Associates Inc.<br>
>> >> > tel: 1-877-GKX-GROUP<br>
>> >> > email: ggrothendieck at <a href="http://gmail.com" target="_blank">gmail.com</a><br>
>> >><br>
>> >><br>
>> >><br>
>> >> --<br>
>> >> Statistics & Software Consulting<br>
>> >> GKX Group, GKX Associates Inc.<br>
>> >> tel: 1-877-GKX-GROUP<br>
>> >> email: ggrothendieck at <a href="http://gmail.com" target="_blank">gmail.com</a><br>
>> >> _______________________________________________<br>
>> >> datatable-help mailing list<br>
>> >> <a href="mailto:datatable-help@lists.r-forge.r-project.org">datatable-help@lists.r-forge.r-project.org</a><br>
>> >><br>
>> >><br>
>> >> <a href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help" target="_blank">https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help</a><br>
>> ><br>
>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> Statistics & Software Consulting<br>
>> GKX Group, GKX Associates Inc.<br>
>> tel: 1-877-GKX-GROUP<br>
>> email: ggrothendieck at <a href="http://gmail.com" target="_blank">gmail.com</a><br>
><br>
><br>
<br>
<br>
<br>
--<br>
Statistics & Software Consulting<br>
GKX Group, GKX Associates Inc.<br>
tel: 1-877-GKX-GROUP<br>
email: ggrothendieck at <a href="http://gmail.com" target="_blank">gmail.com</a><br>
</div></div></blockquote></div><br></div>