[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

neuroimage software - scientific computing and visualization

Darren L. Weber

2/1/2006 6:19:00 AM


Hi,

I've been programming with perl, a bit of python and a lot of matlab.
I've become very curious about ruby and considering whether or not to
take it on as my main development environment in the near future. I
could use some good advice before I dive into the deep end.

I'm looking at Ruby for scripting/programming of scientific computing
for neuroimaging. This includes time-series plots and analysis, image
volume segmentation and rendering, surface modeling, visualization and
morphing, and animating scalar and vector quanities on surfaces. Also
linear algrebra methods and spatial transformations, almost any
scientific computation you can imagine, especially large scale
statistical analysis (including permutations). Did I leave anything
out? What about threading and distributed cluster systems? I could
really use some tips on whether Ruby is a good choice for this work and
where to find projects that already fit into this picture.

So, I'm wonder if ruby has wrapped things like: VTK, ITK, The R-project
for stats, OpenGL, wxWindows, scientific libraries (eg, GNU GSL,
Atlas/Lapack), graphics libraries, etc. Any good advice on getting
started with these tools would be great.

There is some momentum in this area using python already. Why should I
use Ruby instead of Python? One thing that I've noticed is that python
distribution and installation methods are clumsy. If I want some
python package for neuroimaging, I have to find and install many
additional dependencies before I even get started. As a Debian user,
the apt system helps, but it's still not quite what I want. Ruby has
the gem system that appears to do the job right.

Thanks, Darren
18 Answers

anne001

2/1/2006 10:45:00 AM

0

I think you should stick with Matlab, they have developped programs for
years for this kind of work. The programs I have seen for MRI imaging
are in matlab.

In ruby, there are things missing: ex when you do a sort, you don't get
the index of a sort as in matlab, only the sorted array. So you would
have to write you own - Matlab like - methods.

The other thing I miss in ruby, the ability to do matrix operations. If
you do the mean, it is the mean of a vector, while in matlab, you can
do a mean on any dimension array, indicating which dimension

I don't know how much stats ruby can do, certainly the matlab stat
package is not complete, but I can't imagine that a programming
language would be that developed in this area.

Another reason to stay with matlab is readability. Matlab is a higher
level language. It sounds like you are a programmer selling a product,
so it might be different, but I work at a university, and students
inherit the matlab programs from one another, and then typically they
have to figure out what the program does to get the data in correctly
for their data, get the figures they want for their conditions... the
fact that it is written in a higher level language seems to help.

Ruby does have some matrix computation ability, so you should look at
that, and see if that suits your needs.

junk5

2/1/2006 2:53:00 PM

0

Hi Darren

> I'm looking at Ruby for scripting/programming of scientific computing
> for neuroimaging.

I used Matlab for my PhD research (medical image modelling and
analysis), and I think it was excellent for my purposes. Below is a
list of why I liked using it, which I'll compare to my (limited)
experience with Ruby afterwards:

1. Matlab language syntax maps closely to the underlying concepts (i.e.
vector and matrices).
2. Very simple, but powerful, plotting/visualisation abilities.
3. (Generally) efficient implementations for common matrix operations
(multiplication, decompositions etc.). These are very well-tested.
4. A REPL (i.e. you can experiment on a 'command line').
5. Cross-platform (Linux, OS X, Solaris, Windows).
6. No compiling (recent Matlabs do just-in-time compilation
automatically).
7. Excellent support for profiling (easily find and quantify those
computational hot-spots).
8. It's easy to write C (or FORTRAN) extensions when you really need
every last ounce of speed or control over memory.
9. Lots of other people use it, so there's an 'ecosystem' (the users
are also working on your problem or closely-related ones).

Comparing this to Ruby:

1. Ruby is high-level, but it's a general purpose language; it's not
specialised for vectors and matrices. You'd have to get a library or
write this yourself. The Ruby syntax is 'sort-of' similar to the Matlab
syntax, though. Well, it feels Matlab-y to me!
2. You'd need to write or find plotting/visualisation library for Ruby.
I've not looked, but I'd hope this is reasonably trivial.
3. You'd need to find or write a library to let you do efficient matrix
computations. I know there is stuff for Ruby out there, but it won't be
as well-tested as Matlab's and it's not a first class citizen of the
environment. Writing your own is much harder than it seems. You really
need a library that allows you to call LAPACK routines from Ruby.
4. Ruby has the irb REPL. This is fine.
5. Ruby seems to be pretty cross-platform, but you'd need to check the
same is true for the additional libraries you'd need. You might not
care about WIndows, but what about your colleagues? You often need to
share code with them.
6. No compiling, but also no JIT as far as I'm aware. Not too big an
issue if you've got a good matrix library.
7. I've not tried profiling in Ruby, but Matlab's profiler is very
good. If you can't profile your code and you're doing numerics, you're
in trouble.
8. I understand you can write Ruby extensions in C but I've not done
it.
9. The ecosystem for your problem domain is going to be much smaller in
Ruby than in Matlab. Ruby's best ecosystem domain seems to be webapps
(i.e. Rails).

