enterprise ruby

[Edwin Van leeuwen]

I have a lot of numerical processing scripts in ruby. Mostly they are
hybrids of NArray and GSL, with a few of Ara's tricks and C extensions
thrown in. Since my focus has also been results ASAP, I've had
little time to generalize / sync these efforts. In addition, I sorely
miss direct graphics (note: I'm not a fan of how GSL shellsout to
graph, or many of the other solutions. The closest to what I like is
the NArray/PGPLOT extension, but PGPLOT itself is better when not used
directly).

I also have a half hearted library for my own use, which basically
consist of wrapper/helper methods around rbgsl/gnuplot functions.

It'd be great to find a few like minded people and work together to
garner and keep momentum for such a project. Given the small number
of interested people, and the fact that "like-minded solutions" don't
seem to overlap between them - I'm skeptical of it happening. However
unlikely, I still cling to hope...

What would you like to see in such a project. Would you like something
that binds together existing c libraries (gsl/lapack etc) or would you
like to build it all up from scratch?

Edwin

 

[Sean Surname]

I also have a half hearted library for my own use, which basically
consist of wrapper/helper methods around rbgsl/gnuplot functions.


What would you like to see in such a project. Would you like something
that binds together existing c libraries (gsl/lapack etc) or would you
like to build it all up from scratch?

Building these things up from scratch is nearly impossible, even more so
than with such a small audience. I know I don't know enough about
numerical methods to recreate even a fraction of Matlab/Octave/R, and I
bet the number of people who do is vanishingly small. So a non-painful
wrapper around existing libraries is probably the only way to go.

On the other hand, using Ruby creates opportunities not available in
Matlab/Octave. One that I've toyed with is an extension to generate
efficient loops over arrays (kind of like pdlpp in Perl, but hopefully
less painful). The idea is for loops like "a[...] =
complicated_expression(b, c)" to iterate in C without making temporary
array copies. An easy-to-use version of this would really set Ruby
apart from other numerical languages.

 

[M. Edward (Ed) Borasky]

I also have a half hearted library for my own use, which basically
consist of wrapper/helper methods around rbgsl/gnuplot functions.


What would you like to see in such a project. Would you like something
that binds together existing c libraries (gsl/lapack etc) or would you
like to build it all up from scratch?

Edwin

Are we talking *enterprise* Ruby or *high-performance scientific*
Ruby??? There's a whole web site devoted to the latter,
http://sciruby.codeforpeople.com/.

 

[M. Edward (Ed) Borasky]

so, so, so true. I, also, have had some half-hearted attempts to make
some things work - but it's difficult. While I still don't use
matlab, I'm not exceptionally happy with the current state of my
workflow. I also believe that Ruby has a lot of the right things to
make a fantastic solution. Unfortunately, years later, I have to
agree - it requires some Serious Work and I'm not sure how/if/when I
can make it happen. Also, besides a select few - it doesn't appear
that many care to make ruby stretch far in that realm. The select few
seem to be rather satisfied with current solutions (say, a certain
advocate of RSRuby While unfortunate, it makes sense - it's not a
very large user base.

I have a lot of numerical processing scripts in ruby. Mostly they are
hybrids of NArray and GSL, with a few of Ara's tricks and C extensions
thrown in. Since my focus has also been results ASAP, I've had
little time to generalize / sync these efforts. In addition, I sorely
miss direct graphics (note: I'm not a fan of how GSL shellsout to
graph, or many of the other solutions. The closest to what I like is
the NArray/PGPLOT extension, but PGPLOT itself is better when not used
directly).

It'd be great to find a few like minded people and work together to
garner and keep momentum for such a project. Given the small number
of interested people, and the fact that "like-minded solutions" don't
seem to overlap between them - I'm skeptical of it happening. However
unlikely, I still cling to hope...

Cameron

Well ...

1. Ruby is the newest language in my toolbox, running something like six
years behind R and ten years behind Perl. The other side of that coin,
though, is that I've *never* learned Python and don't plan to.

2. As long as your focus is results ASAP, you're always going to favor
the old tools and quick hacks like shelling out to the command line
interface of your favorite open-source application for the domain of
interest.

3. As I noted on another post, there is a "scientific Ruby" project. So
there is a place for "us".

 

[Charles Oliver Nutter]

The only Java-ImageMagick library I can find is JMagick, a JNI bridge to
ImageMagick (which I'm guessing won't build in JRuby).

Actually, it probably would work fine, but I'm not sure anyone's tried
it. Of course, JNI brings along its own considerations, but nothing in
JRuby prevents JNI from working; it's just more painful to wire
libraries in from scratch using JNI.

Well, in theory, the latter; in reality, the former. ImageMagick, as
unwieldy as it's been, seems to be a de facto standard in the web
community. I must have installed it five zillion times by now (that's in
metric, you understand) for various PHP, Perl, and Ruby packages.

Only a subset of ImageMagick is really used there - basically enough to get
thumbnails, text rendering, and maybe the equivalent of Amazon's image
processing features (http://aaugh.com/imageabuse.html). But the API oughta
Just Work. There are drop-in replacements for RMagick, like ImageScience -
but even that needs FreeImage (binary!) and Ruby::Inline (C!).

I guess my specific problem with RMagick (beyond those that e.g.
inspired ImageScience) is that like most Ruby extensions there's no
abstraction going on. It's little more than a wrapper around a C
library, resulting in apps being tightly coupled to one specific
image-processing library. If that weren't the case, and if the
operations were a bit more abstracted, it would be a lot easier to
provide the same functionality from any other library.

- Charlie

 

[Cameron McBride]

What would you like to see in such a project. Would you like something
that binds together existing c libraries (gsl/lapack etc) or would you
like to build it all up from scratch?

well, I think there are great libraries in both C and ruby versions (C
extensions). I really like how rb-gsl and NArray allow crosstalk. I
think a lot could be done with some thought and further syncing of
these efforts.

GSL is nice, but it'd also be great to use lapack/blas libraries.
Rnum looks interesting, but admittedly, I haven't done much with it.
Also, there are some quirks to these solutions that would require some
thought (it's not yet clear to me if it can be solved with a subclass
type plan, or a tweak to the "core").

In any case, I have a fairly well thought out list that I've been
playing with for years, but that is better discussed elsewhere
(sciruby perhaps).

Cameron

 

[Cameron McBride]

Well ...

1. Ruby is the newest language in my toolbox, running something like six
years behind R and ten years behind Perl. The other side of that coin,
though, is that I've *never* learned Python and don't plan to.

sure. But I'm not clear about the point you're trying to make. What
am I missing?

2. As long as your focus is results ASAP, you're always going to favor
the old tools and quick hacks like shelling out to the command line
interface of your favorite open-source application for the domain of
interest.

exactly. which is the problem. at least, this is specifically the
issue with my involvement / progress. I'm willing to give it some
time, thought and code - but I don't feel I currently don't have the
time (nor coding efficiency) to actually make this coalesce into a
proper project.

So like you say, the general approach has to change. If a small group
got interested and focused on it, I think the momentum could go a long
way. The immediate difficulty is agreeing on some features.
ThoseThatCameBefore have made many workable solutions, several of
which I've used religiously (e.g. NArray and rb-gsl).

3. As I noted on another post, there is a "scientific Ruby" project. So
there is a place for "us".

yes. A good reminder.

Cameron