melt.data.table overwrites factor labels/names depending on number of inputs

[enfascination]

melt() overwrites the values of the variable.name column when measure.vars is given multiple arguments.

> ?patterns
> names(dt)
[1] "x1" "x2" "y1" "y2"
> levels(melt(dt, measure.vars = patterns("^x"))$variable)
[1] "x1" "x2"
> levels(melt(dt, measure.vars = patterns("^x", "^y"))$variable)
[1] "1" "2"

In both examples, the values of variable should be x1 and x2. It also happens when factors are disabled and when patterns() is circumvented

> unique(melt(dt, measure.vars = patterns("^x"), variable.factor=F)$variable)
[1] "x1" "x2"
> unique(melt(dt, measure.vars = patterns("^x", "^y"), variable.factor=F)$variable)
[1] "1" "2"
> levels(melt(dt, measure.vars = list(grep("^x", names(dt))))$variable)
[1] "x1" "x2"
> levels(melt(dt, measure.vars = list(grep("^x", names(dt)), grep("^y", names(dt))))$variable)
[1] "1" "2"

FYI,

> sessionInfo()
R version 3.3.0 (2016-05-03)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: OS X 10.10.5 (Yosemite)
...
data.table_1.9.6

[franknarf1]

It's not clear to me why you think the levels should be x1 x2 in the latter case...

Fwiw, there's a related discussion under #1547

[enfascination]

@franknarf1 , the levels could come out x1 and x2 (as in hadley's version of melt), or 1 and 2, but whatever they become, it shouldn't change depending on the number of arguments to measure.vars, that's inconsistent.

You're right about #1547 , that code has the problem I am describing (though it seems to be about a bit more, and it makes me see how flexible patterns really is). It also has what looks like a PR from @jangorecki that fixes the issue.

[jangorecki]

@enfascination no it didn't, it was workaround, AFAIR better solution was proposed in that issue

[MichaelChirico]

Not clear if there's anything outstanding here since there's no example to test. @enfascination please feel feel free to re-open with a reproducible example if there's still something wrong w the behavior.