Now, the thing I haven't mentioned is price. Matlab is expensive
(thousands of dollars for all the stuff you need). They do student
discounts, but last time I looked you'd need to pay hundreds of dollars
rather than thousands, so it's not a great discount. (Mathematica's
student terms were much better, last time I looked.)

Ruby is free. In my opinion, if you can afford Matlab (or someone else
is affording it for you), you should have a very good reason before you
ditch Matlab. However, if you can't afford Matlab, or have ideological
reasons why you don't want to use it (it's not open source, for
example), you should probably use and improve Octave, the open source
equivalent to Matlab. However, if you need to roll your own soluation,
I think Ruby would make a very good foundation for putting together
your own environment for numerical computing.

I think the real question is whether you want to do the 'fun' thing and
start (almost) from scratch (i.e. base your environment on Ruby) or
stand on the shoulders of giants (i.e. use Matlab or Octave). If you've
got real problems to solve now, you should probably resist the
temptation to do the fun thing.

Chris

Darren L. Weber

2/1/2006 8:25:00 PM

0


Thanks very much for these thoughtful comments.

Matlab is very nice and I enjoy working with it. The help system is
very informative and all aspects of scientific computing work well. No
wonder so many university projects work with matlab. But, I do not
enjoy the inconvenience of running a licence manager and having my work
come to a halt when my license expires every year. (Yes, some IT
departments do not automatically update the licenses on every system,
including my laptop). I also fear that sometime I may not have a
matlab license and my work will be locked, despite my best attempts to
create open-source tools. Most annoying is that I do not know how to
or cannot create multi-threaded functions and I can't call matlab
functions in shell scripts (matlab doesn't have a shebang for
scripting).

I can see some momentum in python for scientific computing and I have
begun to play with python, but I find the installation of modules can
be either easy or painful (especially dependencies). My intuitions are
telling me that ruby could be a better option than python in the long
term, but I want to clarify my understanding before I get carried away
with enthusiasm.

For a start, I've noticed these useful sites:

http://narray.rubyforge.org/ind...

http://rb-gsl.ruby...

http://sciruby.codeforpeople.com/sr.cgi...

I don't see anyone using these for neuroimaging, in particular.

Best, Darren

ptkwt

2/1/2006 9:01:00 PM

0

In article <1138774740.285273.21190@z14g2000cwz.googlegroups.com>,
Darren L. Weber <darrenleeweber@gmail.com> wrote:
>
>Hi,
>
>I've been programming with perl, a bit of python and a lot of matlab.
>I've become very curious about ruby and considering whether or not to
>take it on as my main development environment in the near future. I
>could use some good advice before I dive into the deep end.
>
>I'm looking at Ruby for scripting/programming of scientific computing
>for neuroimaging. This includes time-series plots and analysis, image
>volume segmentation and rendering, surface modeling, visualization and
>morphing, and animating scalar and vector quanities on surfaces. Also
>linear algrebra methods and spatial transformations, almost any
>scientific computation you can imagine, especially large scale
>statistical analysis (including permutations). Did I leave anything
>out? What about threading and distributed cluster systems? I could
>really use some tips on whether Ruby is a good choice for this work and
>where to find projects that already fit into this picture.
>
>So, I'm wonder if ruby has wrapped things like: VTK, ITK, The R-project
>for stats, OpenGL, wxWindows, scientific libraries (eg, GNU GSL,
>Atlas/Lapack), graphics libraries, etc. Any good advice on getting
>started with these tools would be great.

wxWindows, GSL, OpenGL are there, I believe. Not sure about the rest.

It would be nice to get a nice Ruby->R bridge and it could probably be
very Rubyish (maybe a DSL built on Ruby).

>
>There is some momentum in this area using python already. Why should I
>use Ruby instead of Python? One thing that I've noticed is that python
>distribution and installation methods are clumsy.

Well, that could be your reason. The other thing to consider is which language
you prefer. While many people will claim they are equivilent, there are
differences both feature-wise and less tangible differences. Check out Bruce
Eckel's recent post at Artima, for example.

