Closed deh9951 closed 9 years ago
Hey Dave, thanks for finding this. Would you send me a few lines that show the issue you were having?
@deh9951 This got buried? I played a bit with the pack and unpack functions and checked the network objects but couldn't find the issue! except for the slight inconsistency between the pack and unpack functions. _--- If this issue is resolved, stop reading! :) ---_
Lets get some random data:
F1 <- matrix(rnorm(100), nrow = 10)
inp <- runif(10)
exp <- rexp(10)
out <- abs(rt(n = 10, df = 3))
sto <- runif(n = 10, min = 45, max = 4500)
liv <- sample(c(TRUE, FALSE), size = 10, replace = TRUE)
On this generated data; I construct a Network object using the 'pack' function.
y1 <- pack(flow = F1, input = inp, export = exp, output = out, storage = sto, living = liv)
## [1] "respiration"
## Warning in pack(flow = F1, input = inp, export = exp, output = out, storage
## = sto, : Missing model components: respiration
Now, notice that the network object contains the vertex attribute "living" just as the pack function specifies; this is consistent with the existing Network models as can be seen later.
get.vertex.attribute(y1, attrname = "living")
## [1] TRUE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE TRUE
liv
## [1] TRUE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE TRUE
Whereas when I try it with "Living"; I get NAs.
get.vertex.attribute(y1, attrname = "Living")
## [1] NA NA NA NA NA NA NA NA NA NA
However, I realized that the unpack function returns "Living" component in the list when a Network object is 'unpacked'. But this shouldn't be a scope for confusion for users. Should it?
y2 <- unpack(y1)
class(y2)
## [1] "list"
str(y2)
## List of 7
## $ F : num [1:10, 1:10] 0.4809 0.0345 0.7979 0.2371 0.7659 ...
## ..- attr(*, "dimnames")=List of 2
## .. ..$ : chr [1:10] "1" "2" "3" "4" ...
## .. ..$ : chr [1:10] "1" "2" "3" "4" ...
## $ z : num [1:10] 0.955 0.847 0.578 0.569 0.413 ...
## $ r : num [1:10] 0 0 0 0 0 0 0 0 0 0
## $ e : num [1:10] 1.71 0.307 0.8 0.172 0.728 ...
## $ y : num [1:10] 0.462 0.674 0.383 0.794 0.343 ...
## $ X : num [1:10] 4480 2178 2397 2553 2677 ...
## $ Living: logi [1:10] TRUE FALSE FALSE FALSE FALSE FALSE ...
Here, though the "Living" component is spelled out with an "L", the help file does mention it clearly.
Also, the same goes for the saved Ecosystem models in 'enaR'.
data("troModels"); data("bgcModels")
get.vertex.attribute(troModels[[16]], "living") #For troModels
## [1] TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE
## [12] TRUE FALSE FALSE FALSE
get.vertex.attribute(bgcModels[[16]], "living") #For bgcModels
## [1] TRUE TRUE TRUE FALSE FALSE FALSE FALSE
Hence, at least in Version 2.8.1, the 'pack' function is behaving fine.
packageDescription('enaR')
## Package: enaR
## Type: Package
## Title: Tools for Ecological Network Analysis (ena)
## Version: 2.8.1
## Date: 2015-01-14
## Author: M.K. Lau, S.R. Borrett, D.E. Hines, P. Singh
## Maintainer: Matthew K. Lau <enaR.maintainer@gmail.com>
## Description: Functions for the analysis of ecological networks
## Depends: R (>= 2.10), MASS, stringr, sna, network, gdata
## Suggests: codetools, igraph, R.rsp
## VignetteBuilder: R.rsp
## License: GPL-3
## URL: https://github.com/SEELab/enaR
## Packaged: 2015-01-14 15:58:08 UTC; Aeolus
## NeedsCompilation: no
## Repository: CRAN
## Date/Publication: 2015-01-14 19:32:22
## Built: R 3.2.1; ; 2015-06-22 20:15:00 UTC; unix
##
## -- File: /usr/local/lib/R/site-library/enaR/Meta/package.rds
Hey guys, I get the issue now. Having the unpack function name the living vector “Living” is a bit confusing. I went ahead and changed it on the beta branch so that unpack calls the living vector “living” so that it’s in-line with the network attribute.
I’ll add this change to the next update to the master branch and CRAN, but for now to install from beta:
library(devtools) install_github('SEELab/enaR',ref='beta')
Thanks for working on this!
Matt
On Aug 25, 2015, at 2:28 AM, Pawan notifications@github.com<mailto:notifications@github.com> wrote:
@deh9951https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_deh9951&d=BQMCaQ&c=WO-RGvefibhHBZq3fL85hQ&r=yYM9bdhQa7fj0pqtCBPxMvjOe6gKXC-k_OhnGcaB0ZI&m=wbY8mbGsUaiR2WIZcLJsi_cPIBFNc7gnL80qijyRnXQ&s=PjRPhwwYVJ5sNqmQZ3ywiLxubpwbMQlM-uKYGw3dBlw&e= This got buried? I played a bit with the pack and unpack functions and checked the network objects but couldn't find the issue! --- If this issue is resolved, stop reading! :) ---
Find the code and outputs that I came across, the details of the package are also provided in the end of the document.
Lets get some random data:
F1 <- matrix(rnorm(100), nrow = 10) inp <- runif(10) exp <- rexp(10) out <- abs(rt(n = 10, df = 3)) sto <- runif(n = 10, min = 45, max = 4500) liv <- sample(c(TRUE, FALSE), size = 10, replace = TRUE)
On this generated data; I construct a Network object using the 'pack' function.
y1 <- pack(flow = F1, input = inp, export = exp, output = out, storage = sto, living = liv)
Now, notice that the network object contains the vertex attribute "living" just as the pack function specifies; this is consistent with the existing Network models as can be seen later.
get.vertex.attribute(y1, attrname = "living")
liv
Whereas when I try it with "Living"; I get NAs.
get.vertex.attribute(y1, attrname = "Living")
However, I realized that the unpack function returns "Living" component in the list when a Network object is 'unpacked'. But this shouldn't be a scope for confusion for users. Should it?
y2 <- unpack(y1) class(y2)
str(y2)
Here, though the "Living" component is spelled out with an "L", the help file does mention it clearly.
Also, the same goes for the saved Ecosystem models in 'enaR'.
data("troModels"); data("bgcModels") get.vertex.attribute(troModels[[16]], "living") #For troModels
get.vertex.attribute(bgcModels[[16]], "living") #For bgcModels
Hence, at least in Version 2.8.1, the 'pack' function is behaving fine.
packageDescription('enaR')
— Reply to this email directly or view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_SEELab_enaR_issues_162-23issuecomment-2D134494513&d=BQMCaQ&c=WO-RGvefibhHBZq3fL85hQ&r=yYM9bdhQa7fj0pqtCBPxMvjOe6gKXC-k_OhnGcaB0ZI&m=wbY8mbGsUaiR2WIZcLJsi_cPIBFNc7gnL80qijyRnXQ&s=pdbBLbk-iwhFXBrPgCnX-ED4J9AH_sGH1NBNcbGhXtE&e=.
@MKLau Thanks for addressing this promptly Matt. _Great that you've also changed the help files!_ @deh9951 was it the entire issue? Did we miss something?
Hi All,
Thanks for looking into this, it sounds like you've fixed it- the "living" vs "Living" problem was the entire issue I think.
-Dave
On Wed, Aug 26, 2015 at 2:17 AM, Pawan notifications@github.com wrote:
@MKLau https://github.com/MKLau Thanks for addressing this promptly Matt. Great that you've also changed the help files! @deh9951 https://github.com/deh9951 was it the entire issue? Did we miss something?
— Reply to this email directly or view it on GitHub https://github.com/SEELab/enaR/issues/162#issuecomment-134853072.
When using the pack function, the 'living' input uses a lower case 'l', but the 'Living' piece of the network object uses a capital 'L'. This is not a major issue, but caused come confusion with coding and may cause problems for some users.