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
bhmm/bhmm#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
bhmm/bhmm#27 (comment).

---

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
bhmm/bhmm#27 (comment).

---

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
bhmm/bhmm#27 (comment).

---

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