>If I want some
>python package for neuroimaging, I have to find and install many
>additional dependencies before I even get started. As a Debian user,
>the apt system helps, but it's still not quite what I want. Ruby has
>the gem system that appears to do the job right.

You should definitely check ou the SciRuby site:
http://sciruby.codeforp...

You should also check out narray for high speed vector math in Ruby.

Phil

ptkwt

2/1/2006 9:13:00 PM

0

In article <1138790704.505109.135060@g44g2000cwa.googlegroups.com>,
anne001 <anne@wjh.harvard.edu> wrote:
>I think you should stick with Matlab, they have developped programs for
>years for this kind of work. The programs I have seen for MRI imaging
>are in matlab.
>
>In ruby, there are things missing: ex when you do a sort, you don't get
>the index of a sort as in matlab, only the sorted array. So you would
>have to write you own - Matlab like - methods.

I'm not sure I understand what you're saying here: are you saying you want the
indices of the array sorted, but not the array itself?

So are you saying that if you have an array like:
a = ['d', 'b', 'a', 'c', 'e']
You would like to get something like:
a.sort_index #=> [2, 1, 3, 0, 4]

If that's the case, then I'm sure it's doable. No built-in method that I'm
aware of, but you could easily create one.

>
>The other thing I miss in ruby, the ability to do matrix operations. If
>you do the mean, it is the mean of a vector, while in matlab, you can
>do a mean on any dimension array, indicating which dimension

check out narray.

>
>I don't know how much stats ruby can do, certainly the matlab stat
>package is not complete, but I can't imagine that a programming
>language would be that developed in this area.
>
>Another reason to stay with matlab is readability. Matlab is a higher
>level language. It sounds like you are a programmer selling a product,
>so it might be different, but I work at a university, and students
>inherit the matlab programs from one another, and then typically they
>have to figure out what the program does to get the data in correctly
>for their data, get the figures they want for their conditions... the
>fact that it is written in a higher level language seems to help.

YMMV. I don't find Matlab very readable. I much prefer Ruby's syntax.

It's been mentioned before, but it would be cool to create a kind of MatLab
'replacement' using Ruby. One could imagine that you could take advantage of
Ruby's metaprogramming and DSL abilities to create something that would be
quite nice to use. (realistically, we couldn't completely replicate all matlab
functionality, but perhaps we could focus on certain areas).

MatLab may be 'higher level' but that's only in the sense of representing
mathematical operations. In another sense Ruby is higher-level because it
would allow you to create a DSL for representing mathematical operations
(similar to MatLab).

Phil

ptkwt

2/1/2006 9:27:00 PM

0

In article <1138805570.480128.261390@g49g2000cwa.googlegroups.com>,
<junk5@microserf.org.uk> wrote:
>Hi Darren
>
>> I'm looking at Ruby for scripting/programming of scientific computing
>> for neuroimaging.
>
>I used Matlab for my PhD research (medical image modelling and
>analysis), and I think it was excellent for my purposes. Below is a
>list of why I liked using it, which I'll compare to my (limited)
>experience with Ruby afterwards:
>
>1. Matlab language syntax maps closely to the underlying concepts (i.e.
>vector and matrices).
>2. Very simple, but powerful, plotting/visualisation abilities.
>3. (Generally) efficient implementations for common matrix operations
>(multiplication, decompositions etc.). These are very well-tested.
>4. A REPL (i.e. you can experiment on a 'command line').
>5. Cross-platform (Linux, OS X, Solaris, Windows).
>6. No compiling (recent Matlabs do just-in-time compilation
>automatically).
>7. Excellent support for profiling (easily find and quantify those
>computational hot-spots).
>8. It's easy to write C (or FORTRAN) extensions when you really need
>every last ounce of speed or control over memory.
>9. Lots of other people use it, so there's an 'ecosystem' (the users
>are also working on your problem or closely-related ones).
>
>Comparing this to Ruby:
>
>1. Ruby is high-level, but it's a general purpose language; it's not
>specialised for vectors and matrices. You'd have to get a library or
>write this yourself. The Ruby syntax is 'sort-of' similar to the Matlab
>syntax, though. Well, it feels Matlab-y to me!
>2. You'd need to write or find plotting/visualisation library for Ruby.
>I've not looked, but I'd hope this is reasonably trivial.

There are a few things out there. There's a gnuplot interface, for example.

>3. You'd need to find or write a library to let you do efficient matrix
>computations. I know there is stuff for Ruby out there, but it won't be
>as well-tested as Matlab's and it's not a first class citizen of the
>environment. Writing your own is much harder than it seems. You really
>need a library that allows you to call LAPACK routines from Ruby.

