apply-like output for alply (addresses #102) #103

merged 3 commits into from Oct 18, 2012


None yet

2 participants


Here's a possible way to address #102, by letting alply optionally put dims onto its output (covering the behavior that was removed from aaply.) Comments/discussion welcome.

hadley commented Oct 15, 2012

Does this even need to be an option?


Not sure. I can imagine ways it would change behavior downstream when you hand the result of alply to other things, but haven't found any examples in use.

hadley commented Oct 17, 2012

I don't think it should - if using 1d indexing, it'll return the same results as before.

@hadley hadley and 1 other commented on an outdated diff Oct 17, 2012
.progress = .progress, .inform = .inform,
.parallel = .parallel, .paropts = .paropts)
+ if (.dims) {
+ labels <- attr(pieces, "split_labels")
+ res_labels <- lapply(labels,
+ function(x) if(is.factor(x)) levels(x) else sort(unique(x)))
hadley Oct 17, 2012 owner

This seems a little suspicious - will the ordering always be correct?

crowding Oct 18, 2012

That came from the old aaply code -- splitter_a seems to construct factors with levels in order of appearance, so it works, but I agree just an as.character(unique(x)) would do the same more clearly.


Made it non-optional, and strengthened the test. In the case of splitting a data frame on margin 1, splitter_a gives one column per input column instead of one per margin, so it's not clear how to make dimnames, so there's a guard against that.

There was a test failure under "empty arrays returns object of same shape" but the dimnames behavior there seemed right to me so I changed the test to is_equivalent_to.

@hadley hadley merged commit a1a7277 into hadley:master Oct 18, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment