The all.equal was a side issue for me; I don't have strong opinions one way or
the other.
You are welcome to leave me out of the loop on that. (Or leave me on the cc,
whatever is
easiest).
I will update the survival package once the [.terms issues are addressed.
One debatable issues is
On 05/04/2019 11:33 a.m., Martin Maechler wrote:
Duncan Murdoch
on Fri, 5 Apr 2019 11:12:48 -0400 writes:
> On 05/04/2019 10:46 a.m., Therneau, Terry M., Ph.D. wrote:
>>
>>
>> On 4/5/19 9:39 AM, Duncan Murdoch wrote:
>>> On 05/04/2019 10:19 a.m., Therneau, Terry M.
> Martin Maechler
> on Fri, 5 Apr 2019 17:33:54 +0200 writes:
> Duncan Murdoch
> on Fri, 5 Apr 2019 11:12:48 -0400 writes:
>> On 05/04/2019 10:46 a.m., Therneau, Terry M., Ph.D. wrote:
>>>
>>>
>>> On 4/5/19 9:39 AM, Duncan Murdoch wrote:
On 05/
> Duncan Murdoch
> on Fri, 5 Apr 2019 11:12:48 -0400 writes:
> On 05/04/2019 10:46 a.m., Therneau, Terry M., Ph.D. wrote:
>>
>>
>> On 4/5/19 9:39 AM, Duncan Murdoch wrote:
>>> On 05/04/2019 10:19 a.m., Therneau, Terry M., Ph.D. wrote:
Duncan,
On 05/04/2019 10:46 a.m., Therneau, Terry M., Ph.D. wrote:
On 4/5/19 9:39 AM, Duncan Murdoch wrote:
On 05/04/2019 10:19 a.m., Therneau, Terry M., Ph.D. wrote:
Duncan,
I should have included it in my original note, but
all.equal(unclass(t0x), unclass(t1x))
returns TRUE as well. I
On 4/5/19 9:39 AM, Duncan Murdoch wrote:
On 05/04/2019 10:19 a.m., Therneau, Terry M., Ph.D. wrote:
Duncan,
I should have included it in my original note, but
all.equal(unclass(t0x), unclass(t1x))
returns TRUE as well. I had tried that as well. But a further look at
all.equal.d
On 05/04/2019 10:19 a.m., Therneau, Terry M., Ph.D. wrote:
Duncan,
I should have included it in my original note, but
all.equal(unclass(t0x), unclass(t1x))
returns TRUE as well. I had tried that as well. But a further look at
all.equal.default shows the following line right near th
Duncan,
I should have included it in my original note, but
all.equal(unclass(t0x), unclass(t1x))
returns TRUE as well. I had tried that as well. But a further look at
all.equal.default
shows the following line right near the top:
if (is.language(target) || is.function(target))
On 05/04/2019 9:03 a.m., Therneau, Terry M., Ph.D. via R-devel wrote:
This arose in testing [.terms and has me confused.
data(esoph) # use a standard data set
t0x <- terms(model.frame( ~ tobgp, data=esoph))
t1 <- terms(model.frame(ncases ~ agegp + tobgp, data=esoph))
t1x <- (delete.response(
As footnote, the error in survival:::untangle.specials is that it assumed that
if
attr(myterms, 'specials')[['strata']] was = to 4, then one could use
myterms[-4] to remove
the strata term. Not so. In the model y ~ x1 + x2 + strata(x3) the
attritube will
be 4 -- the response counts --
This arose in testing [.terms and has me confused.
data(esoph) # use a standard data set
t0x <- terms(model.frame( ~ tobgp, data=esoph))
t1 <- terms(model.frame(ncases ~ agegp + tobgp, data=esoph))
t1x <- (delete.response(t1))[-1]
> all.equal(t0x, t1x)
[1] TRUE
# the above is wrong, because
In addition you can also try to use a PSOCK cluster (see makeCluster,
parLapply) to avoid the problem - it should help if the problem is
somehow related to forking in mclapply().
The problem you are seeing may be in base R, in data.table, or in
interaction between the two (mclapply() from b
On 4 April 2019 at 17:28, ivo welch wrote:
| The following program is whittled down from a much larger program that
| always works on Intel, and always works on AMD's threadripper with
| lapply but not mclappy. With mclapply on AMD, all processes go into
| "suspend" mode and the program then han
The following program is whittled down from a much larger program that
always works on Intel, and always works on AMD's threadripper with
lapply but not mclappy. With mclapply on AMD, all processes go into
"suspend" mode and the program then hangs. This bug is replicable on an
AMD Ryzen Threadrip
Hello!
This is my first post here. I came across the very same problem.
It can be reproduced within modified tests/Embedding/RParseEval.c
Actually this example has another issue, namely it doesn't wrap
everything in R_ToplevelExec . This is a major show stopper for
newcomers as that function is b
Dear Terry,
> Therneau, Terry M , Ph D via R-devel
> on Thu, 4 Apr 2019 22:48:49 -0400 writes:
> Someone sent me a bug report for survival2.44.1-1 that involves a model
with both cluster
> and offset. It turns out to be a 3 part issue with [.terms and my own
untangle.spec
> Ben Bolker
> on Thu, 4 Apr 2019 12:46:37 -0400 writes:
> Proposed patch
Thank you Ben!
[the rest is technical nit-picking .. but hopefully interesting
to the smart R-devel reader base:]
There was a very subtle thinko in your patch which is not easily
diagnosed from R's parse
17 matches
Mail list logo
