···
On Tue, Jun 24, 2014 at 8:34 AM, Damian Avila damian.avila@continuum.io wrote:
I missed 3 the last hours knocking this implicit assumption about equality of columns lengths. At least, we strongly need to warn about the inequality status…
We shouldn’t warn. This should be a validation error, otherwise people will simply ignore/overlook this warning and end up in the same place. Optimally, this should be fixed on bokehjs level, so that scalars are expanded on glyph level, not on data source level, or even better not expanded at all, but we should use generators or some other abstraction over arrays and scalars.
Mateusz
–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.
To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+unsubscribe@continuum.io.
To post to this group, send email to bokeh@continuum.io.
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/CAM9Ly3GgkCOqF%3DV2LkxTFk%3DH_LEt%3Drx7ZyTL%3DWew4diHtdW-wg%40mail.gmail.com.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.
On Sun, Jun 22, 2014 at 2:49 PM, Bryan Van de Ven bryan@bokeh.org wrote:
Hugo, can you write up your thoughts on selections on a GH wiki page or similar when you get a chance? It seems maybe we should make a proper selection object that is decoupled from datasources but I would like to see your thoughts on this.
Regarding hard checks on column data source columns, I think that is fine, or at the very least, loud warnings.
Bryan
On Jun 21, 2014, at 3:39 AM, hugo hugo@continuum.io wrote:
re: selections - I would love to see us tackle that ASAP, a better selection model would enable much better stuff with serverside data
re: data sources - Is there a reason not to constrain column data sources to having the same column length? Personally i would like to do that, and just throw errors on construction if it’s violated
On 06/20/2014 11:45 AM, Bryan Van de Ven wrote:
On Jun 20, 2014, at 9:58 AM, Samuel Colvin samcolvin@gmail.com wrote:
When declaring multiple sets of data (eg. multiple x=[0,1,2,3], y=[0,1,4,9] pairs) in JSON it seems there are two possible approaches.
In one (eg. anscombe.py) you declare one ColumnDataSource which contains all data arrays.
In the other (eg. stocks.py) you declare a ColumnDataSource for each x,y pair.
Which is the preferred approach? And most importantly are there situations where only one approach is valid?
As Mateusz mentioned, the implicit assumption on columns in a given data source is that they have the same size. This could probably be stated more often or clearly in the docs. Some context might be helpful as well. The main reason for this is that data sources also store a current selection, and the selection indices can only make sense across different columns if the columns have the same length. This was probably a convenient thing to do early on but I think we may have to revisit this model in the future.
Bryan
–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.
To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+unsubscribe@continuum.io.
To post to this group, send email to bokeh@continuum.io.
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/53A544DE.4030000%40continuum.io.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.
–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.
To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+unsubscribe@continuum.io.
To post to this group, send email to bokeh@continuum.io.
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/60DEE1AF-EBCB-4187-A961-8312C886D18A%40continuum.io.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.
