M. Edward (Ed) Borasky wrote:
GSL doesn't have SVD, least-squares and eigenvalues?
IIRC GSL has these things (and BLAS and LAPACK), but it lacks others,
such as NArray's convenient matrix slice-and-dice syntax. RSRuby has
lots of great statistical routines, but probably can't share data with
NArray or GSL. Each solves its own part of the problem well, but
someone still needs to sit down and write efficient (non-copying) and
transparent glue between them. A Matlab transition cheat-sheet would
also help (Numpy has one of these).
···
--
Posted via http://www.ruby-forum.com/\.
Sean Surname wrote:
M. Edward (Ed) Borasky wrote:
GSL doesn't have SVD, least-squares and eigenvalues?
IIRC GSL has these things (and BLAS and LAPACK), but it lacks others, such as NArray's convenient matrix slice-and-dice syntax. RSRuby has lots of great statistical routines, but probably can't share data with NArray or GSL. Each solves its own part of the problem well, but someone still needs to sit down and write efficient (non-copying) and transparent glue between them. A Matlab transition cheat-sheet would also help (Numpy has one of these).
There is an Octave-to-R cheat sheet available at http://cran.r-project.org/doc/contrib/R-and-octave.txt
As far as sharing data is concerned, to keep everybody's garbage collectors and memory allocators happy and segfault-free, you probably need to do explicit transfers of data between the various packages, rather than trying to maintain your sanity and pass pointers at the same time. 
Depending on the size of the datasets involved, though, you might want to look at something like SQLite files. They're fast, look like an RDBMS, and both Ruby and R can talk to them. And if you have enough RAM, the OS will buffer them for you. Of course, the datasets I deal with are so large I have to put them in PostgreSQL anyhow.
M. Edward (Ed) Borasky wrote:
As far as sharing data is concerned, to keep everybody's garbage
collectors and memory allocators happy and segfault-free, you probably
need to do explicit transfers of data between the various packages,
This is a significant barrier. Having to marshal and unmarshal your
data whenever you go from one domain to another is annoying. It's a
large part of what we're trying to avoid in moving away from a
multi-language solution. I think Ruby's got the right ingredients to
pull this stuff together: dynamism, easy C interaction, and flexible and
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.
···
--
Posted via http://www.ruby-forum.com/\.
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 11/13/07, Sean Surname <x3qh85202@sneakemail.com> wrote:
M. Edward (Ed) Borasky wrote:
> As far as sharing data is concerned, to keep everybody's garbage
> collectors and memory allocators happy and segfault-free, you probably
> need to do explicit transfers of data between the various packages,
This is a significant barrier. Having to marshal and unmarshal your
data whenever you go from one domain to another is annoying. It's a
large part of what we're trying to avoid in moving away from a
multi-language solution. I think Ruby's got the right ingredients to
pull this stuff together: dynamism, easy C interaction, and flexible and
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.
Cameron McBride 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
···
On 11/13/07, Sean Surname <x3qh85202@sneakemail.com> wrote:
--
Posted via http://www.ruby-forum.com/\.
Cameron McBride wrote:
M. Edward (Ed) Borasky wrote:
As far as sharing data is concerned, to keep everybody's garbage
collectors and memory allocators happy and segfault-free, you probably
need to do explicit transfers of data between the various packages,
This is a significant barrier. Having to marshal and unmarshal your
data whenever you go from one domain to another is annoying. It's a
large part of what we're trying to avoid in moving away from a
multi-language solution. I think Ruby's got the right ingredients to
pull this stuff together: dynamism, easy C interaction, and flexible and
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
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".
···
On 11/13/07, Sean Surname <x3qh85202@sneakemail.com> wrote:
Edwin Van leeuwen wrote:
Cameron McBride 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.
···
On 11/13/07, Sean Surname <x3qh85202@sneakemail.com> wrote:
--
Posted via http://www.ruby-forum.com/\.
Edwin Van leeuwen wrote:
Cameron McBride 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
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 Surname <x3qh85202@sneakemail.com> wrote:
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
···
On 11/14/07, Edwin Van leeuwen <edder@tkwsping.nl> wrote:
Cameron McBride wrote:
> 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?
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
···
On 11/14/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote: