Plotlyviz

[empet]

Hi @sauln and @MLWave,

Here is my new PR on including Plotly visualization for kmapper graphs.

• I defined the file plotlyviz.py, that only makes a few imports from visuals, and did not perform any change in the original kmapper files.

• In the folder examples I included a Jupyter notebook for makecircles, cat, digits, and breast-cancer, as well as a pdf file for the Plotly figure representing the corresponding dataset.
  At the first inspection it is recommended to read the notebooks in the order given above, because each one illustrates more plotting capabilities, compared with the previous.

• A notebook Plotly-colorscale.ipynb explains how we can convert matplotlib colormaps to Plotly colorscales, to color the graph nodes and the bars of histograms illustrating node distribution.

• In README.md are inserted details on how to install plotly, ipywidgets, and python-igraph.

[codecov-io]

Codecov Report

Merging #113 into master will decrease coverage by 15.96%.
The diff coverage is 54.16%.

@@             Coverage Diff             @@
##           master     #113       +/-   ##
===========================================
- Coverage   90.76%   74.79%   -15.97%     
===========================================
  Files           6        7        +1     
  Lines         433      619      +186     
  Branches       93      130       +37     
===========================================
+ Hits          393      463       +70     
- Misses         27      133      +106     
- Partials       13       23       +10

Impacted Files	Coverage Δ
kmapper/jupyter.py	0% <ø> (ø)	⬆️
kmapper/__init__.py	100% <100%> (ø)	⬆️
kmapper/nerve.py	86.36% <100%> (ø)	⬆️
kmapper/plotlyviz.py	27.46% <27.46%> (ø)
kmapper/visuals.py	89.03% <81.08%> (-7.4%)	⬇️
kmapper/cover.py	96.07% <83.33%> (ø)	⬆️
kmapper/kmapper.py	89.45% <94.11%> (+0.04%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4073607...f70b161. Read the comment docs.

[sauln]

I think this all looks really good. I'm going to put a little bit of work to polish it up and integrate it nicely. Below are a few lists of tasks I've done, tasks I'd like done, and tasks we should talk about.

things I've changed

• Squashed all the commits with commit message 'first commit' into a single commit so this is easier to look at.
• Applied black to the new plotlyviz.py and to all the older code as well.
• Cleared widget state from the notebooks so the notebooks don't take >10k lines. I've never used widgets and so I'm not sure why this state is kept around. What purpose does it serve?
• Trying to make clear that there are a few different sets of requirements depending on what you want to do. I'd prefer for plotly to not be a default requirement, but if you want to use plotly, then install it.
• merged format_meta and pl_format_meta

things I'd like to change before merging:

• Include plotly examples in sphinx documentation.
• Increase tests. testing visuals is hard, but the manipulation functions should be easier to test. I've started this effort, but more tests are needed.
• make nodes opaque so you can't see the edges through the node.
• Fix Flexible options for color palette. #112 along with this and
• put the color palettes in just one place of the code.
• For color functions, instead of taking mean color, choose max instead (mean can change interpretation of categorical variables.)
• Add some more narrative to the notebooks (comments can become markdown and cells can be smaller.
• re: plotly-colorscales notebook. Can we just roll that function into the plotly constructors and then have users supply a matplotlib colormap?
• I really like how the color schemes are handled (_map_val2color) and would like to use this as the default mechanism in the normal color handling.

concerns that might warrant changes

• The histogram makes 10 bins when the color scale is defined with 11 entries. The color scale defines lower and upper bounds of each bin. This could get confusing if you want to have categorical data and use colors based on the number of categories. Can we devise a color scale convention that would be useful for both continuous and categorical colorings?

[sauln]

Hi @empet,

Apologies for the delay. Would you mind taking a look at the most recent changes I've made to the notebooks and code? I think everything is working okay. I added a function that wraps most of the code built up in the notebooks so that for users who aren't as familiar with plotly can build the visuals with just one function being called.

Let me know if it's okay, or please suggest changes.

Thank you,
Nathaniel

[empet]

Hi @sauln,
The Plotly-demo is absolutely great. Nice work!!!

[sauln]

Hey @empet! Thanks for all the work you put into making these visualizations. I am very excited to incorporate these. Sorry I have been moving slowly on this, but I think we're all ready to incorporate.

Thank you again! 🍾

[deargle]

@empet I am reworking kmapper.py and visuals.py to decouple them from jinja and to refactor the color value calculation to be more customizable. In doing so, I noticed that plotlyviz.py reimplements portions of visuals.py and kmapper.py. Is this because jinja and html are tied into both kmapper.py and visuals.py? If so, once jinja is decoupled, I suspect that plotlyviz.py could be refactored to cut out a lot of duplicated code and logic, to make maintenance easier. WIth my refactor, visuals.py does all preparatory work separate from any html rendering.

[deargle]

Specifically was looking at get_mapper_graph and the functions that it calls, such as scomplex_to_graph