Repository navigation
showClusterHeatmap(cluster_custom_order =); accept any expression name - #154
Merged
Merged
Conversation
Correlations are still computed from the data shown, defaulting to the cells and features the tree was built on. expression_values accepts any expression name.
A tree would only set the layout here while the colours are recomputed, so its branches could describe different data than the plot. An order arranges without claiming structure.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
showClusterHeatmap()gainscluster_custom_order, to lay the clusters out in a given order on both axes, for example a cluster tree's leaf order:When given, the clusters are not clustered and no dendrogram is drawn. The order only arranges the clusters, so the plot shows the correlations without claiming a structure. The correlations are computed from the data shown, as before.
Why an order, not a tree
An earlier version of this PR took
tree =and drew its branches. In every other tree consumer, the tree drives the operation: it defines the comparisons infindClusterTreeMarkers()and the groups inannotateClusterTree(). Here it would only have set the layout while the colors were recomputed. Its branches could then describe different data than the plot, with a warning in the best case and silently in the worst: a re-clustered object with the same label set passes every check. An order makes no such claim. A plot of a tree's own correlation matrix belongs with the tree itself (a possibleplot(tree, what = "heatmap")from its recorded matrix), not with a function that recomputes from the object.The name follows
plotHeatmap()anddotPlot()(cluster_custom_order), notplotMetaDataHeatmap()'scustom_cluster_order. Aligning those names is part of the heatmap consolidation, to be filed as a separate issue.Also
expression_valuesaccepts any expression name. It used to reject anything other than"normalized"/"scaled"/"custom", such as"raw". The validation now matches Giotto's.@returnsnow says it returns aComplexHeatmapHeatmapobject. It previously said ggplot.cluster_custom_ordermust name every cluster shown, exactly once. Otherwise the error lists what's missing or not in the data.Verification
New
test-cluster-heatmap-order.R:The tests don't need Giotto. All 45 tests pass (100 expectations).
🤖 Generated with Claude Code