Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Porting the 2-3 heap data-structure library from C to Python

Reply
Thread Tools

Porting the 2-3 heap data-structure library from C to Python

 
 
Alec Taylor
Guest
Posts: n/a
 
      03-07-2012
I am planning to port the 2-3 heap data-structure as described by
Professor Tadao Takaoka in Theory of 2-3 Heaps published in 1999 and
available in PDF:
http://www.cosc.canterbury.ac.nz/tad...a/2-3heaps.pdf

The source-code used has been made available:
http://www.cosc.canterbury.ac.nz/res...G/alg/ttheap.h
http://www.cosc.canterbury.ac.nz/res...G/alg/ttheap.c

I plan on wrapping it in a class.

This tutorial I used to just test out calling C within Python
(http://richizo.wordpress.com/2009/01...inside-python/)
and it seems to work, but this might not be the recommended method.

Any best practices for how best to wrap the 2-3 heap data-structure
from C to Python?

Thanks for all suggestions,

Alec Taylor
 
Reply With Quote
 
 
 
 
Hrvoje Niksic
Guest
Posts: n/a
 
      03-07-2012
Alec Taylor <(E-Mail Removed)> writes:

> The source-code used has been made available:
> http://www.cosc.canterbury.ac.nz/res...G/alg/ttheap.h
> http://www.cosc.canterbury.ac.nz/res...G/alg/ttheap.c
>
> I plan on wrapping it in a class.


You should get acquainted with the Python/C API, which is the standard
way of extending Python with high-performance (and/or system-specific) C
code. See "Extending and Embedding" and "Python/C API" sections at
http://docs.python.org/.

There is also a mailing list for help with the C API, see
http://mail.python.org/mailman/listinfo/capi-sig for details.
 
Reply With Quote
 
 
 
 
Stefan Behnel
Guest
Posts: n/a
 
      03-07-2012
Hrvoje Niksic, 07.03.2012 16:48:
> Alec Taylor writes:
>
>> The source-code used has been made available:
>> http://www.cosc.canterbury.ac.nz/res...G/alg/ttheap.h
>> http://www.cosc.canterbury.ac.nz/res...G/alg/ttheap.c
>>
>> I plan on wrapping it in a class.

>
> You should get acquainted with the Python/C API


If it proves necessary, yes.


> which is the standard way of extending Python with high-performance
> (and/or system-specific) C code.


Well, it's *one* way. Certainly not the easiest way, neither the most
portable and you'll have a hard time making it the fastest.

Stefan

 
Reply With Quote
 
Hrvoje Niksic
Guest
Posts: n/a
 
      03-11-2012
Stefan Behnel <(E-Mail Removed)> writes:

>> which is the standard way of extending Python with high-performance
>> (and/or system-specific) C code.

>
> Well, it's *one* way. Certainly not the easiest way, neither the most
> portable and you'll have a hard time making it the fastest.


I didn't say it was easy, but standard, in the sense of documented in
Python documentation. Python/C is as portable as Python itself, and as
fast as the platform allows. I understand your desire to promote
Cython, but please stop resorting to FUD in doing so.
 
Reply With Quote
 
Terry Reedy
Guest
Posts: n/a
 
      03-11-2012
On 3/10/2012 8:03 PM, Hrvoje Niksic wrote:
> Stefan Behnel<(E-Mail Removed)> writes:
>
>>> which is the standard way of extending Python with high-performance
>>> (and/or system-specific) C code.

>>
>> Well, it's *one* way. Certainly not the easiest way, neither the most
>> portable and you'll have a hard time making it the fastest.

>
> I didn't say it was easy, but standard, in the sense of documented in
> Python documentation. Python/C is as portable as Python itself, and as


Python is portable because a *lot* of work has gone and continues to go
into making it so. And because it sticks with the lowest common
denominator of C89. There is much system or compiler specific code in
#ifdefs. There are over 60 buildbots for testing patches on various
hardware-os-compiler-(python)version combinations. Perhaps once a week
something does not work on one of them. The patch gets revised. It
happened just today.

Apple is changing compilers for the Mac; Python initially did not build
with the new compiler. Some people had to do some work so there would
continue to be Python on the Mac. So I can imagine that Cython *might*
shield one from some of the very real portability problems.

> fast as the platform allows. I understand your desire to promote
> Cython, but please stop resorting to FUD in doing so.


You admitted it might be easier. Portability is plausible. So I think
that a bit harsh.

--
Terry Jan Reedy

 
Reply With Quote
 
Stefan Behnel
Guest
Posts: n/a
 
      03-11-2012
Hrvoje Niksic, 11.03.2012 02:03:
> Stefan Behnel writes:
>>> which is the standard way of extending Python with high-performance
>>> (and/or system-specific) C code.

>>
>> Well, it's *one* way. Certainly not the easiest way, neither the most
>> portable and you'll have a hard time making it the fastest.

>
> I didn't say it was easy, but standard, in the sense of documented in
> Python documentation. Python/C is as portable as Python itself, and as
> fast as the platform allows.


Only if you know how to do it right and have the discipline to do a lot of
cross-platform testing, benchmarking and tuning. Not everyone wants to
invest that much time into details that are unrelated to the problem at
hand. And why should they, when other people (who have gained some
experience in it) have already done if for them and continue to do that, so
that they don't need to care and can get it for free?


> I understand your desire to promote
> Cython, but please stop resorting to FUD in doing so.


I can't see it being FUD (although arguably promotion) to tell people that
"we write C so you don't have to". It's certainly not FUD that it's easier
(and IMHO also more fun) to write good Python code than good C code. Quite
the contrary, telling new users to go straight for writing C code and using
CPython's C-API natively is like asking them why (the heck!) they are using
Python in the first place, when they can just dive into the beautiful world
of C. I don't think that's the ideal attitude for this list.

Stefan

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How much heap can I reserve for JVM? Error when allocation very much heap Raymond Schanks Java 0 04-11-2010 04:25 PM
JNI library and Heap memory Saptarshi Java 5 03-15-2009 03:29 PM
stl heap question: restoring heap validinty after changing 1 element viki C++ 6 06-28-2008 10:12 AM
Heap dump file size vs heap size Michal Slocinski Java 1 03-25-2008 12:54 PM
Porting library from C to C++ but must maintain backwards compatibility Sonny C++ 7 02-10-2004 06:50 PM



Advertisments