Skip to content

glm.nb and Error in x[good, , drop = FALSE] * w : non-conformable arrays

3 messages · Patrick Giraudoux, Ivan Krylov

#
Dear Listers,

I meet an error with glm.nb that I cannot explain the origin (and find a 
fix). The model I want to fit is the following:

library(MASS)

glm.nb(deg~offset(log(durobs))+zone,data=db)

and the data.frame is dumped below.

Has anyone an idea about what the trouble comes from ? (except computing 
leads to a non-conformable array somewhere... the question is why; 
fitting goes through without any problem eg with a Poisson link)

Best,

Patrick


db <-
structure(list(deg = structure(c(0, 1, 0, 3, 0, 1, 0, 2, 1, 0,
3, 0, 0, 0, 4, 1, 0, 0, 0, 0, 4, 0, 0, 0, 4, 3, 2, 0, 0, 0, 0,
0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 3, 2, 3, 0, 1, 1, 0, 0, 0, 0, 1,
0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 2, 0, 0, 0, 2, 1, 0, 2, 0, 1, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 2, 1, 0, 1, 0, 0, 0, 0, 0,
0, 0, 0, 0, 1, 0, 0, 0, 2, 1, 0, 0, 1, 3, 2, 1, 2, 0, 0, 0, 0,
0, 1, 0, 0, 2, 0, 0, 0, 0, 0, 1, 2, 0, 0, 0, 0, 2, 1, 1, 0), dim = 135L, 
class = "table"),
 ??? durobs = c(371, 371, 371, 371, 371, 371, 239, 266, 234, 71,
 ??? 436, 407, 407, 414, 415, 418, 415, 329, 414, 414, 415, 330,
 ??? 435, 436, 210, 436, 214, 436, 436, 210, 434, 438, 438, 402,
 ??? 402, 289, 264, 264, 434, 435, 434, 434, 434, 434, 434, 427,
 ??? 427, 427, 328, 422, 291, 412, 221, 417, 416, 416, 79, 322,
 ??? 213, 440, 434, 462, 397, 457, 419, 406, 316, 392, 392, 392,
 ??? 392, 392, 452, 386, 399, 305, 240, 404, 226, 226, 381, 385,
 ??? 392, 388, 388, 391, 396, 392, 385, 385, 385, 237, 378, 378,
 ??? 378, 381, 126, 315, 379, 314, 185, 313, 312, 301, 312, 312,
 ??? 310, 310, 307, 306, 304, 455, 472, 472, 466, 467, 334, 565,
 ??? 429, 429, 425, 422, 421, 419, 417, 417, 410, 405, 195, 422,
 ??? 419, 419, 426, 426, 442), zone = c("MO1", "MO1", "MO1", "MO1",
 ??? "MO1", "MO1", "MO1", "MO1", "MO1", "MO1", "MO1", "MO1", "MO1",
 ??? "MO1", "MO1", "MO1", "MO1", "MO1", "MO1", "MO1", "MO1", "MO1",
 ??? "MO1", "MO1", "MO1", "MO1", "MO1", "MO1", "MO1", "MO1", "MO1",
 ??? "MO1", "MO1", "MO1", "MO1", "MO1", "MO1", "MO1", "MO1", "MO1",
 ??? "MO1", "MO1", "MO1", "MO1", "MO1", "MO1", "MO1", "MO1", "MO1",
 ??? "MO1", "MO1", "MO1", "MO1", "MO1", "MO1", "MO1", "MO1", "MO1",
 ??? "MO1", "MO1", "MO1", "MO1", "MO1", "MO1", "MO1", "MO1", "MO1",
 ??? "MO2", "MO2", "MO2", "MO2", "MO2", "MO2", "MO2", "MO2", "MO2",
 ??? "MO2", "MO2", "MO2", "MO2", "MO2", "MO2", "MO2", "MO2", "MO2",
 ??? "MO2", "MO2", "MO2", "MO2", "MO2", "MO2", "MO2", "MO2", "MO2",
 ??? "MO2", "MO2", "MO2", "MO2", "MO2", "MO2", "MO2", "MO2", "MO2",
 ??? "MO2", "MO2", "MO2", "MO2", "MO2", "MO2", "MO2", "MO2", "MO2",
 ??? "MO2", "MO2", "MO2", "MO2", "MO2", "MO2", "MO2", "MO2", "MO2",
 ??? "MO2", "MO2", "MO2", "MO2", "MO2", "MO2", "MO2", "MO2", "MO2",
 ??? "MO2", "MO2", "MO2", "MO2", "MO2")), row.names = c(NA, 135L
), class = "data.frame")
#
On Fri, 21 Apr 2023 09:02:37 +0200
Patrick Giraudoux <patrick.giraudoux at univ-fcomte.fr> wrote:

            
Thank you for providing both the code and a small piece of data that
reproduces the error!

(It almost worked. Your mailer automatically generated a plain text
version of the e-mail and put Unicode non-breaking spaces in there. R
considers it a syntax error to encounter any of the various Unicode
space-like characters outside string literals.)
The problem is that `deg` is a table, which ends up making the
effective weights a table too. tables are arrays, and element-wise
product rules are stricter for them than for plain matrices. The code
makes use of the ability to take an element-wise product between a
matrix and a vector of the same length as the number of rows in the
matrix:

matrix(1:12, 4) * 1:4 # works
matrix(1:12, 4) * as.array(1:4) # results in the same error

# the right way to take products with an array is to make sure that the
# shapes match exactly
matrix(1:12, 4) * as.array(cbind(1:4, 1:4, 1:4))

One possible solution is to to remove all attributes from db$deg:

db$deg <- as.vector(db$deg)

This way the values of the expressions involved in glm.fit end up being
of the expected type, and the function completes successfully.
#
Many thanks Ivan ! This is fairly clear to me, now... When I dumped the 
data.frame, I found strange to have a "table" declaration for deg, but 
was not able to judge if it was a problem or not (I would have expected 
something as "numeric")
Your workaround is fine to me (I do not need to carry on with table 
attributes).
Best,
Patrick



Le 21/04/2023 ? 10:08, Ivan Krylov a ?crit?: