In a very small bioinformatics group I know of, they are deciding
whether to code mostly in python or ruby. The lead knows that python
can "easily be ported to C because of its strictness."
How easy is it to port (translate) ruby code into C? Anyone with
experience in doing this? I've done a little and it seemed very easy,
but I've never translated python into C so I can't compare.
Discussion on alternatives (Inline, using C extensions, NArray, #include ruby, etc.) is welcome, but I'd like to keep the main focus
on translating to C for this thread.
I would find it reasonably difficult to port code from ANY scripting
language to C -- and I'm pretty good at C. "Strictness" does not make it
easier to port python to C. Nor does it make it easy to port shell to C,
or perl to C, or anything else. I am afraid the lead is full of crap.
Sometimes this happens.
Furthermore, porting stuff from an OO language to C is almost certainly
absolutely the wrong thing to do. The correct solution might be to write
a plugin module for the language which translates specific functionality into
raw C calls for performance reasons, but if you have a design that makes any
sense at all in an OO language, translating it to C is stupid.
In any event, what you have here is a social problem, not a technical
problem -- you have someone in charge who doesn't know what's going on.
-s
···
On 2010-05-07, bwv549 <jtprince@gmail.com> wrote:
In a very small bioinformatics group I know of, they are deciding
whether to code mostly in python or ruby. The lead knows that python
can "easily be ported to C because of its strictness."
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net | Seebs.Net <-- lawsuits, religion, and funny pictures Fair game (Scientology) - Wikipedia <-- get educated!
Hi. I don't know about "translating" Ruby into C, I would probably write in
C to begin with so that you don't get side tracked using some nice
functionality that Ruby provides that C does not.
However, Ruby does support a procedural paradigm, and you can write it
exactly like your C code (this is how I started, but I don't think it
provides any real benefits, I only used it b/c Ruby doesn't care how large
your numbers are, and I needed to work with enormously large numbers)
I don't know your reasons for wanting to use C, I assume for optimizing
certain parts of your algorithm, or dealing with certian low level
functionalities. In this case, if you are using the default Ruby (Matz's
Ruby Interpreter, which is written in C), then you might consider
Ruby-Inline, which is an elegant and powerful library written by Ryan Davis.
You can see a few examples here rubyinline | software projects | by ryan davis It allows you to write
your C code directly inside of your Ruby code. Then you can have a nice
amalgamate of both Ruby and C, depending on what the situation requires.
···
On Fri, May 7, 2010 at 11:20 AM, bwv549 <jtprince@gmail.com> wrote:
In a very small bioinformatics group I know of, they are deciding
whether to code mostly in python or ruby. The lead knows that python
can "easily be ported to C because of its strictness."
How easy is it to port (translate) ruby code into C? Anyone with
experience in doing this? I've done a little and it seemed very easy,
but I've never translated python into C so I can't compare.
Discussion on alternatives (Inline, using C extensions, NArray, #include ruby, etc.) is welcome, but I'd like to keep the main focus
on translating to C for this thread.
Discussion on alternatives (Inline, using C extensions, NArray, #include ruby, etc.) is welcome, but I'd like to keep the main focus
on translating to C for this thread.
There's lots of good reasons to use Python for scientific computing, such as
the excellent SciPy and NumPy libraries. However, the reason you stated is
not one of them.
There is the Psyco compiler which lets you use a subset of Python syntax to
optimize performance critical portions of your code, however Python itself
certainly cannot "easily be ported to C". There was the Starkiller Python
compiler which compiled to C++, however it was never released.
The main reason to use Python over Ruby for scientific computing is the
community of scientific computing users of Python is larger and there are
better libraries available.
···
On Fri, May 7, 2010 at 10:20 AM, bwv549 <jtprince@gmail.com> wrote:
In a very small bioinformatics group I know of, they are deciding
whether to code mostly in python or ruby. The lead knows that python
can "easily be ported to C because of its strictness."
wrote in
<3aac7538-b703-4604-8280-79f1d98d5260@j36g2000prj.googlegroups.com>:
In a very small bioinformatics group I know of, they are deciding
whether to code mostly in python or ruby. The lead knows that python
can "easily be ported to C because of its strictness."
First, I agree with Peter Seebach that this is nonsense.
Second, why would you port code from either language to C? Is it to
gain performance in areas of the code where Ruby/Python isn't
sufficiently performant? If so, then you're putting the cart before
the horse. Here is the correct order:
1. Write the code.
2. Test performance.
3. If performance is not acceptable, profile the code and identify the
bottlenecks.
4. Examine the bottlenecks to see if the performance can be improved
in the current language, e.g. by switching algorithms or tweaking
generic algorithms to work better with your specific data.
5. Make those changes and retest. You might need to experiment with a
few versions.
6. If the changes result in insufficient improvement, then look at
implementing them in C, compiling to a library and calling into that
from Ruby/Python.
Note that this assumes that you do not have a current code base
written in C. If you do, and it is well tested and performant, then
do this instead:
1. Write the code that you need and that does not exist in C, using
Ruby/Python.
2. Write the wrappers for the C code and integrate.
3. Follow steps 1 .. 6 above, applying step 6 to the code written in
Ruby/Python.
[snip rest]
···
On Fri, 7 May 2010 09:16:36 -0700 (PDT), bwv549 <jtprince@gmail.com>
--
Charles Calvert | Software Design/Development
Celtic Wolf, Inc. | Project Management http://www.celticwolf.com/ | Technical Writing
(703) 580-0210 | Research
So just one question here: why C? Is your group familiar with other
numerical computing-focused languages, such as Fortran? While Fortran isn't
exactly a good language, in my opinion it's a lot more accessible to
scientists and for numerical computing purposes as fast (or sometimes even
faster) than C.
Is there some cultural reason why your group would prefer C to Fortran or
other as-fast-as-C languages?
···
On Fri, May 7, 2010 at 10:20 AM, bwv549 <jtprince@gmail.com> wrote:
In a very small bioinformatics group I know of, they are deciding
whether to code mostly in python or ruby. [...] I'd like to keep the main
focus
and if you're familiar with C, inline or C extensions are really easy
once the bottlenecks are identified.
in my code, I've found that the number crunching can often be handled
by a function or two written as an extension, and then the beauty of
ruby can be used for main logic.
finally, I must admit that I agree with Seebs. Porting code written
in either Python or Ruby to C is far from trivial if there is any
complexity to the code. The only way to make it easy is to use a
subset of the language capabilities and write procedurally.
Cameron
···
On Fri, May 7, 2010 at 16:02, Roger Pack <rogerpack2005@gmail.com> wrote:
Discussion on alternatives (Inline, using C extensions, NArray, #include ruby, etc.) is welcome, but I'd like to keep the main focus
on translating to C for this thread.
What is the nature of the project? If it is solely intended for research
then I cannot see the benefit of even questioning translatability to C.
If it is an issue of speed, it has been stated already that time critical
components of the application can be written in C and integrated into the
application.
As another point, solving problems with C can be a problem to solve in
itself. Often times the "automatic" nature of higher level languages frees
up the developer to spend more brain power on the actual problem and less on
language semantics.
···
2010/5/7 Tony Arcieri <tony.arcieri@medioh.com>
On Fri, May 7, 2010 at 10:20 AM, bwv549 <jtprince@gmail.com> wrote:
> In a very small bioinformatics group I know of, they are deciding
> whether to code mostly in python or ruby. The lead knows that python
> can "easily be ported to C because of its strictness."
There's lots of good reasons to use Python for scientific computing, such
as
the excellent SciPy and NumPy libraries. However, the reason you stated is
not one of them.
There is the Psyco compiler which lets you use a subset of Python syntax to
optimize performance critical portions of your code, however Python itself
certainly cannot "easily be ported to C". There was the Starkiller Python
compiler which compiled to C++, however it was never released.
The main reason to use Python over Ruby for scientific computing is the
community of scientific computing users of Python is larger and there are
better libraries available.
I do not agree, but this is becoming the typical rant and somewhat
off-topic. Anyhow, there are some libraries that are better
developed for python (e.g. plotting in something like matplotlib), but
functionally there are a lot of equivalent libraries available for
ruby as well (GSL, NArray, etc).
I have to make this point since I've been using ruby for many years to
do science (since ~2002) without much pain at all.
Cameron
···
On Fri, May 7, 2010 at 16:43, Tony Arcieri <tony.arcieri@medioh.com> wrote:
The main reason to use Python over Ruby for scientific computing is the
community of scientific computing users of Python is larger and there are
better libraries available.
C extensions. It means you could use C for any speed-critical number-crunching
function. For the sake of clarity, I'd suggest sticking to the least amount of C
you can manage, and use either Python or Ruby to glue the rest together.
The rest is a matter of choice and comfort. While I prefer Ruby for its flexibility,
others might prefer Python for clarity. Now, understand that Python code doesn't
magically make sense for those who read the source, it just enforces significant
formatting that will ensure the source is uniform (at least to some extent).
As the significant number-crunching could be done using C, I doubt the speed
would be greatly impaired by using any of the other two languages. So yeah,
that's that.
···
On 2010-05-07 15:50:11 -0400, Seebs said:
On 2010-05-07, bwv549 <jtprince@gmail.com> wrote:
In a very small bioinformatics group I know of, they are deciding
whether to code mostly in python or ruby. The lead knows that python
can "easily be ported to C because of its strictness."
Furthermore, porting stuff from an OO language to C is almost certainly
absolutely the wrong thing to do. The correct solution might be to write
a plugin module for the language which translates specific functionality into
raw C calls for performance reasons, but if you have a design that makes any
sense at all in an OO language, translating it to C is stupid.
From my understanding, both Python and Ruby are able to use native
While one should not get overwrought about performance ahead of time,
it is something that should be considered at design time. I am not a
subscriber to the notion that many seem to promote that performance
should not be considered at all until you prove with benchmarks that
something is too slow. I don't need to run a bubble-sort to know that
it's slow.
···
On 5/13/10, Charles Calvert <cbciv@yahoo.com> wrote:
the horse. Here is the correct order:
1. Write the code.
2. Test performance.
3. If performance is not acceptable, profile the code and identify the
bottlenecks.
4. Examine the bottlenecks to see if the performance can be improved
in the current language, e.g. by switching algorithms or tweaking
generic algorithms to work better with your specific data.
5. Make those changes and retest. You might need to experiment with a
few versions.
6. If the changes result in insufficient improvement, then look at
implementing them in C, compiling to a library and calling into that
from Ruby/Python.
And if you re-read what I said, I don't see how you're disagreeing with me.
···
On Fri, May 7, 2010 at 4:35 PM, Cameron McBride <cameron.mcbride@gmail.com>wrote:
I do not agree, but this is becoming the typical rant and somewhat
off-topic. Anyhow, there are some libraries that are better
developed for python (e.g. plotting in something like matplotlib), but
functionally there are a lot of equivalent libraries available for
ruby as well (GSL, NArray, etc).
Seconded!
Some time in the 1920s a famous British aeronautical engineer/theorist
(so famous I can't remember his name!) gave a lecture pointing out
that whilst individual parts of an aeroplane gave rise to perhaps an
extra 3% to 5% drag, the overall effect of the sub-optimal design of
the parts was a serious increase in drag over what it could be reduced
to. (I made the numbers up, but the gist is true.)
···
On Thu, May 13, 2010 at 11:11 PM, Caleb Clausen <vikkous@gmail.com> wrote:
While one should not get overwrought about performance ahead of time,
it is something that should be considered at design time. I am not a
subscriber to the notion that many seem to promote that performance
should not be considered at all until you prove with benchmarks that
something is too slow. I don't need to run a bubble-sort to know that
it's slow.
I took this offline since I feel it's off-topic to the OP.
What's a Ruby equivalent of SciPy?
I have found NArray + GSL quite capable. There are several others that
subscribe to a more "complete" picture, but I don't like such a large
bundle so I don't agree that SciPy is "better".
But it's a matter of taste and workflow -- so it'll vary by person.
Luckily we have several good choices in both languages.
Good design will always beat the pants off of hasty premature optimization,
no matter what language you use, and is an important lesson the guy the OP
is dealing with has yet to learn.
Jason
···
On Thu, May 13, 2010 at 9:07 PM, Colin Bartlett <colinb2r@googlemail.com>wrote:
On Thu, May 13, 2010 at 11:11 PM, Caleb Clausen <vikkous@gmail.com> wrote:
> While one should not get overwrought about performance ahead of time,
> it is something that should be considered at design time. I am not a
> subscriber to the notion that many seem to promote that performance
> should not be considered at all until you prove with benchmarks that
> something is too slow. I don't need to run a bubble-sort to know that
> it's slow.
Seconded!
Some time in the 1920s a famous British aeronautical engineer/theorist
(so famous I can't remember his name!) gave a lecture pointing out
that whilst individual parts of an aeroplane gave rise to perhaps an
extra 3% to 5% drag, the overall effect of the sub-optimal design of
the parts was a serious increase in drag over what it could be reduced
to. (I made the numbers up, but the gist is true.)
Anyhow, there are some libraries that are better