On 8/23/19 2:52 PM, Serena De Stefani wrote:
I have a computer simulation in which a virtual agent end up in different
areas of a layout based on several factors. There are 18 conditions in
total.
If I collapse the datapoint into bins, where each bin is one of the areas,
the data would look lik
I have a computer simulation in which a virtual agent end up in different
areas of a layout based on several factors. There are 18 conditions in
total.
If I collapse the datapoint into bins, where each bin is one of the areas,
the data would look like this:
x0 <- c(3,3,5,5,2) # computer simula
Hello,
Inline.
Às 20:45 de 23/08/19, Sorkin, John escreveu:
I have code that works perfectly when run as in-line code, but that fails when
the code is put into a function with the following message:
Error in contest1D.lmerModLmerTest(model, ll, rhs = rhs, ddf = ddf, confint =
confint, :
lengt
Sorry -- neglected to cc the list.
Bert
-- Forwarded message -
From: Bert Gunter
Date: Fri, Aug 23, 2019 at 2:06 PM
Subject: Re: [R] Code that works when run as straight code, but that fails
when run as a function
To: Sorkin, John
s1E is not defined in your function in:
SBP <-
Since this isn't reproducible, my first guess would be that alldata,
which is required for your model, is not visible within the
environment of the function.
Or something similar: that kind of problem is almost always a scoping issue.
Sarah
On Fri, Aug 23, 2019 at 3:46 PM Sorkin, John wrote:
>
I have code that works perfectly when run as in-line code, but that fails when
the code is put into a function with the following message:
Error in contest1D.lmerModLmerTest(model, ll, rhs = rhs, ddf = ddf, confint =
confint, :
length(L) == length(model@beta) is not TRUE
Why does moving the code
Thanks for all those comments, and thanks Terry for the repair!
Tamas
2019. augusztus 23., 14:40:05, írtad:
I've spent some time chasing this down, and another error of similar type.
It's repaired in version 3.0-9 (soon to go to CRAN, or at least that is the
plan --- I'm working through
On the other hand, SAS gets the same answer all three ways. And the answer SAS
gets is closest to the one that R gets when using the daily cutting.
Obs _TIES_ _TYPE_ _STATUS_ _NAME_ trt prior karno _LNLIKE_
1 EFRON PARMS 0 Converged time 0.1801972156 -0.005550913 -0.033771016
-483.9277463
2
Hi Sophie,
It's good form to reply to the list, not directly to me - I'm not able
to help people individually. It's also good form to put the necessary
info directly into your email, rather than expecting people to open
attachments (which the mailing list might not even allow, depending on
format)
# For what it is worth, even the second fit (cuts at observation times) does
not give identical coefficient estimates as using the original data structure.
answer <- coef( coxph(Surv(time, status) ~ trt + prior + karno, data = veteran)
)
veteran2 <- survSplit( Surv(time, status) ~ trt + prior +
I think this is a case of (a - x) + x != a in floating arithmetic. When
updating the risk set, you subtract sums of covariates at the end of a time
interval, then add them back at the beginning of the next interval. Something
like that, anyway. As in
> x <- rnorm(1000)
> sum(c(x,-x))
[1] -1.387
Den 2019-08-22 kl. 21:48, skrev Göran Broström:
On 2019-08-18 19:10, Ferenci Tamas wrote:
Dear All,
Consider the following simple example:
library( survival )
data( veteran )
coef( coxph(Surv(time, status) ~ trt + prior + karno, data = veteran) )
trt prior karno
12 matches
Mail list logo
