similar to: Duplicate column names created by base::merge() when by.x has the same name as a column in y

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

Hi Scott, Thanks for the patch. I'm not really involved in R development; it will be up to someone in the R core team to apply it. I would hazard to say that even if correct (I haven't checked), it will not be applied because the change might break existing code. For example it seems like reasonable code might easily assume that a column with the same name as "by.x" exists in

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 potentially may break downstream packages (i.e. any cases where this occurs but they expect the name of the key column(s) to remain the same). Best, Scott On

Thanks Gabriel, I think your suggested approach is 100% backwards compatible Currently in the case of duplicate column names only the first can be indexed by its name. This will always be the column appearing in by.x, meaning the column in y with the same name cannot be accessed. Appending ".y" (suffixes[2L]) to this column means it can now be accessed, while keeping the current

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) +++ src/library/base/R/merge.R (working copy) @@ -157,6 +157,14 @@ }

>>>>> Gabriel Becker <gmbecker at ucdavis.edu> >>>>> on Wed, 21 Feb 2018 07:11:44 -0800 writes: > Hi all, > For the record this approach isnt 100% backwards compatible, because > names(mergeddf) will e incompatibly different. Thatx why i claimed > bakcwards compatable-ish exactly. > That said its still worth considering

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

Hi Scott, It seems like reasonable behavior to me. What result would you expect? That the second "name" should be called "name.y"? The "merge" documentation says: If the columns in the data frames not used in merging have any common names, these have ?suffixes? (?".x"? and ?".y"? by default) appended to try to make the names of the

On 17/02/2018 6:36 PM, frederik at ofb.net wrote: > Hi Scott, > > Thanks for the patch. I'm not really involved in R development; it > will be up to someone in the R core team to apply it. I would hazard > to say that even if correct (I haven't checked), it will not be > applied because the change might break existing code. For example it > seems like reasonable code

It seems like there is a way that is backwards compatible-ish in the sense mentioned and still has the (arguably, but a good argument I think) better behavior: if by.x is 'name', (AND by.y is not also 'name'), then x's 'name' column is called name and y's 'name' column (not used int he merge) is changed to name.y. Now of course this would still change

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 suggested approach is 100% backwards compatible > > Currently in the case of

Hi all, For the record this approach isnt 100% backwards compatible, because names(mergeddf) will e incompatibly different. Thatx why i claimed bakcwards compatable-ish That said its still worth considering imho because of the reasons stated (and honestly one particular simple reading of the docs might suggest that this was thr intended behavior all along). Im not a member of Rcore through so i

Thanks Martin! Can you clarify the functionality of the 'no.dups' argument so I can change my patch to `data.table:::merge.data.table` accordingly? - When `no.dups=TRUE` will the suffix to the by.x column name? Or will it take the functionality of the second functionality where only the column in y has the suffix added? - When `no.dups=FALSE` will the output be the same as it currently

LLVM3.8 version. https://bugs.llvm.org//show_bug.cgi?id=24233. The example can catch exception. But I use my own code for testing, CustomEHMemoryManager allocated memory address is very large, allocateCodeSection, allocateDataSection assigned address (more than 32 bit address space) is getting smaller and smaller. Cause registerEHFrames to fail. 3.9.1 or 4.0.0 version has been supported on win

dear all I got this error when I try to use libspeex in visual studio. when I include speex/speex_echo.h, it complains about unresolved external symbol _speex_echo_state_init. And when I include mdf.c into the source, it generates whole bunch of errors. Any idea? thanks so much --------------------Configuration: audio - Win32 Debug-------------------- Compiling... mdf.c C:\Documents and

To all: hi, i have implemented the associations in my models so i have a Parent model that has many Children model but i need to get a list of Parents that do not have children or Parents that have just 2 children or Parents that have children whose name is ''James'', or ''Sarah'', or ''Betty'' or Parents whose children do not have names like

Hi Mats, I think Kevin's point is malloc can return 0, if malloc/free pair is optimized way, the semantic of the original would be changed. On the other hand, malloc/free are special functions, but programmers can still define their own versions by not linking std library, so we must assume malloc/free always have side-effect like other common functions, unless we know we will link std

Hi.... I have one text file which containing 4 variables with 10 observations. I would like to import with scan() function. Please give some suggestion............ Thanks... Mydata set is. id name sex age 111 HELEN f 22 112 DONNA f 22 113 ERIC m 21 114 LINDA f 23 115 AXEL m 27 116 Madhuri f 32 117 Tarun m 39 118 Aashirya f 23 119 Nachik m 24 120 Leena f 32 -- View this message in context:

Hi David and Mats, Thanks for your explanation. If my understanding is correct, it means we don't need to consider the side-effect of malloc/free unless compiling with -ffreestanding. Because without -ffreestanding, user defined malloc/free should be compatible with std library. It makes sense to me. My point is, in std library, malloc is allowed to return null if this malloc failed. Why

For help: Llvm generated instruction calls a function (extern), the function will have a SEH exception (EXCEPTION_ACCESS_VIOLATION), But JIT can not capture the exception of the EXCEPTION_ACCESS_VIOLATION. I saw Bug 24233. EXCEPTION_ACCESS_VIOLATION exception cannot be captured after modification. How to catch EXCEPTION_ACCESS_VIOLATION exceptions on win64 ? haifeng.qin at wellintech.com