r - knitr gets tricked by data.table `:=` assignment -

r - knitr gets tricked by data.table `:=` assignment -

it seems knitr doesn't understand dt[, a:=1] should not result in output of dt document. there way stop behaviour?

example knitr document: data.table markdown ======================================================== suppose create `data.table` in **r markdown** ```{r} dt = data.table(a = rnorm(10)) ``` notice doesn't display contents until ```{r} dt ``` style command. however, if want utilize `:=` create column ```{r} dt[, c:=5] ``` appear absence of equals sign tricks `knitr` thinking printed. knitr output:

is knitr bug or data.table bug?

edit

i have noticed, knitr beingness weird when echoing code. @ output above. in source code have dt[, c:=5] knitr renders

dt[, `:=`(c, 5)]

weird...

edit 2: caching

caching seems have problem := must different cause, separate question here: why knitr caching fail data.table `:=`?

update oct 2014. in data.table v1.9.5 :

:= no longer prints in knitr consistency behaviour @ prompt, #505. output of test knit("knitr.rmd") in data.table's unit tests.

and related :

if (true) dt[,lhs:=rhs] doesn't print (thanks jureiss, #869). test added. work we've had live 1 downside: if := used within function no dt[] before end of function, next time dt typed @ prompt, nil printed. repeated dt print. avoid this: include dt[] after lastly := in function. if not possible (e.g., it's not function can change) print(dt) , dt[] @ prompt guaranteed print. before, adding [] on end of := query recommended idiom update , print; e.g. > dt[,foo:=3l][]

previous reply kept posterity (the global$depthtrigger business no longer done data.table v1.9.5 no longer true) ...

just clear understand then: knitr printing when don't want to.

try increasing data.table:::.global$depthtrigger little bit @ start of script.

this 3 :

data.table:::.global$depthtrigger [1] 3

i don't know how much eval depth knitr adds stack. seek changing trigger 4 first; i.e.

assign("depthtrigger", 4, data.table:::.global)

and @ end of knitr script ensure set 3. if 4 doesn't work, seek 5, 6. if 10 give , i'll think again. ;-p

why might work?

see news v1.8.4 :

dt[,lhs:=rhs,...] no longer prints dt. implements #2128 "try 1 time again dt[i,j:=value] homecoming invisibly". discussions here : how suppress output when using `:=` in r {data.table}, prior v1.8.3? http://r.789695.n4.nabble.com/avoiding-print-when-using-tp4643076.html faqs 2.21 , 2.22 have been updated.

faq 2.21 why dt[i,col:=value] homecoming whole of dt? expected either no visible value (consistent <-), or message or homecoming value containing how many rows updated. isn't obvious info has indeed been updated reference. has changed in v1.8.3 meet expectations. please upgrade. whole of dt returned (now invisibly) compound syntax can work; e.g., dt[i,done:=true][,sum(done)]. number of rows updated returned when verbosity on, either on per query basis or globally using options(datatable.verbose=true).

faq 2.22 ok, thanks. hard result of dt[i,col:=value] beingness returned invisibly? r internally forces visibility on [. value of funtab's eval column (see src/main/names.c) [ 0 meaning forcefulness r_visible on (see r-internals section 1.6). therefore, when tried invisible() or setting r_visible 0 straight ourselves, eval in src/main/eval.c forcefulness on again. solve problem, key stop trying stop print method running after :=. instead, within := (from v1.8.3) set global flag print method uses know whether print or not.

that global flag data.table:::.global$print. @ top of data.table:::print.data.table you'll see looking @ it. that's because there no known way suppress printing [ (as faq 2.22 explains).

so, within := within [.data.table looks see how "deep" phone call :

if (cstack_info()[["eval_depth"]] <= .global$depthtrigger) { suppprint = function(x) { .global$print=false; x } # suppress print when returns ok not on error, bug #2376. # to: http://stackoverflow.com/a/13606880/403310 # appropriate returns next point # wrapped i.e. return(suppprint(x)). }

essential that's saying: if dt[,x:=y] running @ prompt, know repl going phone call print method on result, beyond control. ok, given print method going run, i'm going suppress within print method setting flag (since print method runs (i.e. print.data.table) can control).

in knitr's case it's simulating repl in clever way. isn't script, iiuc, otherwise dt[,x:=y] wouldn't print anyway reason. because it's simulating repl via eval there level of eval depth code run knitr. or similar (i don't know knitr).

which why i'm thinking increasing depthtrigger might trick.

hacky/crufty, agree. if works, , allow me know value works, can alter data.table knitr aware , alter depthtrigger automatically. or improve solutions welcome.

r data.table knitr