plot(xpose_plot) vs xpose_plot gives different results. (ie Seeing @x, @y @dir when using plot(xpose_plot))

[mattfidler]

Hi @guiastrennec,

I'm seeing the @x @y etc again. I'm assuming something in the updated tidyverse may be to blame? stringi or something similar?'

My sessionInfo:

> sessionInfo()
R version 3.5.1 (2018-07-02)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Linux

Matrix products: default
BLAS: /usr/lib64/blas/reference/libblas.so.3.7.0
LAPACK: /usr/lib64/R/lib/libRlapack.so

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C              
 [3] LC_TIME=en_US.UTF-8        LC_COLLATE=C              
 [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8   
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C                 
 [9] LC_ADDRESS=C               LC_TELEPHONE=C            
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] RxODE_0.8.1-0      xpose.nlmixr_0.1.3 xpose_0.4.4        ggplot2_3.1.0     
[5] nlmixr_1.0.0-8    

loaded via a namespace (and not attached):
 [1] Rcpp_1.0.1                lattice_0.20-38          
 [3] tidyr_0.8.3               prettyunits_1.0.2        
 [5] ps_1.3.0                  vpc_1.1.0                
 [7] utf8_1.1.4                assertthat_0.2.1         
 [9] rprojroot_1.3-2           digest_0.6.18            
[11] ggforce_0.2.1             R6_2.4.0                 
[13] plyr_1.8.4                backports_1.1.3          
[15] pillar_1.3.1              rlang_0.3.3              
[17] lazyeval_0.2.2            curl_3.2                 
[19] callr_3.1.1               R.utils_2.8.0            
[21] R.oo_1.22.0               Matrix_1.2-15            
[23] mvnfast_0.2.5             labeling_0.3             
[25] desc_1.2.0                devtools_2.0.1           
[27] dparser_0.1.8             stringr_1.4.0            
[29] PreciseSums_0.3           polyclip_1.10-0          
[31] munsell_0.5.0             compiler_3.5.1           
[33] pkgconfig_2.0.2           pkgbuild_1.0.2           
[35] tidyselect_0.2.5          tibble_2.1.1             
[37] fansi_0.4.0               crayon_1.3.4             
[39] dplyr_0.8.0.1             withr_2.1.2              
[41] MASS_7.3-50               lbfgs_1.2.1              
[43] R.methodsS3_1.7.1         grid_3.5.1               
[45] nlme_3.1-137              gtable_0.3.0             
[47] magrittr_1.5              units_0.6-2              
[49] scales_1.0.0              cli_1.1.0                
[51] stringi_1.4.3             n1qn1_6.0.1-3            
[53] farver_1.1.0              fs_1.2.6                 
[55] RcppArmadillo_0.9.300.2.0 remotes_2.0.2            
[57] rex_1.1.2                 testthat_2.0.1           
[59] brew_1.0-6                tools_3.5.1              
[61] glue_1.3.1                tweenr_1.0.1             
[63] purrr_0.3.2               processx_3.2.1           
[65] pkgload_1.0.2             parallel_3.5.1           
[67] colorspace_1.4-1          sessioninfo_1.1.1        
[69] memoise_1.1.0             usethis_1.4.0            

[mattfidler]

Actually, it seems:

plot(dv_vs_pred(xpdb) +
     ylab("Observed Nimotuzumab Concentrations (ug/mL)") +
     xlab("Population Predicted Nimotuzumab Concentrations (ug/mL)"))

gives the strange plots whereas:

dv_vs_pred(xpdb) +
     ylab("Observed Nimotuzumab Concentrations (ug/mL)") +
     xlab("Population Predicted Nimotuzumab Concentrations (ug/mL)")

gives the correct labels.

[mattfidler]

Because of this, I'm unsure how to save plots to pdf in

https://github.com/nlmixrdevelopment/nlmixr-examples/blob/master/case-study-nimotuzumab/Nimo.R

If I don't plot them, they of course don't show up in the GOF page:

https://github.com/nlmixrdevelopment/nlmixr-examples/blob/master/case-study-nimotuzumab/GOF-nimo.pdf

[smouksassi]

did you try the print method ?
( print is implicit when in interactive mode while you need to explicitly call the print in script mode)
print( ggplotobject)
not sure what a plot(ggplotobject) does

[mattfidler]

I did try the print method, but I was trying to be too clever:

dv_vs_pred(xpdb) +
     ylab("Observed Nimotuzumab Concentrations (ug/mL)") +
     xlab("Population Predicted Nimotuzumab Concentrations (ug/mL)") %>% print

did not work because of operator precedence.

I changed to plot which in the past for grid based object like lattice and ggplot printed correctly for me.

If I change to:

print(dv_vs_pred(xpdb) +
     ylab("Observed Nimotuzumab Concentrations (ug/mL)") +
     xlab("Population Predicted Nimotuzumab Concentrations (ug/mL)"))

everything works well.

Perhaps the question is if xpose wants to support the plot method; I believe ggplot supports it.

[bguiastr]

@mattfidler the trick for the operator precedence issue is to use { } e.g.

xpdb %>%
{dv_vs_pred(.) +
     ylab("Observed Nimotuzumab Concentrations (ug/mL)") +
     xlab("Population Predicted Nimotuzumab Concentrations (ug/mL)")} %>% 
print()

I have always used print() but if ggplot2 supports plot() then it would be logical for xpose to support it as well, so I will implement it.

[mattfidler]

That is true; You could also use parentheses. (), but at that point I thought print(...) was easier and more readable than piping everything.

[mattfidler]

One last point/question;

In your new version would you want

plot(xpdb) # where xpdb is the expose data object

To plot a common list of plots that are considered best pratice to run.

[bguiastr]

@mattfidler, having the possibility to store plots within the xpdb is something I have been considering for a while e.g.:

xpbd %>%
dv_vs_ipred() %>%
res_vs_idv() %>%
xpose_save(file = '@run_gofplots.pdf')

But I still need to figure out a few things. Maybe using plot (render the plot) vs. print (prints the xpdb overview as of the current version) could be a way to go but it would break all previous codes...

[mattfidler]

Hi @guiastrennec,

That is what I do for RxODE objects; Plot plots a ggplot of the solved system and print gives the overview.

I'm unsure what would break, but I think since you are adapting s3, things might break in general.