Cameron McBride wrote:
On 11/13/07, Sean S. [email protected] wrote:
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
Edwin Van leeuwen wrote:
Cameron McBride wrote:
On 11/13/07, Sean S. [email protected] wrote:
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?
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.
Edwin Van leeuwen wrote:
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/.
On 11/13/07, Sean S. [email protected] wrote:
unobtrusive syntax. But someone needs to sit down and do some Serious
Work before it’s a viable Matlab replacement. I’ve made a couple of
half-hearted tries, but it’s hard to make progress piece-by-piece when
you’re trying to generate results right-this-minute.
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
On Mon, 12 Nov 2007 13:03:42 -0500, Charles Oliver N. wrote:
a Java-based ImageMagick that either wraps or duplicates IM’s functionality.
The only Java-ImageMagick library I can find is JMagick, a JNI bridge
to
ImageMagick (which I’m guessing won’t build in JRuby).
So I guess there’s an important introductory question to ask before we
would start investigating:
Is it ImageMagick’s exact specifications or general image processing we
want to provide? The former is obviously much harder, while the latter
can be done through any number of libraries.
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 (Abusing Amazon images). 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!).
Jay L. |
Boston, MA | My character doesn’t like it when they
Faster: jay at jay dot fm | cry or shout or hit.
http://www.jay.fm | - Kristoffer
On Mon, 12 Nov 2007 10:02:21 -0500, M. Edward (Ed) Borasky wrote:
I actually thought about ImageMagick when I wrote that. Doesn’t
ImageMagick have a command line interface? Can’t Ruby (and jRuby)
execute command lines? That’s what I had in mind when I wrote “loose
coupling”. 
Ah, yeah, that’s VERY loose coupling! And there are people doing that
today; there’s a recommendation on an O’Reilly blog to skip the JNI
JMagick
wrapper and just use Runtime.exec().
Aside from the obvious performance hit - a new process for every image!
it just feels too much like the old days of MIS-written batch-processed
no-error-checking copy-a-file-into-the-queue-directory scripts. I’m
probably being religious there, though. But the performance issue
remains.
Well … I’m sticking with “because it’s open source and we can” as the
best reason for extending a language. Implicit in that is a plea to
extend the language to the primitive data types necessary for, say,
signal and image processing, which are – surprise – multidimensional
arrays of numeric data packed contiguously in RAM.
I realize that you’re talking mostly about scientific software, and that
the image-processing would be a side benefit. But I do want to point
out
that, to a non-comp-sci guy like myself, image processing has nothing to
do
with a multidimensional array of numeric data packed contiguously in
RAM.
It has to do with thumbnails and resizing and drawing lines and circles
and
fonts. I’m looking for an iPod, not an FPGA. Unless someone wanted to
reinvent ImageMagick as a pure-ruby solution based on those new
primitive
types, they wouldn’t do me any good for this example.
On 11/14/07, Edwin Van leeuwen [email protected] wrote:
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
Jay L. wrote:
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 (Abusing Amazon images). 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.
On 11/14/07, M. Edward (Ed) Borasky [email protected] wrote:
Well …
- 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?
- 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).
- As I noted on another post, there is a “scientific Ruby” project. So
there is a place for “us”.
yes. A good reminder.
Cameron