Interactive notebook

[Jhsmit]

I needed this for my own stuff so I thought i'd make PR for communism.
This implements interative guesses in jupyter notebooks, only for 1D atm.
Requires Ipywidgets
Not compatible with the contrib module interactive_guess because of the plt.ioff() which gets called on import. (also on just import of jupyter contrib module)

[Jhsmit]

towards #255

[pckroon]

Not bad :)
I think we can deduplicate quite a bit of effort by merging the ipywidget frontend with the matplotlib slider frontend. We'll have to arrive at an API for the main update function that updates all the relevant plots, from there I think we can combine the whole lot fairly easily.
How are you for time to implement this?

[pckroon]

Is this comment still needed? And do I actually need to do the plt.ioff() to make it work in a normal Python script (not notebook)?

[Jhsmit]

Its needed to be commented out for my notebook implementation to work. I'm not sure if you really need it in a normal python file. I can give it a try if I have time.

[Jhsmit]

Yes I agree that merging to an API would be a good idea and would eliminate duplicate code. The reason I've created another contrib module is because it requires ipywidgets and that in turn requires a whole host of other packages (traitlets, ipython.. etc). So if we merge both when a user has only matplotlib and wants to use the normal python file said user will have to install all ipywidgets requirements.

So it might make sense to have 2 modules 1) interactive_guess (current) 2) jupyter where with 1) you only need matplotlib and has the common API and 2) needs ipywidgets and also 1)?

[pckroon]

So it might make sense to have 2 modules 1) interactive_guess (current) 2) jupyter where with 1) you only need matplotlib and has the common API and 2) needs ipywidgets and also 1)?

Exactly what I had in mind. Internally this will mean 1) will get split into two parts, one part dealing with the sliders, and one part dealing exclusively with preparing and updating the matplotlib graphs. It'll require some thought where the split in responsibilities will come exactly: which part decides how many sliders should be made? Their limits? Their labels?

[Jhsmit]

It looks like i'm probably not going to have much time to spend on this in the coming 3 months.

Should the number of sliders not always be equal to the number of (non fixed) parameters?
Then the update function should in both cases be a function that accepts parameters values as kwargs, put evalutates the model, then updates the lines?

What type of visualization do you use for the N dimensional case?

[pckroon]

I'm also super swamped until my thesis is finished.
The number of sliders should (probably) always be the number of parameters. But in N-dimensional cases you can come up with a visualisation strategy where the variables you project out become sliders.

See https://symfit.readthedocs.io/en/stable/examples/ex_interactive_guesses_nD.html for the visualization I use now.

[tBuLi]

With regards to visualizing higher dimensional data, perhaps we should look into t-SNE. It seems this is popular in machine learning for visualizing higher dimensional data so it could be what we need: https://scikit-learn.org/stable/auto_examples/manifold/plot_t_sne_perplexity.html#sphx-glr-auto-examples-manifold-plot-t-sne-perplexity-py

[Jhsmit]

looks interesting. I found some cool animations: https://distill.pub/2016/misread-tsne/

[lesshaste]

I understand https://umap-learn.readthedocs.io/en/latest/ is regarded as much better than tsne these days.

[tBuLi]

@lesshaste, that also looks very interesting, thanks for the suggestion! I do think one of these techniques could solve the problem for doing higher dimensional interactive guesses, by playing a game of making the point cloud of the initial guess overlap as much as possible with that of the data before fitting. I don't know it that is guaranteed to be a good initial guess, or that there is still no uniqueness in the output of these algorithms?