Good math/stats libraries for Ruby?

[Kenneth McDonald]

There seem to be lots of small stats/math libraries for Ruby, but none
that really dominate in the same way that NumPy/SciPy dominates in
Python. Can anyone recommend what are the most reliable and stable? My
needs are quite modest--standard deviation and things of that ilk. I
can code them up myself if need be, but that would seem to be a waste
of time if they are already available.

Thanks,
Ken

 

[Saji N. Hameed]

There seem to be lots of small stats/math libraries for Ruby, but none

that really dominate in the same way that NumPy/SciPy dominates in
Python. Can anyone recommend what are the most reliable and stable? My
needs are quite modest--standard deviation and things of that ilk. I can
code them up myself if need be, but that would seem to be a waste of time
if they are already available.

Ken,

Ruby has NArray -
http://narray.rubyforge.org/

Ruby GSL may also be of interest to you

http://rb-gsl.rubyforge.org/

If you have interest in gridded data, you may also check out
http://ruby.gfd-dennou.org/

saji

--
Saji N. Hameed

APEC Climate Center +82 51 668 7470
National Pension Corporation Busan Building 12F
Yeonsan 2-dong, Yeonje-gu, BUSAN 611705 (e-mail address removed)
KOREA

 

[Axel Etzold]

-------- Original-Nachricht --------

Datum: Tue, 25 Nov 2008 18:23:34 +0900
Von: "Saji N. Hameed" <[email protected]>
An: (e-mail address removed)
Betreff: Re: Good math/stats libraries for Ruby?

Ken,

Ruby has NArray -
http://narray.rubyforge.org/

Ruby GSL may also be of interest to you

http://rb-gsl.rubyforge.org/

If you have interest in gridded data, you may also check out
http://ruby.gfd-dennou.org/

saji


--
Saji N. Hameed

APEC Climate Center +82 51 668 7470
National Pension Corporation Busan Building 12F
Yeonsan 2-dong, Yeonje-gu, BUSAN 611705 (e-mail address removed)
KOREA

Dear Ken,

in addition to what Saji suggested, you could use the statistics2 package

http://raa.ruby-lang.org/project/statistics2/

which is a statistics library in pure Ruby, or, if you want extremely exhaustive
statistics, there are bindings to the very encyclopedic R statistical language.

http://www.r-project.org/
http://rubyforge.org/projects/rsruby/

I haven't been able to use the latter bindings with Windows, though.

Best regards,

Axel

 

[Joe Wölfel]

Math/stats libraries still seem to need a bit of work compared to =20
other Ruby libraries. The most comprehensive one I've used is =20
RubyGSL. However, it isn't easy to install/manage, has external =20
dependencies, and doesn't work with all versions of Ruby. I created =20
a patch so it could work with 1.9, but I don't know that the patch =20
has been included yet. Also, the GSL isn't as friendly as Ruby's =20
depending on what you want it for.

NArray doesn't have many math or stats functions, but it's easy to =20
install, manage, and try. It would be nice if there was a simple =20
dependency free gem that has all of what you want that just works out =20=

of the box. If there is one it isn't heavily advertised. It feels a =20=

bit like Python is today's FORTRAN in that you're almost forced to =20
use it because of its math libraries rather than because it's the =20
right language choice for you. Hopefully progress will continue and =20=

there will be more freedom of choice.

joe

 

[Cameron McBride]

Math/stats libraries still seem to need a bit of work compared to other R= uby
libraries. The most comprehensive one I've used is RubyGSL.

I strongly agree with both points. However, there are lots libraries
available that have worked well for many (as others have suggested).

Personally, I've made do with NArray + rb-gsl + hand-rolled. This
has been a solid performer for me over several years. However, there
have been some annoyances. For the simple stuff, I try and stick with
NArray as I think it's lightweight, easy and elegant. Since rb-gsl
is a larger C-binding, it can trigger some occasional bus-errors in
ruby. These have all seemed resolved by using newer versions of ruby
if repeatedly encountered. Any of these tie you to Matz' ruby
interpreter (MRI) which has never been a concern of mine (but it's
worth pointing out).

I certainly do *not* think Python is "today's FORTRAN" (sidenote:
there are a lot of fun comparisons in there beyond the scope of Joe's
suggestion), Python is better than that. I've found my solutions
in ruby to be quite sufficient, although I'll concede they are not as
comprehensive with repect to SciPy and/or PDL (perl!). There appears
to be more focus on the latter two from the US science community (at
least in astrophysics, which is what I'm most familiar with).

To speak to Joe's wish, I have felt for years that most of the pieces
are there to build a more cohesive umbrella for
math/statistics/analysis packages. In one form, this already exists
in http://ruby.gfd-dennou.org/. My problem with this solution and
also with SciPy / PDL is their monolithic structure which have
complicated dependencies and/or maintenance woes. Coming up with a
lighter-weight alternative isn't a small task. So it's not worth
doing unless it's done right, and doing it right will take a good deal
of time. In addition, most of the necessary functionality is already
available in the above libraries -- which means there might not even
be a good consensus of what "right" is for numerical computing in
ruby. (Let's be clear, this is solely my rambling speculation on why
it doesn't yet exist.)

I digress. Getting back to Ken's question: if you need C-like
numerics and don't mind being tied to MRI -- NArray and/or rb-GSL have
been very helpful and reliable for me.

Cameron

 

[Saji N. Hameed]

=20
I strongly agree with both points. However, there are lots libraries
available that have worked well for many (as others have suggested).

------clipped -------=20

To speak to Joe's wish, I have felt for years that most of the pieces
are there to build a more cohesive umbrella for
math/statistics/analysis packages. In one form, this already exists
in http://ruby.gfd-dennou.org/. My problem with this solution and
also with SciPy / PDL is their monolithic structure which have
complicated dependencies and/or maintenance woes. Coming up with a
lighter-weight alternative isn't a small task. So it's not worth
doing unless it's done right, and doing it right will take a good deal
of time. =20

------clipped -------=20

I wish there was a Ruby port of the NCAR Command Language,
(http://ncl.ucar.edu) a set of libraries for numerical data=20
analysis and visualisation. There
is a Python version though http://www.pyngl.ucar.edu/ . If there is some
group effort in making a port of this to Ruby, I will volunteer to help,
with my minimal ruby skills (i am better with scientific data analyis
though).

saji

--=20
Saji N. Hameed

APEC Climate Center +82 51 668 7470
National Pension Corporation Busan Building 12F =20
Yeonsan 2-dong, Yeonje-gu, BUSAN 611705 (e-mail address removed)
KOREA

 

[Joe Wölfel]

[Note: parts of this message were removed to make it a legal post.]

My problem with this solution and
also with SciPy / PDL is their monolithic structure which have
complicated dependencies and/or maintenance woes. Coming up with a
lighter-weight alternative isn't a small task. So it's not worth
doing unless it's done right, and doing it right will take a good deal
of time.

I'm not sure of the best overall scheme for structuring dependencies
between the libraries. I think gems could help. Few of the
current ruby math libraries are gems. There should not be any
external dependencies and the licensing should be simple and flexible.

Also, for these kind of libraries source control ought to be chosen
to encourage outside contribution. I don't think I'd personally want
to belong to every math project in the world, but I might
occasionally contribute a feature or bug fix. It's much better if
changes can be submitted via distributed version control rather than
manually merged uncontrolled text via email.

I certainly do *not* think Python is "today's FORTRAN" (sidenote:
there are a lot of fun comparisons in there beyond the scope of Joe's
suggestion), Python is better than that. I've found my solutions
in ruby to be quite sufficient, although I'll concede they are not as
comprehensive with repect to SciPy and/or PDL (perl!). There appears
to be more focus on the latter two from the US science community (at
least in astrophysics, which is what I'm most familiar with).

I agree with that. I don't mean to say that Python is crummy like
FORTRAN or that either of the two are crummy*. Python is a very
good language as well as one of the more interesting ones. But there
are lots of reasons to choose between different languages and
language implementations and with increasing frequency I find Ruby
and its various implementations to be really good choices for many
things. It doesn't seem like basic scientific and math libraries
should be one of the reasons not to choose Ruby. Yet sometimes I
feel pressured to use Python instead because of the libraries rather
than because it makes the most sense for a particular project. So it
feels to me very much like back in the day when there was pressure to
write in FORTRAN whenever science or math was involved.


*As soon as somebody makes a web framework for FORTRAN I'm sure it
will make a huge comeback. Just look at the success that COBOL ON
COGS has had.

joe

 

[Cameron McBride]

I wish there was a Ruby port of the NCAR Command Language,
(http://ncl.ucar.edu) a set of libraries for numerical data
analysis and visualisation. There
is a Python version though http://www.pyngl.ucar.edu/ . If there is some
group effort in making a port of this to Ruby, I will volunteer to help,
with my minimal ruby skills (i am better with scientific data analyis
though).

I've run across this a couple times, but have never tried to use it.
NCAR seems targeted at atmospheric science. Besides plotting, what
advantages does it have over the GSL bindings? What advantages would
it bring to have a ruby binding? My guess is it'd be the same people
that use NCAR, but now they could script using ruby syntax. While
that is a fine goal, I'm not sure it would satisfy the broader scope
(but I could be wrong, which is why I'm asking).

Cameron

 

[Saji N Hameed]

I've run across this a couple times, but have never tried to use it.
NCAR seems targeted at atmospheric science. Besides plotting, what
advantages does it have over the GSL bindings? What advantages would
it bring to have a ruby binding? My guess is it'd be the same people
that use NCAR, but now they could script using ruby syntax. While
that is a fine goal, I'm not sure it would satisfy the broader scope
(but I could be wrong, which is why I'm asking).

I have not much experience with GSL bindings. Looks like a collection of
basic math libraries with which you may build up a toolkit for something.

NCL (NCAR Command Language) is a tool kit for spatial and time series analysis
of multi-dimensional data sets. Things I like about it are:
1. Data model based on netcdf (basically data accompanied with metadata)
2. A large collection of libraries for spatial and time series analysis
3. Good graphic capabilities
4. The data model could be easily manipulated in a Fortran like style
5. Easy extensibility - users may extend NCL libraries with their own
Fortran or C code (write a stub file describing the headers, run
a simple script and you are ready to go)
- thus any of the basic math libraries (available in GSL for example)
may be easily used in NCL with minimal effort
6. Great documentation
7. Open-source from version 5.0 onwards

I guess NCL may not necessarily be only for the geophysical sciences - it
is sufficiently generic (data model & analysis + visualisation libraries)
for most needs. I am from the climate sciences, so I may be
a bit biased But I think the design of NCL may help us think
about a data analysis and visualisation toolkit for Ruby.

saji
--
Saji N. Hameed

APEC Climate Center +82 51 668 7470
National Pension Corporation Busan Building 12F
Yeonsan 2-dong, Yeonje-gu, BUSAN 611705 (e-mail address removed)
KOREA