Looks good. I'm a big fan of narray to get decent performance for array operations, interesting to see how the rewrite of that will perform. Narray is pretty damn close to realtime compared to native ruby implementations.
SciRuby
21–30 of 63 posts
Re: SciRuby
#22This is absolutely needed. Glad that the project is come back to life. Big up to the developers.
Re: SciRuby
#23I hope they don't set up SciPy as the project to emulate and improve upon. Deep knowledge of R, Fortran, and Matlab would better inform this project of what scientists need. SciPy is great, but it's clearly best for programmers that have a slight scientific bent and can't stomach learning the existing scientific tools (which are admittedly a bit difficult to combine with modern software engineering). There are some g…
What do you mean exactly? Most of the SciPy API maps pretty directly to MATLAB.
Re: SciRuby
#24Interesting stuff, but given the sheer brainmass that SciPy has attracted its going to be hard to draw users away from that crowd. I think the only appeal of this project, at least for the time being, is labs that are already entrenched in Ruby.
Re: SciRuby
#25This is a sincere question, if you're doing science, why would you want to use ruby over python?
Re: SciRuby
#26I noticed this is licensed as GPLv3 as opposed to a BSD license for SciPy. Isn't this going to be a huge barrier to adoption, or am I missing something?
Re: SciRuby
#27This is a sincere question, if you're doing science, why would you want to use ruby over python?
My answer to this question is transparency. At my company Brighter Planet we write all of our scientific/methodological code in Ruby so that people with basic technical skill can understand what's going on. The ability to create expressive DSLs is really crucial.
Re: SciRuby
#28I'm really glad they're implementing Protovis instead of trying to copy Matlab's plotting facilities like Matplotlib. Matlab plotting is pretty terrible.
matplotlib is very flexible and has a wide array of plot types. It's great for quickly making plots of some data in Python. But IMO the output is not really nice to look at, it takes a lot of customization to make the plots publication-quality, and it feels kind if clunky for making interactive plots (however, some animation support was added recently, I haven't looked at that in deail yet). The screenshots of protov…
Matplotlib is ok for a first plot during exploratory analysis, but is a far, far cry from the facilities available in R through base graphics, grid graphics, trellis graphics, or ggplot2.
Protovis/d3 take a different approach, also focused on a similar Grammar of Graphics like ggplot but primarily concerned about the tooling, instead of the application.
Tooling level libraries are nice because they tend to be flexible enough for high data ink ratios, unlike highcharts, which turns me away with every example.
Re: SciRuby
#29This is a sincere question, if you're doing science, why would you want to use ruby over python?
My answer to this question is transparency. At my company Brighter Planet we write all of our scientific/methodological code in Ruby so that people with basic technical skill can understand what's going on. The ability to create expressive DSLs is really crucial.
That's very interesting. What sorts of DSLs are you creating, or can you say?
Re: SciRuby
#30Earlier quoted context omitted.
matplotlib is very flexible and has a wide array of plot types. It's great for quickly making plots of some data in Python. But IMO the output is not really nice to look at, it takes a lot of customization to make the plots publication-quality, and it feels kind if clunky for making interactive plots (however, some animation support was added recently, I haven't looked at that in deail yet). The screenshots of protov…
Matplotlib is ok for a first plot during exploratory analysis, but is a far, far cry from the facilities available in R through base graphics, grid graphics, trellis graphics, or ggplot2. Protovis/d3 take a different approach, also focused on a similar Grammar of Graphics like ggplot but primarily concerned about the tooling, instead of the application. Tooling level libraries are nice because they tend to be flexibl…
Your choice of terms is very interesting! I would say that Protovis and d3 do not take a Grammar of Graphics approach per se; rather, they tackle mostly just the lowest level of the grammar, namely aesthetic composition and some transforms. ggplot is very nice for the kinds of datasets that people use R for, but it's only one part of the story.
For large dataset and interactive visualization in Python, take a look at Chaco: http://code.enthought.com/chaco