Hi Scott,
I tried the new patch and can confirm that it has the advertised
behavior on a couple of test cases. I think it makes sense to apply
it, because any existing code which refers to a second duplicate
data.frame column by name is already broken, while if the reference is
by numerical index
Dear all,
Sorry if I am posting to the wrong place, but I could not find the link for
registration on the bug tracker, that’s why I am writing here.
I think there is inconsistency between two R functions from the stats
package, bw.nrd0 and bw.nrd.
Consider the following vector:
D <- c(0, 1, 1, 1
Hi Frederick,
It looks like I didn't overwrite the patch.diff file after the last edits.
Here's the correct patch (attached and copied below):
Index: src/library/base/R/merge.R
===
--- src/library/base/R/merge.R (revision 74280)
+++
Hi Scott,
I think that's a good idea and I tried your patch on my copy of the
repository. But it looks to me like the recent patch is identical to
the previous one, can you confirm this?
Frederick
On Mon, Feb 19, 2018 at 07:19:32AM +1100, Scott Ritchie wrote:
> Thanks Gabriel,
>
> I think your
Hi all,
Not sure if this belongs to R-devel or R-package-devel. Anyways...
Suppose we have objects of class c("foo", "bar"), and there are two S3
methods c.foo, c.bar. In c.foo, I'm trying to modify the dots and
forward the dispatch using NextMethod without any success. This is
what I've tried so
Thanks! Cleaned up in R-devel,
Tomas
On 02/16/2018 05:03 PM, S Ellison wrote:
A discussion on r-help led me to look at stem.c at
https://github.com/wch/r-source/blob/trunk/src/library/graphics/src/stem.c
Lines 76-77 appear superfluous. They sit inside a condition, and set mu, as
follows:
Dear Henrik,
The rationale is just that it is within these extremes and that it is really
simple to calculate, without making any assumptions and knowing that it won't
be perfect.
The extremes A and B you are mentioning are special cases based on assumptions.
Case A is based on the assumption