You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue could be automatically handled by #4386 but the problem is that forder strips out all attributes before even calling forderv. This happens because when we call
d= data.table(x=2:1)
d[order(x, na.last=FALSE)]
We technically call forder on integer vector x, not on a d data.table. To not duplicate the work, to address that, it is best to rely on #4386 and we have to make better input massaging when preparing arguments for forderv, retaining key/index attributes.
According to ideas in #4346 the proper way to address that would be to optimize from [.data.table directly to forderv, and not to forder.
Activity
in dev index optimize for order call
[-]order could utilize existing index[/-][+]`order` could utilize existing index[/+]jangorecki commentedon Apr 19, 2020
This issue could be automatically handled by #4386 but the problem is that
forderstrips out all attributes before even callingforderv. This happens because when we callWe technically call
forderon integer vectorx, not on addata.table. To not duplicate the work, to address that, it is best to rely on #4386 and we have to make better input massaging when preparing arguments forforderv, retaining key/index attributes.According to ideas in #4346 the proper way to address that would be to optimize from
[.data.tabledirectly toforderv, and not toforder.jangorecki commentedon May 11, 2020
It should be possible to optimize as well
d[order(x)]in cases wherexdoes not have NAs, which can be a cheap to check if index exists.