hhuuggoo

I wanted to point out one important distinction between Bokeh and anything that's currently out there - we have a full blow python/js object bridge that synchronizes client side models with objects you can interact with in python. The significance of this, is that someone can select points on a scatter plot, and then you can retrieve the indexes of those points on the python side, and use that to further dive into your data.

It's worth mentioning that the IPython guys are implementing a similar json/python bridge to support the new interactive tools in the IPython notebook. Once that is up and running, we'll probably just piggy back off of that bridge, when you're running in the notebook.

Well, we'll be able to do that without sending the data to the client, not sure if our implementation right now will work without loading the data into memory, though long term that is definitely the plan (we will leverage http://blaze.pydata.org/)

If you want to discuss further, please email [email protected]

This doesn't directly answer your question, but in regards to seaborn, our goal is to support enough of the mpl API so we can get seaborn to work with bokeh. Either that or we would write our own ggplot interface. Which ever approach ends up being easier

January - but probably only support for abstract rendering for scatter plots and line plots. we'll have to roll it out incrementally, but the good thing is 90% of plots are scatters and lines =)

Part of the 0.4 release is to incorporate the concept of abstract rendering - which means you render on the server, and then send the necessary information over to the client on demand. For example, if someone tries to scatter a billion points, instead of just drawing a useless point cloud, you would figure out where all the points fit inside your 512x512 canvas (or whatever size you have), figure out how all the points stack up, compute an alpha that is meaningful for that number of points, and then send the heatmap to the client.

You can easily imagine as similar approach for line plots which does selectively downsampling of datapoints in order to preserve interesting features in the plot.

And then we'll build interactors on top of that, so you can actually treat it like a scatter plot, even though it's a heatmap that's being sent to your browser.

So the answer is - large datasets, means, as large as our abstract rendering algorithm can handle on your hardware, so those data sets should be pretty big.

We're actually using canvas.

http://bokeh.pydata.org/plot_gallery/iris.html

That has a selection tool you can play around with.

wouldn't js -> llvm be an easier approach?

agreed, disco is really great becuase you can easily get access to the file descriptor which has your data, then you can load it however way you want

hope you all don't mind. little self plug on the subject - I also have an open source outliner

here is the source http://github.com/hhuuggoo/efficiently

and the demo: https://eff.iciently.com/docview/r/4ed70c031a7ba32edb000002/

But this one is an app, not a plugin, so it might be less useful to some.

I realize there are other entries in this space, but here is mine. Just launched with credit card payments for non-free accounts

I took a really boring job, and it was a terrible experience but I came away with 2 lessons 1. python can be just as terrible or worse than java when written by ex-java programmers 2. I can now understand and read some seriously scary large and ridiculously bloated code bases - which is a valuable and painfully learned skill.

I use nosql stores for the same reason that I use a dynamically typed language (python) I like the flexibility and agility. I don't use nosql stores for performance

we've been discussing this a bit at Continuum, the motivation for me is that we're building some data viz stuff in the browser, and so access to some numerics in the browser would be quite nice. we could try numba -> llvm -> emcsripten, but then we might also just make a js backend to numba.