JEFworks
commented
8 years ago Hi Jens,
If you look at the code for pagoda.reduce.loading.redundancy, you can see how the colors for the row cluster colors are determined. I've commented the relevant aspects of the code for you below:
# the number of clusters is determined by the user-provided distance threshold
ct <- cutree(y, h = distance.threshold)
ctf <- factor(ct, levels = sort(unique(ct)))
# convert from cluster factor to colors
sc <- sample(colors(), length(levels(ctf)), replace = TRUE)
view.aspects(tam$xv, row.clustering = y, row.cols = sc[as.integer(ctf)], ...)If you would like to use RColorBrewer colors, I think the easiest way would be to make a fork and change this code. Similarly, if you would like to return the row-dendrogram y, you can modify the code to return return(list('tam'=tam, 'rowhc'=y)) instead of just return(tam).
Best, Jean
jenzopr
Hi Jean and Peter,
I would like to see the clustered aspects of pagoda.reduce.loading.redundancy() in custom colors (from RColorBrewer). Unfortunately, pagoda.reduce.loading.redundancy doesn't know in advance how many clusters will be created, so I tried plotting the tamr-object with pagoda.view.aspects afterwards. I was able to use the row.cols argument with custom colors, since the number of colors needed equals the number of clusters, which is length(tamr$cname). Nevertheless, the clustering itself is missing, or only available inside pagoda.reduce.loading.redundancy(). See below for the original plot of the pagoda.reduce.loading.redundancy()-call
and my pagoda.view.aspects call with custom colors:
The easiest way is to make the clustering available through a new item returned by pagoda.reduce.loading.redundancy? Or am I missing something else? Please let me know what you think.
Best, Jens