Seems to me that narray has most of what you need here.

>4. Ruby has the irb REPL. This is fine.
>5. Ruby seems to be pretty cross-platform, but you'd need to check the
>same is true for the additional libraries you'd need. You might not
>care about WIndows, but what about your colleagues? You often need to
>share code with them.

No, they've all bought iBooks or PowerBooks by now ;-)

>6. No compiling, but also no JIT as far as I'm aware. Not too big an
>issue if you've got a good matrix library.

narray is implemented in C.

>7. I've not tried profiling in Ruby, but Matlab's profiler is very
>good. If you can't profile your code and you're doing numerics, you're
>in trouble.

Ruby has reasonably good profiling ability.

>8. I understand you can write Ruby extensions in C but I've not done
>it.

It's quite easy. It's even easier if you use Ruby::Inline.

Here's an tantalizing idea that I'll throw out: C is one thing and, yes, it's
fast.... but what if you could actually map some algorithm or math operation to
_hardware_ and thus get a large speed advantage even over C? I'm working on
something like this... details forthcoming. The idea is very similar to
Ruby::Inline. It will allow seamless communication between your Ruby program
and an FPGA board acting as hardware accelerator (these boards are available
for less than $200 now).

>9. The ecosystem for your problem domain is going to be much smaller in
>Ruby than in Matlab. Ruby's best ecosystem domain seems to be webapps
>(i.e. Rails).

Maybe that's the most successful domain related to Ruby up to this point,
however there are people using Ruby for scientific apps - see the SciRuby site:
http://sciruby.codeforp...

Ruby isn't just for webapps. In fact, until the last 18 months or so, people
were wondering if Ruby would be a player in the webapp space - how quickly
things change, eh?

>
>Now, the thing I haven't mentioned is price. Matlab is expensive
>(thousands of dollars for all the stuff you need). They do student
>discounts, but last time I looked you'd need to pay hundreds of dollars
>rather than thousands, so it's not a great discount. (Mathematica's
>student terms were much better, last time I looked.)
>
>Ruby is free. In my opinion, if you can afford Matlab (or someone else
>is affording it for you), you should have a very good reason before you
>ditch Matlab. However, if you can't afford Matlab, or have ideological
>reasons why you don't want to use it (it's not open source, for
>example), you should probably use and improve Octave, the open source
>equivalent to Matlab. However, if you need to roll your own soluation,
>I think Ruby would make a very good foundation for putting together
>your own environment for numerical computing.

Yes, and part of the philosophical argument as I see it is that tools like
MatLab are becoming 'required' for doing research (many people think so
anyway), kind of like using LaTeX for writing papers. However, LaTeX is free.
It would be great to have a completely free tool for research since
computational methods are becoming central to so much research.

>
>I think the real question is whether you want to do the 'fun' thing and
>start (almost) from scratch (i.e. base your environment on Ruby) or
>stand on the shoulders of giants (i.e. use Matlab or Octave). If you've
>got real problems to solve now, you should probably resist the
>temptation to do the fun thing.

However, I think you'd be surprised at how much is already available in Ruby.
Check it out and see if what you need might already be there (or be almost
there). Also, get on SciRuby and post requests.

Phil

junk5

2/2/2006 4:12:00 PM

0

Hi Darren

> But, I do not
> enjoy the inconvenience of running a licence manager and having my work
> come to a halt when my license expires every year. (Yes, some IT
> departments do not automatically update the licenses on every system,
> including my laptop). I also fear that sometime I may not have a
> matlab license and my work will be locked, despite my best attempts to
> create open-source tools. Most annoying is that I do not know how to
> or cannot create multi-threaded functions and I can't call matlab
> functions in shell scripts (matlab doesn't have a shebang for
> scripting).

All valid points, except that you can call matlab functions on the UNIX
(and Windows?) command line (though probably not with a shebang, but I
don't see that as essential).

> For a start, I've noticed these useful sites:
> http://narray.rubyforge.org/ind...
> http://rb-gsl.ruby...
> http://sciruby.codeforpeople.com/sr.cgi...

Thanks for the pointers.

Chris

junk5

2/2/2006 4:18:00 PM

0

Phil

> narray is implemented in C.

I took a quick look at its API and it only seemed to offer the LU
matrix decomposition; which seems a bit minimal.

> It would be great to have a completely free tool for research since
> computational methods are becoming central to so much research.

Agreed.

Chris

Ara.T.Howard

2/2/2006 4:21:00 PM

0

Ara.T.Howard

2/2/2006 5:25:00 PM

0