From: Jason Roelofs Date: 2008-01-20T23:57:37+09:00 Subject: Re: Ruby, C, swig and variable types ------=_Part_9583_3640946.1200841063320 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Using SWIG is a good way to go. The most basic wrapping, if there's no out parameters is simply this: wrapper.i: %{ #include "file1.h" #include "file2.h" ... %} %include "file1.h" %include "file2.h" ... SWIG doesn't take much to learn. Look through the website at www.swig.org, the wiki, and especially http://www.swig.org/Doc1.3/Ruby.html. And as a clarification of RubyInline, the only speed hit is the first run where Inline has to parse your C code, generate Ruby wrapper code (if applicable), and compile an extension. If the extension exists and the code hasn't changed, it just require's your extension. Jason On Jan 20, 2008 5:36 AM, Axel Etzold wrote: > Dear Ed, > > > Is your C code one of the "well-known" open source libraries that do > > this kind of computation, or is it home-grown? The reason I ask is that > > there are quite a few Python interfaces to the well-known libraries, and > > it would be relatively easy to port some of them to Ruby. > > It is home-grown ... partly because the divisions I have to do > involve several variables (see an example here: > http://www.geocities.com/famancin/buchberger.html) ... I am not aware that > there are any "well-known" open-source libraries for this as it seems a more > exotic part of computational algebra after all. > > One problem of this type of computations is that they tend to be > a.) extremely consuming in computation (twice exponential in the number > of variables ... and any interesting applied problem now > involves around 20 variables or more), > so C seemed a good choice for doing the bulk of the work, but problems > of this size tend to be just unfeasible unless one can make good use of: > b.) the actual amount of computations depends on the ordering of the > terms (defined based on the different variables) and you can achieve > dramatic differences if a good procedure is found. So I am trying out > several strategies for reducing the amount of work based on the > concrete structure of the problem (graph theoretic ideas, mostly). > > These things are done in Ruby, as it is so much nicer to code in :) > and as this is a part of the problem where speed of computation > is not so critical, as most of the computation is done in the division > process written in C. > > Now, to connect the two, I looked at this tutorial: > > > http://www.rubyinside.com/how-to-create-a-ruby-extension-in-c-in-under-5-minutes-100.html > > I've managed to make this work without any problem. > Now, what I still do not understand is quite what SWIG does precisely > for the communication of Ruby and C. > > 1.) I faintly recall reading a post on this list that SWIG could be used > not only to extend Ruby with C, but also the other way round ... so I was > thinking that maybe I could use the Ruby's Rational to extend > my C code .. if you have any pointers for extending C with Ruby, please > let me know. > > 2.) If you don't have to declare variables with types in Ruby, but can > use Ruby nevertheless in connection with C via SWIG, and possibly > inversely (as said in 1.), SWIG must somehow be able to determine the > underlying > C structure of Ruby and associate the two. > Beyond the problem I'm having here, I would also like to know how > realistic this is - in the most perfect of all worlds, this would mean > one could re-use any code from any language having a C basis in > any other ... just a dream, but a nagging one. > > > One other note -- have you looked at RubyInline? > > Yes, but as far as I understand it, this allows to use C as if it > were a scripting language, but it comes at a cost of speed, which I > can't afford here. > > Best regards, > > Axel > -- > GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. > Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail > > ------=_Part_9583_3640946.1200841063320--