search for: ritchie73

...attached patch.diff will make merge.data.frame() append the suffixes >>> to >>> columns with common names between by.x and names(y). >>> >>> Best, >>> >>> Scott Ritchie >>> >>> On 17 February 2018 at 11:15, Scott Ritchie <s.ritchie73 at gmail.com> >>> wrote: >>> >>> Hi Frederick, >>>> >>>> I would expect that any duplicate names in the resulting data.frame >>>> would >>>> have the suffixes appended to them, regardless of whether or not they >>&g...

....y. > > Now of course this would still change output, but it would change it to > something I think would be better, while retaining the 'merge columns > retain their exact names' mechanic as documented. > > ~G > > On Sat, Feb 17, 2018 at 6:50 PM, Scott Ritchie <s.ritchie73 at gmail.com> > wrote: > >> Thanks Duncan and Frederick, >> >> I suspected as much - there doesn't appear to be any reason why conflicts >> between by.x and names(y) shouldn't and cannot be checked, but I can see >> how this might be more trouble than...

...but it would change it to > > > something I think would be better, while retaining the 'merge columns > > > retain their exact names' mechanic as documented. > > > > > > ~G > > > > > > On Sat, Feb 17, 2018 at 6:50 PM, Scott Ritchie <s.ritchie73 at gmail.com> > > > wrote: > > > > > >> Thanks Duncan and Frederick, > > >> > > >> I suspected as much - there doesn't appear to be any reason why > conflicts > > >> between by.x and names(y) shouldn't and cannot be che...

...taining the 'merge > columns >> > > > retain their exact names' mechanic as documented. >> > > > >> > > > ~G >> > > > >> > > > On Sat, Feb 17, 2018 at 6:50 PM, Scott Ritchie < > s.ritchie73 at gmail.com> >> > > > wrote: >> > > > >> > > >> Thanks Duncan and Frederick, >> > > >> >> > > >> I suspected as much - there doesn't appear to be any reason why >> > conflict...

...used int he merge) is changed to name.y. Now of course this would still change output, but it would change it to something I think would be better, while retaining the 'merge columns retain their exact names' mechanic as documented. ~G On Sat, Feb 17, 2018 at 6:50 PM, Scott Ritchie <s.ritchie73 at gmail.com> wrote: > Thanks Duncan and Frederick, > > I suspected as much - there doesn't appear to be any reason why conflicts > between by.x and names(y) shouldn't and cannot be checked, but I can see > how this might be more trouble than its worth given it potentiall...

...t, Feb 17, 2018 at 04:42:21PM +1100, Scott Ritchie wrote: > The attached patch.diff will make merge.data.frame() append the suffixes to > columns with common names between by.x and names(y). > > Best, > > Scott Ritchie > > On 17 February 2018 at 11:15, Scott Ritchie <s.ritchie73 at gmail.com> wrote: > > > Hi Frederick, > > > > I would expect that any duplicate names in the resulting data.frame would > > have the suffixes appended to them, regardless of whether or not they are > > used as the join key. So in my example I would expect &qu...

...is would still change output, but it would change it to > > something I think would be better, while retaining the 'merge columns > > retain their exact names' mechanic as documented. > > > > ~G > > > > On Sat, Feb 17, 2018 at 6:50 PM, Scott Ritchie <s.ritchie73 at gmail.com> > > wrote: > > > >> Thanks Duncan and Frederick, > >> > >> I suspected as much - there doesn't appear to be any reason why conflicts > >> between by.x and names(y) shouldn't and cannot be checked, but I can see > >> h...

Hi Frederick, I would expect that any duplicate names in the resulting data.frame would have the suffixes appended to them, regardless of whether or not they are used as the join key. So in my example I would expect "names.x" and "names.y" to indicate their source data.frame. While careful reading of the documentation reveals this is not the case, I would argue the intent of

...> > > something I think would be better, while retaining the 'merge columns > > > > retain their exact names' mechanic as documented. > > > > > > > > ~G > > > > > > > > On Sat, Feb 17, 2018 at 6:50 PM, Scott Ritchie < s.ritchie73 at gmail.com> > > > > wrote: > > > > > > > >> Thanks Duncan and Frederick, > > > >> > > > >> I suspected as much - there doesn't appear to be any reason why > > conflicts > > > >> between by.x and names...

The attached patch.diff will make merge.data.frame() append the suffixes to columns with common names between by.x and names(y). Best, Scott Ritchie On 17 February 2018 at 11:15, Scott Ritchie <s.ritchie73 at gmail.com> wrote: > Hi Frederick, > > I would expect that any duplicate names in the resulting data.frame would > have the suffixes appended to them, regardless of whether or not they are > used as the join key. So in my example I would expect "names.x" and > &quo...

...; columns > >> > > > retain their exact names' mechanic as documented. > >> > > > > >> > > > ~G > >> > > > > >> > > > On Sat, Feb 17, 2018 at 6:50 PM, Scott Ritchie < > > s.ritchie73 at gmail.com> > >> > > > wrote: > >> > > > > >> > > >> Thanks Duncan and Frederick, > >> > > >> > >> > > >> I suspected as much - there doesn't appear to be any reason >...

...+1100, Scott Ritchie wrote: >> The attached patch.diff will make merge.data.frame() append the suffixes to >> columns with common names between by.x and names(y). >> >> Best, >> >> Scott Ritchie >> >> On 17 February 2018 at 11:15, Scott Ritchie <s.ritchie73 at gmail.com> wrote: >> >>> Hi Frederick, >>> >>> I would expect that any duplicate names in the resulting data.frame would >>> have the suffixes appended to them, regardless of whether or not they are >>> used as the join key. So in my example...

Hi, I was unable to find a bug report for this with a cursory search, but would like clarification if this is intended or unavoidable behaviour: ```{r} # Create example data.frames parents <- data.frame(name=c("Sarah", "Max", "Qin", "Lex"), sex=c("F", "M", "F", "M"),