New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ENH: add Alignment.heatmap method #816
Conversation
Also fig_size defaults to None, and so does cmap.
The docstring entries about the X and Y axis labels are likely in the wrong place.
…into aln-heatmap
…additions Took a pass through the code and unit tests, cleaning up the implementation a bit and improving error messages. Also refactored some of the code for easier testing of individual pieces, which uncovered a few bugs: - every value in `value_map` was being used to compute min/median/max for the legend, and default values (if `value_map` was a defaultdict) were ignored - plotting an empty alignment resulted in a cryptic error - plotting an alignment with a single sequence produced the wrong y-axis labels Fixes scikit-bio#765.
``KeyErrors`` are not caught, so all possible values should be in | ||
`value_map`, or it should be a ``collections.defaultdict`` which | ||
can, for example, default to ``nan``. | ||
legend_labels : iterable, optional |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gregcaporaso does the behavior described for legend_labels
make sense?
In your original cookbook implementation, all of the values in value_map
were used to compute the minimum, median, and maximum. This could produce strange behavior if a value in value_map
wasn't used in the heatmap. For example, if value_map
had an unused mapping to a maximum value, the "maximum" label wouldn't show up in the legend because a different (smaller) maximum value was used in the heatmap/colorbar.
Also, if a defaultdict
was supplied, mappings using the default value weren't being considered when computing min/median/max. For example, suppose the defaultdict
had a default value that happened to be the true maximum, the "maximum" label would be placed in the wrong spot.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jairideout, that makes sense and I see that it has to be that way now that you bring it up. But, I wonder if we should include the values in the legend label as well in this case. So, next to the label for the minimum, you'd always include the min value in parenthesis, and same for mean and max. Otherwise it could be misleading if your labels were *hydrophilic", "medium", and "hydrophobic", and then there were no "hydrophobic" residues in the alignment (I know, very unlikely, but just working from the cookbook example).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good idea, I'll add that in. Since these labels are pretty specialized, I think a better default is to not include these labels on the legend at all (i.e., legend_labels=None
). If someone wants to mark the min/median/max, then they have the option to, but then we're not forcing users to label the legend this way. Does that make sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, good idea.
@gregcaporaso @ebolyen this is ready for review -- tests are passing now and I manually verified that coverage is at 100% for the code I added (coveralls isn't rerunning for some reason). |
Conflicts: CHANGELOG.md
@jairideout Merge conflict. |
Conflicts: CHANGELOG.md skbio/alignment/_alignment.py skbio/alignment/tests/test_alignment.py
Fixed, thanks! |
Looks good, thanks @jairideout! I just added one suggestion based on your question - if that doesn't make sense we can discuss tomorrow. |
See here for choices: | ||
http://matplotlib.org/examples/color/colormaps_reference.html | ||
If ``None``, defaults to the colormap specified in the user's | ||
matplotlibrc file. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the default if it's not specified in the user's matplotlibrc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With any luck, we'll have a better default in the future as mpl is discussing a change to the default color map (matplotlib/matplotlib#875). Anyone want to weigh in on that discussion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will fall back to whatever matplotlib's default is (there is always a "base" config file included in a matplotlib install, similar to how QIIME config files work). I don't think listing this here is appropriate because matplotlib's defaults may change and we won't want to update these docs when that happens.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, agree.
Thanks for reviewing @gregcaporaso! I had another question (see inline). In the meantime I'll work on the change you suggested. |
@gregcaporaso I made the changes we discussed. Can you and @ebolyen review? |
def test_heatmap_invalid_sequence_order(self): | ||
# duplicate ids | ||
with self.assertRaises(ValueError): | ||
self.a1.heatmap({}, sequence_order=['d1', 'd2', 'd1']) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you assert some basic verbs in the error message exist to ensure that the correct error is being raised?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent idea!
This pull request includes @Kleptobismol's commits in #779. I added a few commits with documentation updates, a few bug fixes, some refactoring, and more unit tests.
Fixes #765.
@gregcaporaso @ebolyen can you please review? @gregcaporaso I'll follow up with a comment on a specific part of the code that I'd like your feedback on.