Hi,
I am unable to plot numpy arrays with a single dimension - The plot turns up empty. I’m pretty sure this was possible on an earlier release of Bokeh (maybe 0.10?, I’m not a 100% sure)
Below is a code sample that gives me an error
from bokeh.io import output_file
from bokeh.plotting import figure, show
import numpy as np
dat = np.random.randn(100)
output_file(‘temp.html’)
plt = figure()
plt.circle(dat)
show(plt)
Thanks!
Srikrishna Sekhar
I’m about certain this has never worked. You can just pass x=list(range(len(dat)))
Srikrishna Sekhar
Okay, thanks! That’s the workaround I’m using now.
Are there any plans to support this in the future? If implementing this doesn’t involve javascript, I’m happy to take a look and see if I can help with it!
On 22 May 2016 at 15:34, Bryan Van de Ven [email protected] wrote:
I’m about certain this has never worked. You can just pass x=list(range(len(dat)))
On May 22, 2016, at 02:57, Sri Krishna [email protected] wrote:
Hi,
I am unable to plot numpy arrays with a single dimension - The plot turns up empty. I’m pretty sure this was possible on an earlier release of Bokeh (maybe 0.10?, I’m not a 100% sure)
Below is a code sample that gives me an error
from bokeh.io import output_file
from bokeh.plotting import figure, show
import numpy as np
dat = np.random.randn(100)
output_file(‘temp.html’)
plt = figure()
plt.circle(dat)
show(plt)
Thanks!
Srikrishna Sekhar
–
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/CA%2BqdgMci-SBsw%2BxBBmwBsvbP6aCHUJWV0VPCuF%3Db3EqUAVqZUw%40mail.gmail.com.
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/8674D4D8-9D57-4BCC-8FD9-E35EB0BC499F%40continuum.io.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.
Srikrishna Sekhar
I can't say we have any plans, tho if you wanted to submit a PR it could be discussed. However, I don't think it would be entirely trivial. In order to support automated docs generation and boilerplate reduction, the glyph functions are actually derived programmatically, e.g. here:
https://github.com/bokeh/bokeh/blob/master/bokeh/plotting/figure.py#L52
And the issue is that this type of capability would only be appropriate for a subset of the glyph methods, not all of them, which means modifying the automation machinery in a way that makes it works on the subset of glyphs that it makes sense for. It would probably involve adding some kind of static class metadata to the Glyph classes that woudl support this optimization, and then having _glyph_function inspect for that.
Bryan
On May 22, 2016, at 10:51 AM, Sri Krishna <[email protected]> wrote:
Okay, thanks! That's the workaround I'm using now.
Are there any plans to support this in the future? If implementing this doesn't involve javascript, I'm happy to take a look and see if I can help with it!
Srikrishna Sekhar
On 22 May 2016 at 15:34, Bryan Van de Ven <[email protected]> wrote:
I'm about certain this has never worked. You can just pass x=list(range(len(dat)))On May 22, 2016, at 02:57, Sri Krishna <[email protected]> wrote:
Hi,
I am unable to plot numpy arrays with a single dimension - The plot turns up empty. I'm pretty sure this was possible on an earlier release of Bokeh (maybe 0.10?, I'm not a 100% sure)
Below is a code sample that gives me an error
from bokeh.io import output_file
from bokeh.plotting import figure, show
import numpy as np
dat = np.random.randn(100)
output_file('temp.html')
plt = figure()
plt.circle(dat)
show(plt)Thanks!
Srikrishna Sekhar--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/CA%2BqdgMci-SBsw%2BxBBmwBsvbP6aCHUJWV0VPCuF%3Db3EqUAVqZUw%40mail.gmail.com\.
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/8674D4D8-9D57-4BCC-8FD9-E35EB0BC499F%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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/CA%2BqdgMfkb8LBfKUX417W_oG_UCUb7ZFbb2pCUtAu6hjbqu0Keg%40mail.gmail.com\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.
I agree that doing it this way would be non-trivial. But, I like this idea
of having other constructor classmethods, possibly decorated in some way to
indicate how they match arguments. So, in spirit, similar to the
MultipleDispatch library, but matching based on the number (and perhaps,
the shape) of positional args, rather than their types. And you would want
to generically handle positional vs keyword arguments.
The real challenge will be the logic involved shape transformation, e.g.
"unzipping" lists of 2-tuples into two lists of scalars. This seems like a
very common and useful capability to have in the library, but it doesn't
fit with how things are implemented. (This also gets into things like,
lists of dicts, and transposing that into a ColumnDataSource...)
-Peter
On Fri, Jun 3, 2016 at 11:17 PM, Bryan Van de Ven <[email protected]> wrote:
I can't say we have any plans, tho if you wanted to submit a PR it could
be discussed. However, I don't think it would be entirely trivial. In order
to support automated docs generation and boilerplate reduction, the glyph
functions are actually derived programmatically, e.g. here:https://github.com/bokeh/bokeh/blob/master/bokeh/plotting/figure.py#L52
And the issue is that this type of capability would only be appropriate
for a subset of the glyph methods, not all of them, which means modifying
the automation machinery in a way that makes it works on the subset of
glyphs that it makes sense for. It would probably involve adding some kind
of static class metadata to the Glyph classes that woudl support this
optimization, and then having _glyph_function inspect for that.
Right to do this in general, it seems like you need hooks on the glyph methods to delegate (*args, **kwargs) parsing into some defined "internal" interface specification. I'm not sure it's "hard" per se, but it is actual work, and would require both tests as well as the appropriate hooks into the documentation automation machinery.
Bryan
On Jun 4, 2016, at 5:48 AM, Peter Wang <[email protected]> wrote:
On Fri, Jun 3, 2016 at 11:17 PM, Bryan Van de Ven <[email protected]> wrote:
I can't say we have any plans, tho if you wanted to submit a PR it could be discussed. However, I don't think it would be entirely trivial. In order to support automated docs generation and boilerplate reduction, the glyph functions are actually derived programmatically, e.g. here:https://github.com/bokeh/bokeh/blob/master/bokeh/plotting/figure.py#L52
And the issue is that this type of capability would only be appropriate for a subset of the glyph methods, not all of them, which means modifying the automation machinery in a way that makes it works on the subset of glyphs that it makes sense for. It would probably involve adding some kind of static class metadata to the Glyph classes that woudl support this optimization, and then having _glyph_function inspect for that.
I agree that doing it this way would be non-trivial. But, I like this idea of having other constructor classmethods, possibly decorated in some way to indicate how they match arguments. So, in spirit, similar to the MultipleDispatch library, but matching based on the number (and perhaps, the shape) of positional args, rather than their types. And you would want to generically handle positional vs keyword arguments.
The real challenge will be the logic involved shape transformation, e.g. "unzipping" lists of 2-tuples into two lists of scalars. This seems like a very common and useful capability to have in the library, but it doesn't fit with how things are implemented. (This also gets into things like, lists of dicts, and transposing that into a ColumnDataSource...)
-Peter
--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/CABGrp%2B9oxffdQF3T6HaYfvaSYAcetweE%2BSRi7hf%3DZg0vdAu_DQ%40mail.gmail.com\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.