41–47 of 47 posts
How easy is it to integrate a chart or graph into a larger project? My biggest gripe with Shiny is how difficult is to use the R calculate and graphing functions in a larger project without using OpenCPU as an API. My guess is that with Python being a more general purpose language, this should be easier..
Earlier quoted context omitted.
D3 is pretty ok with large datasets but I understand your point. What Shiny does to get around this is natively 'evaluate' the plots on the backend, creating a rasterized PNG file. A similar approach could work for Pyxley (using matplotlib or Seaborn to render the plot, and then sending that image file to the front end) but I fear with so much development time spent on d3 support such an approach would not be nativel…
>What Shiny does to get around this is natively 'evaluate' the plots on the backend, creating a rasterized PNG file I don't think that's the case for D3 charts, because that would kill the interactivity that is so great about D3. I use RCharts to inject D3 into my Shiny applications, and have ran into into performance issues with just a couple hundred data points. I think this is because all heavy lifting is done by…
Earlier quoted context omitted.
Dashing is great, but it's Ruby on the backend, not Python :)
It actually has a REST API for sending a dashboard data so you can pump in new data from Python or any language.
> I've been looking for something to do this (below) in python at least on backend.
How easy is it to integrate a chart or graph into a larger project? My biggest gripe with Shiny is how difficult is to use the R calculate and graphing functions in a larger project without using OpenCPU as an API. My guess is that with Python being a more general purpose language, this should be easier..
Why you don't want to use OpenCPU?
Of course, most of these issues are understandable and possibly by design, especially since OpenCPU was designed for embedded systems. That's fine - it just makes creating webapps or dashboards around R a more complicated usecase.
looks great. but i can't help but think it would save everyone a lot of time -- maybe not up-front, but in the long-run -- if we wrote these frameworks in c and just wrote language bindings for r, python, ruby, etc. why are we rebuilding good frameworks over again just because they're not written in our preferred language?
There is a big divide between interpreted and compiled resources though. If you have the original source in an interpreted language, it supports your ARM raspberry pi or chromebook just as well. With the C variation you need to build / package / install. I've kinda just come to accept that code re-use cross language has never been good except with the unix pipe.
So to run this there's code that needs to be compiled anyway.
Earlier quoted context omitted.
Why is having R a limitation? R is a fantastic data language which arguably beats all others in terms of number of libraries and data manipulation tools.
R has no native bayesian library like Pymc 3 (Must use stan which is c++). Also Python is better for ad hoc and agent based modeling and for out of core data with blaze and dask. So no, R is not ahead in everything.
Earlier quoted context omitted.
R has no native bayesian library like Pymc 3 (Must use stan which is c++). Also Python is better for ad hoc and agent based modeling and for out of core data with blaze and dask. So no, R is not ahead in everything.
I'm not trying to get into a R vs. Python argument, both have their strengths, but is it really true that R doesn't have anything like Pymc? https://cran.r-project.org/web/views/Bayesian.html