ttestbf: Error in is.infinite(c(x, y)) - r

This is a question about an error in R's package BayesFactors.
When I tried the code generated in this example, I can use ttestBF fine.
However, when I tried running ttestBF on my data I got the following error:
Error in is.infinite(c(x, y)) :
default method not implemented for type 'list'
I also get that error if I create very simple data like this:
why <- data.frame(sensitivity = c(5, 6, 7, 7, 8, 9), perspective = c(1, 1, 1, 0, 0, 0))
ttestBF(sensitivity ~ perspective, data = why)
t.test(sensitivity ~ perspective, data = why)
The t.test works fine. I imagine it is a very simple issue, but I can't figure this out, and I guess others might face similar issues.

I eventually got the answer from the relevant github Issues thread.
BayesFactor::ttestBF(formula=sensitivity ~ perspective, data = why)

Related

Running R package "WARN" results in "Remains:" and then a number

I'm a researcher working in the R package WARN by Tsutaya (2013). I've gotten it to work fine using the example dataset, but when using my own data I think the code gets stuck in a loop.
library(WARN)
warn(age = nonadult$age,
d15N = nonadult$d15N,
female.mean = mean(female$d15N),
female.sd = NA,
fraction = "collagen",
prior = c(0.5, 3, 3, 3, 1.9, 0.9, female.mean, 3, 0, 1),
num.particle = 10000,
form = "parabolic",
tolerances = c(2.0, 1.0, 0.5, 0.25, 0.125, 0.0625, 0))
I just get this in the console:
Remains: 7
Sometimes if I wait, the number ticks down but never gets to 0. Sometimes the number is lower, but usually it's 7. I have to force-quit using the stop button and then try tweaking things.
I think it has to do with the female.mean argument. I tried just giving a single number, female.mean = 9.87, but it didn't like that.
Is it just taking forever to run the code? When I use the example dataset it runs instantly. For this, I can walk away, get a drink, come back and it's still counting down, or seems to be stuck at 1. My dataset is larger than the example dataset... but still.
Any help is much appreciated!

Histogram: 'x' must be numeric

I am currently working on a statical analysis using histogram. However, when I try to plot the histogram of the data, an "x must be numeric" error appeared.
x < - c(1, 2, 3, 4, 5)
y < - c(1, 5, 7, 21, 34)
DATA <- data.frame(x,y)
plot(hist(y ~ x, DATA, breaks = 50))
I try different solutions found on the Stack Overflow community, yet nothing works for my codes. Any help is highly appreciated. Thank You.

Need help fixing the plot for a simple curve() function code

I am trying to plot four separate functions on the same graph using the curve() function in r. I came up with the following code:
for (n in 1:4){
curve(n*sin(x), -5, 5, add = TRUE)
}
Unfortunately, when I try that, the resulting plot is extremely zoomed in on one arbitrary point of the graph (axes labels nor graph borders can be seen either). Just to clarify, there is no resulting error message in the console at all, the plot is just very zoomed in.
Instead of plotting them in a for loop, I tried plotting them separately to see if it would work and it did. I used:
curve(4*sin(x), -5, 5)
curve(3*sin(x), -5, 5, add = TRUE)
curve(2*sin(x), -5, 5, add = TRUE)
curve(1*sin(x), -5, 5, add = TRUE)
I had also thought that it could be that I used curve() in a for loop; however, it has worked for this code (demonstrating that the function doesn't seem to care whether I use it in a loop-type function):
for (n in 0:5){
curve(x^n, -3, 3, add = TRUE)
}
Besides trying out different code, I have closed my graphics device, turned it off with dev.off(), restarted RStudio, but none of it has worked.
If I were only using a sequence from 1 to 4, like I mentioned above, I wouldn't care about typing them separately; however, I plan on using a much larger range of sequences in the future (like 1:50 or 1:100 for example).
I'm using RStudio version 3.4.4 with macOS 10.14.2 if that matters.

How does R pass a variable from one object to a function without returning it?

I'm fairly new to R-programming and have been struggling to understand how certain objects seem to pass variables to functions, but don't seem to return these variables overtly. Have a look at this example:
install.packages("cluster")
library(cluster)
x <- rbind(cbind(rnorm(10, 0, 0.5), rnorm(10, 0, 0.5)),
cbind(rnorm(15, 5, 0.5), rnorm(15, 5, 0.5)),
cbind(rnorm( 3,3.2,0.5), rnorm( 3,3.2,0.5)))
fannyx <- cluster::fanny(x, 2)
p <- cluster::clusplot(fannyx)
When examining the plot, the following information is provided:
These two components explain 100 % of the point variability
I simply don't understand where how this information is passed! The variability explained is not returned by the fannyx-object.
I've encountered this issue before when other functions have provided more information by summary() than by using print().
How can this be explained?
If we expand the clusplot function
cluster:::clusplot.default
We can see the line of code:
sub = paste("These two components explain",
round(100 * var.dec, digits = 2), "% of the point variability.")
So in this case this particular metric is calculated internally within the function, and then added to the plot.
Edit:
And we can see that cluster:::mkCheckX returns var.dec, which is called in clusplot

How to avoid polluting the current scope (with `library(...)`)

As a matter of long-standing policy, I avoid importing names into (aka "polluting") the current scope, and instead I use fully-qualified names when referring to items defined in a different package.
The script below shows that, in R, using qualified names is, in itself, not enough.
#!/usr/bin/env Rscript
set.seed(0)
x <- local({
x0 <- matrix(rnbinom(80, size = 5, mu = 10), nrow = 20)
`rownames<-`(rbind(0, c(0, 0, 2, 2), x0),
paste("Tag", 1:(nrow(x0) + 2), sep = "."))
})
y <- edgeR::DGEList(counts = x,
group = rep(1:2, each = 2),
lib.size = 1001:1004)
## library(edgeR)
y[1, 1]
The script fails with
Error in y[1, 1] : incorrect number of dimensions
Execution halted
The script's only crime appears to be not having included the line library(edgeR) somewhere before the failing statement, since the error disappears if one un-comments the commented-out line.
This is voodoo, imho.
Is there a way to avoid the error without polluting the current scope with library(edgeR)?
When you avoid loading the edgeR package, you also avoid loading the [.DGEList method, which is necessary to execute y[1, 1]. If you prefer not to load the edgeR library, you'll need to call the extraction function directly:
edgeR::`[.DGEList`(y, 1, 1)
If you don't like the fully qualified syntax, you can bring in the method you need with
`[.DGEList` <- edgeR::`[.DGEList`
Then y[1, 1] will work as expected. But this is another form of pollution and I'm not sure I'd recommend it as a general solution.

Resources