examples/plots.py

[jchodera]

Why is plots.py in examples/?

[franknoe]

Because that is very example-specific and the only module that has the seaborn + matplotlib dependencies. It's really not a part of BHMM unless we decide to make a general plotting package.

Am 17/05/15 um 20:49 schrieb John Chodera:

Why is |plots.py| in |examples/|?

— Reply to this email directly or view it on GitHub https://github.com/bhmm/bhmm/issues/27.

---

Prof. Dr. Frank Noe Head of Computational Molecular Biology group Freie Universitaet Berlin

Phone: (+49) (0)30 838 75354 Web: research.franknoe.de

Mail: Arnimallee 6, 14195 Berlin, Germany

[jchodera]

I think it's important that users have a way to visualize their results. Most users will presumably want to do this, and it's critical to run the examples.

If these packages are automatically installed without hassle, it isn't overly burdensome to automatically install these dependencies. On the other hand, we have to do careful trapping of import exceptions and give the user very clear instructions about how to install the dependencies (possibly using multiple package managers) if we don't include these as dependencies.

[franknoe]

But I guess people are not going to get the examples when they install bhmm through conda? So they are not part of the python package, or are they?

For github users, we can careful import seaborn and raise a warning if it isn't there. I'll make this to an issue and take care of it.

I am very much for adding a useful plotting package to the library (we do that in Emma too), but at the moment these plotting tools are far from being generally usable, and therefore I don't see a reason why installing bhmm should depend on them.

Am 17/05/15 um 21:14 schrieb John Chodera:

I think it's important that users have a way to visualize their results. Most users will presumably want to do this, and it's critical to run the examples.

If these packages are automatically installed without hassle, it isn't overly burdensome to automatically install these dependencies. On the other hand, we have to do careful trapping of import exceptions and give the user very clear instructions about how to install the dependencies (possibly using multiple package managers) if we don't include these as dependencies.

— Reply to this email directly or view it on GitHub https://github.com/bhmm/bhmm/issues/27#issuecomment-102837029.

---

Prof. Dr. Frank Noe Head of Computational Molecular Biology group Freie Universitaet Berlin

Phone: (+49) (0)30 838 75354 Web: research.franknoe.de

Mail: Arnimallee 6, 14195 Berlin, Germany

[jchodera]

But I guess people are not going to get the examples when they install bhmm through conda? So they are not part of the python package, or are they?

They're definitely going to get the examples! The examples are installed into ~/anaconda/share/bhmm/examples/.

[jchodera]

We should add the plotting tools back to the package. At worst, we can use lazy imports. But we should certainly not use this:

# dynamically import plotting tools                                                                                                                                                            
import os,sys,inspect                                                                                                                                                                          
currentdir = os.path.dirname(os.path.abspath(inspect.getfile(inspect.currentframe())))                                                                                                         
parentdir = os.path.dirname(currentdir)                                                                                                                                                        
sys.path.insert(0,parentdir)                                                                                                                                                                   
import plots                                                                                                                                                                                   

If the concern is that you want to use the general BHMM core of this package in pyemma as well, we should simply factor that general model-fitting core into another package and import it from a single molecule spectroscopy package. But we shouldn't do crazy things like this here.

If we do refactor it, have you considered making this compatible with the scikit-learn toolkit? This seems to be the modern way to build machine learning tools now. @kyleabeauchamp has lots of experience with this.

[franknoe]

I do like the idea of separating the bhmm core from application packages. In fact this is what I had in mind for the FRET package as well.

I am not happy to include heavy dependencies for special purpose functionalities that have not general use (yet). If we do that than every package using bhmm will inherit the same dependencies.

sklearn: by "compatible" you probably mean that estimator classes should have a certain API? What would that mean in our case, and would we need an sklearn dependency for this (we currently have one for the Gaussian mixture model estimation, but I though this of being a temporary solution).

Am 18/05/15 um 01:53 schrieb John Chodera:

We should add the plotting tools back to the package. At worst, we can use lazy imports. But we should certainly /not/ use this:

# dynamically import plotting tools import os,sys,inspect currentdir = os.path.dirname(os.path.abspath(inspect.getfile(inspect.currentframe()))) parentdir = os.path.dirname(currentdir) sys.path.insert(0,parentdir) import plots

If the concern is that you want to use the general BHMM core of this package in pyemma as well, we should simply factor that general model-fitting core into another package and import it from a single molecule spectroscopy package. But we shouldn't do crazy things like this here.

If we do refactor it, have you considered making this compatible with the scikit-learn http://scikit-learn.org/ toolkit? This seems to be the modern way to build machine learning tools now. @kyleabeauchamp https://github.com/kyleabeauchamp has lots of experience with this.

— Reply to this email directly or view it on GitHub https://github.com/bhmm/bhmm/issues/27#issuecomment-102871349.

---

Prof. Dr. Frank Noe Head of Computational Molecular Biology group Freie Universitaet Berlin

Phone: (+49) (0)30 838 75354 Web: research.franknoe.de

Mail: Arnimallee 6, 14195 Berlin, Germany

[jchodera]

I am not happy to include heavy dependencies for special purpose functionalities that have not general use (yet). If we do that than every package using bhmm will inherit the same dependencies.

Then we have to either break the BHMM model core into a separate package or split out the force spectroscopy analysis stuff into another package. We can't have a tool that is supposed to be user-friendly to experimentalists that requires they also install a bunch of stuff separately to even make a figure---that's trying to cram too many incompatible goals into one package.

What if we create a new bhmm/bhmm-force-spectroscopy repo to hold all the force spectroscopy stuff? The general core of the Bayesian analysis framework can remain in bhmm/bhmm.

sklearn: by "compatible" you probably mean that estimator classes should have a certain API?

Yes, though it looks like the standard HMM functionality is being removed from scikit-learn: http://scikit-learn.org/stable/modules/hmm.html

What would that mean in our case, and would we need an sklearn dependency for this (we currently have one for the Gaussian mixture model estimation, but I though this of being a temporary solution).

Yeah, it would mean using sklearn as a dependency, but also being interoperable with the sklearn scheme of fitting models. The advantage is that this could mean we could easily use it in msmbuilder3 as well as pyemma.

[franknoe]

Am 18/05/15 um 05:48 schrieb John Chodera:

I am not happy to include heavy dependencies for special purpose
functionalities that have not general use (yet). If we do that
than every package using bhmm will inherit the same dependencies.

Then we /have/ to either break the BHMM model core into a separate package or split out the force spectroscopy analysis stuff into another package.

OK, that's fine.

We can't have a tool that is supposed to be user-friendly to experimentalists that requires they also install a bunch of stuff separately to even make a figure---that's trying to cram too many incompatible goals into one package.

What if we create a new |bhmm/bhmm-force-spectroscopy| repo to hold all the force spectroscopy stuff? The general core of the Bayesian analysis framework can remain in |bhmm/bhmm|.

sklearn: by "compatible" you probably mean that estimator classes
should have a certain API?

Yes, though it looks like the standard HMM functionality is being removed from |scikit-learn|: http://scikit-learn.org/stable/modules/hmm.html

What would that mean in our case, and would we need an sklearn
dependency for this (we currently have one for the Gaussian
mixture model estimation, but I though this of being a temporary
solution).

Yeah, it would mean using |sklearn| as a dependency, but also being interoperable with the sklearn scheme of fitting models. The advantage is that this could mean we could easily use it in |msmbuilder3| http://msmbuilder.org/ as well as |pyemma|.

It's not really clear to me. Given that the HMM module will be removed from sklearn, is then there still something to do? What is the sklearn scheme of fitting models?

— Reply to this email directly or view it on GitHub https://github.com/bhmm/bhmm/issues/27#issuecomment-102914909.

---

Prof. Dr. Frank Noe Head of Computational Molecular Biology group Freie Universitaet Berlin

Phone: (+49) (0)30 838 75354 Web: research.franknoe.de

Mail: Arnimallee 6, 14195 Berlin, Germany