[bug] spdep package?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[bug] spdep package?

Jérémie Juste


Hello,


I found a dangerous issue in the library spdep. I get variables x and y
that cannot be removed by rm() and I don't don't how they show up. Can
anyone reproduce this?

~$ R --vanilla
> rm(list=ls())
> library(spdep)
> x
[1]   0  30  60  90 120 150 180 210 240 270 300 330 360 390 420 450
> rm(list=ls())
> x
[1]   0  30  60  90 120 150 180 210 240 270 300 330 360 390 420 450



> Sys.info()

sysname        "Linux"                                    
release        "4.9.0-6-amd64"                            
version        "#1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07)"
nodename       "freegnu"                                  
machine        "x86_64"                                    


> Session


> sessionInfo()

R version 3.4.1 (2017-06-30)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 9 (stretch)

Matrix products: default
BLAS: /usr/local/lib/R/lib/libRblas.so
LAPACK: /usr/local/lib/R/lib/libRlapack.so

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C              
 [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8    
 [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    

loaded via a namespace (and not attached):
[1] compiler_3.4.1

______________________________________________
[hidden email] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: [bug] spdep package?

Henrik Bengtsson-5
It turns out that that 'x' comes from the spData package and lives
inside that package (part of its namespace).

> spData::x
 [1]   0  30  60  90 120 150 180 210 240 270 300 330 360 390 420 450

This is conceptually no different from other objects in package
namespace, although we are more used to seeing functions and not data
object.  Another well-known example of this is:

> base::pi
[1] 3.141593

So, this 'x' is *not* in your global workspace and you cannot remove
it without unloading the package.

/Henrik

On Mon, Jul 23, 2018 at 12:30 PM Jeremie Juste <[hidden email]> wrote:

>
>
>
> Hello,
>
>
> I found a dangerous issue in the library spdep. I get variables x and y
> that cannot be removed by rm() and I don't don't how they show up. Can
> anyone reproduce this?
>
> ~$ R --vanilla
> > rm(list=ls())
> > library(spdep)
> > x
> [1]   0  30  60  90 120 150 180 210 240 270 300 330 360 390 420 450
> > rm(list=ls())
> > x
> [1]   0  30  60  90 120 150 180 210 240 270 300 330 360 390 420 450
>
>
>
> > Sys.info()
>
> sysname        "Linux"
> release        "4.9.0-6-amd64"
> version        "#1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07)"
> nodename       "freegnu"
> machine        "x86_64"
>
>
> > Session
>
>
> > sessionInfo()
>
> R version 3.4.1 (2017-06-30)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Debian GNU/Linux 9 (stretch)
>
> Matrix products: default
> BLAS: /usr/local/lib/R/lib/libRblas.so
> LAPACK: /usr/local/lib/R/lib/libRlapack.so
>
> locale:
>  [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
>  [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
>  [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
>
> loaded via a namespace (and not attached):
> [1] compiler_3.4.1
>
> ______________________________________________
> [hidden email] mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

______________________________________________
[hidden email] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: [FORGED] [bug] spdep package?

Rolf Turner
In reply to this post by Jérémie Juste
On 23/07/18 22:30, Jeremie Juste wrote:
>
>
> Hello,
>
>
> I found a dangerous issue in the library spdep. I get variables x and y
> that cannot be removed by rm() and I don't don't how they show up. Can
> anyone reproduce this?

I cannot.

This is *very* unlikely to be a bug.  People should always exercise a
great deal of caution about conjecturing bugs when they encounter a
phenomenon that they don't understand.

What do you see if you simply do "ls()"?  (After loading spdep.)
I.e. do you see an "x" listed as an object in your workspace/global
environment?

What does find("x") return?

It puzzles me that your sessionInfo() doesn't show something like:

> other attached packages:
> [1] spdep_0.6-13  Matrix_1.2-10 sp_1.2-5

There are probably other issues that you have not told us about.

cheers,

Rolf Turner

--
Technical Editor ANZJS
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276

>
> ~$ R --vanilla
>> rm(list=ls())
>> library(spdep)
>> x
> [1]   0  30  60  90 120 150 180 210 240 270 300 330 360 390 420 450
>> rm(list=ls())
>> x
> [1]   0  30  60  90 120 150 180 210 240 270 300 330 360 390 420 450
>
>
>
>> Sys.info()
>
> sysname        "Linux"
> release        "4.9.0-6-amd64"
> version        "#1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07)"
> nodename       "freegnu"
> machine        "x86_64"
>
>
>> Session
>
>
>> sessionInfo()
>
> R version 3.4.1 (2017-06-30)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Debian GNU/Linux 9 (stretch)
>
> Matrix products: default
> BLAS: /usr/local/lib/R/lib/libRblas.so
> LAPACK: /usr/local/lib/R/lib/libRlapack.so
>
> locale:
>   [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
>   [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
>   [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
>
> loaded via a namespace (and not attached):
> [1] compiler_3.4.1

______________________________________________
[hidden email] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: [bug] spdep package?

Jérémie Juste
In reply to this post by Henrik Bengtsson-5

Helllo,

Thanks for the info. I still think these variables should not be loaded
when library(spdep) is called.

But I'll handle it following your suggestion.

Thanks,

Jeremie






> It turns out that that 'x' comes from the spData package and lives
> inside that package (part of its namespace).
>
>> spData::x
>  [1]   0  30  60  90 120 150 180 210 240 270 300 330 360 390 420 450
>
> This is conceptually no different from other objects in package
> namespace, although we are more used to seeing functions and not data
> object.  Another well-known example of this is:
>
>> base::pi
> [1] 3.141593
>
> So, this 'x' is *not* in your global workspace and you cannot remove
> it without unloading the package.
>
> /Henrik


>>
>>
>> I found a dangerous issue in the library spdep. I get variables x and y
>> that cannot be removed by rm() and I don't don't how they show up. Can
>> anyone reproduce this?
>>
>> ~$ R --vanilla
>> > rm(list=ls())
>> > library(spdep)
>> > x
>> [1]   0  30  60  90 120 150 180 210 240 270 300 330 360 390 420 450
>> > rm(list=ls())
>> > x
>> [1]   0  30  60  90 120 150 180 210 240 270 300 330 360 390 420 450
>>
>>
>>
>> > Sys.info()
>>
>> sysname        "Linux"
>> release        "4.9.0-6-amd64"
>> version        "#1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07)"
>> nodename       "freegnu"
>> machine        "x86_64"
>>
>>
>> > Session
>>
>>
>> > sessionInfo()
>>
>> R version 3.4.1 (2017-06-30)
>> Platform: x86_64-pc-linux-gnu (64-bit)
>> Running under: Debian GNU/Linux 9 (stretch)
>>
>> Matrix products: default
>> BLAS: /usr/local/lib/R/lib/libRblas.so
>> LAPACK: /usr/local/lib/R/lib/libRlapack.so
>>
>> locale:
>>  [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
>>  [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
>>  [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
>>
>> loaded via a namespace (and not attached):
>> [1] compiler_3.4.1
>>
>> ______________________________________________
>> [hidden email] mailing list -- To UNSUBSCRIBE and more, see
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
>> and provide commented, minimal, self-contained, reproducible code.

______________________________________________
[hidden email] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: [bug] spdep package?

Henrik Bengtsson-5
This is intended/expected because the spdep package *depends* on the
spData package (see https://cran.r-project.org/web/packages/spdep/),
which means that the maintainer of spdep intends also spData to be
*attached* whenever spdep is attached.    If they would have only
imported it, then spData would only be *loaded* (but not attached),
and you would not get 'spData' on your search() path and therefore not
see 'x' either.

Example:

## Loading spData
> loadNamespace("spData")
<environment: namespace:spData>

> loadedNamespaces()
[1] "compiler"  "graphics"  "utils"     "grDevices" "stats"     "datasets"
[7] "methods"   "spData"    "base"

## The search path used to find objects
> search()
[1] ".GlobalEnv"        "package:stats"     "package:graphics"
[4] "package:grDevices" "package:utils"     "package:datasets"
[7] "package:methods"   "Autoloads"         "package:base"

## So, spData::x is not found
> x
Error: object 'x' not found

## But is still there
> spData::x
 [1]   0  30  60  90 120 150 180 210 240 270 300 330 360 390 420 450


## Attaching spData, which also happens when you do library(spdat)
> library(spData)
To access larger datasets in this package, install the spDataLarge
package with: `install.packages('spDataLarge',
repos='https://nowosad.github.io/drat/', type='source'))

> loadedNamespaces()
[1] "compiler"  "graphics"  "utils"     "grDevices" "stats"     "datasets"
[7] "methods"   "spData"    "base"

## Now, spData is on the search path
> search()
 [1] ".GlobalEnv"        "package:spData"    "package:stats"
 [4] "package:graphics"  "package:grDevices" "package:utils"
 [7] "package:datasets"  "package:methods"   "Autoloads"
[10] "package:base

> x
 [1]   0  30  60  90 120 150 180 210 240 270 300 330 360 390 420 450

> find("x")
[1] "package:spData"

/Henrik
On Mon, Jul 23, 2018 at 2:01 PM Jeremie Juste <[hidden email]> wrote:

>
>
> Helllo,
>
> Thanks for the info. I still think these variables should not be loaded
> when library(spdep) is called.
>
> But I'll handle it following your suggestion.
>
> Thanks,
>
> Jeremie
>
>
>
>
>
>
> > It turns out that that 'x' comes from the spData package and lives
> > inside that package (part of its namespace).
> >
> >> spData::x
> >  [1]   0  30  60  90 120 150 180 210 240 270 300 330 360 390 420 450
> >
> > This is conceptually no different from other objects in package
> > namespace, although we are more used to seeing functions and not data
> > object.  Another well-known example of this is:
> >
> >> base::pi
> > [1] 3.141593
> >
> > So, this 'x' is *not* in your global workspace and you cannot remove
> > it without unloading the package.
> >
> > /Henrik
>
>
> >>
> >>
> >> I found a dangerous issue in the library spdep. I get variables x and y
> >> that cannot be removed by rm() and I don't don't how they show up. Can
> >> anyone reproduce this?
> >>
> >> ~$ R --vanilla
> >> > rm(list=ls())
> >> > library(spdep)
> >> > x
> >> [1]   0  30  60  90 120 150 180 210 240 270 300 330 360 390 420 450
> >> > rm(list=ls())
> >> > x
> >> [1]   0  30  60  90 120 150 180 210 240 270 300 330 360 390 420 450
> >>
> >>
> >>
> >> > Sys.info()
> >>
> >> sysname        "Linux"
> >> release        "4.9.0-6-amd64"
> >> version        "#1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07)"
> >> nodename       "freegnu"
> >> machine        "x86_64"
> >>
> >>
> >> > Session
> >>
> >>
> >> > sessionInfo()
> >>
> >> R version 3.4.1 (2017-06-30)
> >> Platform: x86_64-pc-linux-gnu (64-bit)
> >> Running under: Debian GNU/Linux 9 (stretch)
> >>
> >> Matrix products: default
> >> BLAS: /usr/local/lib/R/lib/libRblas.so
> >> LAPACK: /usr/local/lib/R/lib/libRlapack.so
> >>
> >> locale:
> >>  [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
> >>  [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
> >>  [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
> >>
> >> loaded via a namespace (and not attached):
> >> [1] compiler_3.4.1
> >>
> >> ______________________________________________
> >> [hidden email] mailing list -- To UNSUBSCRIBE and more, see
> >> https://stat.ethz.ch/mailman/listinfo/r-help
> >> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> >> and provide commented, minimal, self-contained, reproducible code.

______________________________________________
[hidden email] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: [FORGED] [bug] spdep package?

Jérémie Juste
In reply to this post by Rolf Turner

Hello,


>This is *very* unlikely to be a bug.  People should always exercise a
>great deal of caution about conjecturing bugs when they encounter a
>phenomenon that they don't understand.

Ok,  I over reacted and I should let the package maintainers
qualify what is a bug or not. My point is that it is surprising to have
access these variables in the global environment when loading the spdep
library.

I normally I would expect the following

 rm(list=ls())
 myfun <- function(x){
        y+ 33}
       
> myfun(x)
> Error in myfun(4) : object 'y' not found

But this is not cool
> myfun()
 [1]  33  63  93 123 153 183 213 243 273 303 333 363 393 423 453 483


> It puzzles me that your sessionInfo() doesn't show something like:
You are right. My apologies. I confused sessions when I pasted the
sessionInfo.  Allow me to correct.



<on the Terminal> R --vanilla -q
> ls()
character(0)
> library(spdep)
Loading required package: sp
Loading required package: Matrix
Loading required package: spData
To access larger datasets in this package, install the spDataLarge
package with: `install.packages('spDataLarge')`
> ls()
character(0)
> sessionInfo()
R version 3.4.1 (2017-06-30)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 9 (stretch)

Matrix products: default
BLAS: /usr/local/lib/R/lib/libRblas.so
LAPACK: /usr/local/lib/R/lib/libRlapack.so

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C              
 [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8    
 [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] spdep_0.7-7    spData_0.2.6.7 Matrix_1.2-10  sp_1.2-5      

loaded via a namespace (and not attached):
 [1] lattice_0.20-35     deldir_0.1-14       gtools_3.5.0      
 [4] MASS_7.3-47         grid_3.4.1          nlme_3.1-131      
 [7] coda_0.19-1         data.table_1.10.4-3 gdata_2.18.0      
[10] LearnBayes_2.15     gmodels_2.16.2      boot_1.3-19        
[13] splines_3.4.1       compiler_3.4.1      filehash_2.4-1    
[16] expm_0.999-2      
> x
 [1]   0  30  60  90 120 150 180 210 240 270 300 330 360 390 420 450


I think Henrik Bengtsson has identified the issue see the next thread.

Best regards,

Jeremie

______________________________________________
[hidden email] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: [bug] spdep package?

Jérémie Juste
In reply to this post by Henrik Bengtsson-5

Many thanks for the info.

I see the point but I'll think calling the spData would be a cheaper
price to pay. If each package one load provide access to their variables
things are likely to get messy.

I guess many R users would like to control the variables in their global
environment.

And since it is not trival to protect variables inside a function from
the parent environment this is potentially dangerous.

Best wishes,

Jeremie










Henrik Bengtsson <[hidden email]> writes:

> This is intended/expected because the spdep package *depends* on the
> spData package (see https://cran.r-project.org/web/packages/spdep/),
> which means that the maintainer of spdep intends also spData to be
> *attached* whenever spdep is attached.    If they would have only
> imported it, then spData would only be *loaded* (but not attached),
> and you would not get 'spData' on your search() path and therefore not
> see 'x' either.
>
> Example:
>
> ## Loading spData
>> loadNamespace("spData")
> <environment: namespace:spData>
>
>> loadedNamespaces()
> [1] "compiler"  "graphics"  "utils"     "grDevices" "stats"     "datasets"
> [7] "methods"   "spData"    "base"
>
> ## The search path used to find objects
>> search()
> [1] ".GlobalEnv"        "package:stats"     "package:graphics"
> [4] "package:grDevices" "package:utils"     "package:datasets"
> [7] "package:methods"   "Autoloads"         "package:base"
>
> ## So, spData::x is not found
>> x
> Error: object 'x' not found
>
> ## But is still there
>> spData::x
>  [1]   0  30  60  90 120 150 180 210 240 270 300 330 360 390 420 450
>
> ## Attaching spData, which also happens when you do library(spdat)
>> library(spData)
> To access larger datasets in this package, install the spDataLarge
> package with: `install.packages('spDataLarge',
> repos='https://nowosad.github.io/drat/', type='source'))
>
>> loadedNamespaces()
> [1] "compiler"  "graphics"  "utils"     "grDevices" "stats"     "datasets"
> [7] "methods"   "spData"    "base"
>
> ## Now, spData is on the search path
>> search()
>  [1] ".GlobalEnv"        "package:spData"    "package:stats"
>  [4] "package:graphics"  "package:grDevices" "package:utils"
>  [7] "package:datasets"  "package:methods"   "Autoloads"
> [10] "package:base
>
>> x
>  [1]   0  30  60  90 120 150 180 210 240 270 300 330 360 390 420 450
>
>> find("x")
> [1] "package:spData"
>
> /Henrik
> On Mon, Jul 23, 2018 at 2:01 PM Jeremie Juste <[hidden email]> wrote:
>>
>>
>> Helllo,
>>
>> Thanks for the info. I still think these variables should not be loaded
>> when library(spdep) is called.
>>
>> But I'll handle it following your suggestion.
>>
>> Thanks,
>>
>> Jeremie
>>
>>
>>
>>
>>
>>
>> > It turns out that that 'x' comes from the spData package and lives
>> > inside that package (part of its namespace).
>> >
>> >> spData::x
>> >  [1]   0  30  60  90 120 150 180 210 240 270 300 330 360 390 420 450
>> >
>> > This is conceptually no different from other objects in package
>> > namespace, although we are more used to seeing functions and not data
>> > object.  Another well-known example of this is:
>> >
>> >> base::pi
>> > [1] 3.141593
>> >
>> > So, this 'x' is *not* in your global workspace and you cannot remove
>> > it without unloading the package.
>> >
>> > /Henrik
>>
>>
>> >>
>> >>
>> >> I found a dangerous issue in the library spdep. I get variables x and y
>> >> that cannot be removed by rm() and I don't don't how they show up. Can
>> >> anyone reproduce this?
>> >>
>> >> ~$ R --vanilla
>> >> > rm(list=ls())
>> >> > library(spdep)
>> >> > x
>> >> [1]   0  30  60  90 120 150 180 210 240 270 300 330 360 390 420 450
>> >> > rm(list=ls())
>> >> > x
>> >> [1]   0  30  60  90 120 150 180 210 240 270 300 330 360 390 420 450
>> >>
>> >>
>> >>
>> >> > Sys.info()
>> >>
>> >> sysname        "Linux"
>> >> release        "4.9.0-6-amd64"
>> >> version        "#1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07)"
>> >> nodename       "freegnu"
>> >> machine        "x86_64"
>> >>
>> >>
>> >> > Session
>> >>
>> >>
>> >> > sessionInfo()
>> >>
>> >> R version 3.4.1 (2017-06-30)
>> >> Platform: x86_64-pc-linux-gnu (64-bit)
>> >> Running under: Debian GNU/Linux 9 (stretch)
>> >>
>> >> Matrix products: default
>> >> BLAS: /usr/local/lib/R/lib/libRblas.so
>> >> LAPACK: /usr/local/lib/R/lib/libRlapack.so
>> >>
>> >> locale:
>> >>  [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
>> >>  [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
>> >>  [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
>> >>
>> >> loaded via a namespace (and not attached):
>> >> [1] compiler_3.4.1
>> >>
>> >> ______________________________________________
>> >> [hidden email] mailing list -- To UNSUBSCRIBE and more, see
>> >> https://stat.ethz.ch/mailman/listinfo/r-help
>> >> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
>> >> and provide commented, minimal, self-contained, reproducible code.

______________________________________________
[hidden email] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.