Clarify T/F versus TRUE/FALSE usage in j argument with new FAQ entry*
#6196
Conversation
|
Does |
don't know much about them other than them being abbreviation but here is some info i found online Historical Context: In early versions of S (the precursor to R), T and F were introduced as constants representing TRUE and FALSE, respectively. This convention has been carried over into R for consistency and familiarity with users who have experience with S. Compatibility: Some packages or legacy code might still use T and F instead of TRUE and FALSE. Therefore, maintaining compatibility with these conventions ensures that older code continues to work seamlessly in newer R environments. |
vignettes/datatable-faq.Rmd
Outdated
| @@ -460,6 +460,10 @@ Happily, an internet search for "How does R method dispatch work" (at the time o | |||
|
|
|||
| However, features like basic S3 dispatch (pasting the function name together with the class name) is why some R folk love R. It's so simple. No complicated registration or signature is required. There isn't much needed to learn. To create the `merge` method for data.table all that was required, literally, was to merely create a function called `merge.data.table`. | |||
|
|
|||
| ## Why do `T` and `F` behave differently from `TRUE` and `FALSE` in `data.table`? | |||
|
|
|||
| In R, `T` and `F` are global variables that default to `TRUE` and `FALSE`, respectively. However, they can be redefined in the user environment, leading to unexpected behavior. The `data.table` package might treat `T` and `F` as variable names rather than logical constants. To avoid this issue, always use `TRUE` and `FALSE` for logical indexing and column selection in `data.table`. | |||
There was a problem hiding this comment.
logical indexing -> logical subsetting?
also the user could re-define TRUE and FALSE, so I think saying that T and F default to TRUE and FALSE, and can be redefined is misleading. better to say anything can be redefined in the user environment? but this is not specific to data table so I'm not sure that any FAQ is even needed
@jangorecki can you please review since you commented on the original issue?
It looks like it is something not just for |
In discussion of issue #4846 decision was to add this as faq, Hi @MichaelChirico WDYT ? if this is not needed anymore, i can close this PR |
Co-authored-by: Michael Chirico <[email protected]>
vignettes/datatable-faq.Rmd
Outdated
| @@ -460,6 +460,10 @@ Happily, an internet search for "How does R method dispatch work" (at the time o | |||
|
|
|||
| However, features like basic S3 dispatch (pasting the function name together with the class name) is why some R folk love R. It's so simple. No complicated registration or signature is required. There isn't much needed to learn. To create the `merge` method for data.table all that was required, literally, was to merely create a function called `merge.data.table`. | |||
|
|
|||
| ## Why do `T` and `F` behave differently from `TRUE` and `FALSE` in `data.table`? | |||
|
|
|||
| In R, `T` and `F` are global variables that default to `TRUE` and `FALSE`, respectively. However, they can be redefined in the user environment, leading to unexpected behavior. The `data.table` package might treat `T` and `F` as variable names rather than logical constants. To avoid this issue, always use `TRUE` and `FALSE` for logical subsetting and column selection in `data.table`. | |||
There was a problem hiding this comment.
I think it's too many words. I would simply reproduce the example from the cited issue, then quickly explain what's happening and give the recommendation to avoid T/F shorthand in general.
We might even give a shoutout to T_and_F_symbol_linter() 🙃
@Anirban166 no, not quite -- read the linked issue. Consider Moreover data.table scoping makes things complicated -- consider |
I think it's reasonable that |
There was a problem hiding this comment.
I'm all good with adding this FAQ entry for that purpose, and I think it would be helpful for those who stick to T/F. I just personally don't see much point in their existence in R, as sticking with TRUE or FALSE when needed sounds reasonable and good enough (in terms of typing convenience) to me. (In other words, people shouldn't generally use them even without us telling them I feel)
Agreed, but it's definitely a gotcha for beginners. Heaven knows why but tons of newbies (including myself!) start out writing R with |
| #> 1: a 1 | ||
| #> 2: a 3 | ||
| #> 3: a 6 | ||
| #> 4: b 1 | ||
| #> 5: b 3 | ||
| #> 6: b 6 |
| When you use `TRUE` and `FALSE` in `DT[, .SD, .SDcols = c(TRUE, TRUE, FALSE)]`, `data.table` correctly identifies them as logical constants. This selects the first two columns (`x` and `y`) and excludes the third column (`v`). | ||
|
|
||
| 2. **Using `T`/`F` leads to unexpected behavior:** | ||
| When you use `T` and `F` in `DT[, .SD, .SDcols = c(T, T, F)]`, `data.table` treats `T` and `F` as variable names rather than logical constants. Since these variables are not defined within the `data.table` scope, it results in incorrect behavior. |
There was a problem hiding this comment.
this does not make sense to me, because the variable names are x, y, v, not T, F
closes #4846
Description
This pull request adds a new FAQ entry in
data.table.faq.Rmdto clarify the behavior difference betweenT/FandTRUE/FALSEwhen used in thejargument ofdata.table. The FAQ entry explains why it's recommended to useTRUEandFALSEoverTandFto avoid unexpected behavior.