Hello, Robert. You wrote 10 июня 2010 г., 7:58:49: > I'd be glad to know exactly what is special about writing ALGLIB > that's more difficult to do with using Cython.
I can't say that it is difficult to do with Cython. I just want to say that for me - and just for me - Cython has no benefits over ctypes. Cython advantages are: a) improved performance of Python code, and b) easier integration of external libraries. I don't need (a) because all time-consuming operations are done in external library. As for (b), the most important aspect of Cython is that it makes easier _non-automated_, manual creation of interfaces. But all my interface code is automatically generated :) Ctypes, from the other side, is a part of standard library, so code relying on Ctypes will be more portable. It also provides me with direct access to shared library linking mechanism. >> Ctypes gives me better control over situation. Arrays and records >> with complex fields (which are records/arrays too) are hard to >> represent in Cython, I think. > > By records, are you talking about C structs? Cython can handle > (nested) structs and arrays just fine, and easier (in my opinion) > than ctypes can. Actually, I can't think of anything control that > ctypes gives that Cython doesn't (though I'd be glad to be > corrected). > I am talking about C structs which contain dynamically allocated arrays which should be freed when the structure is destroyed. I'll explain it below in more details. I develop Python<->ALGLIB interface keeping in mind one more goal - to apply same interface generation technology to another programming languages. The idea is to create binary release of ALGLIB, which includes assembly optimized implementations of algorithms, and to access its functionality from multiple languages. So we will have one shared library alglib.so (or alglib.dll) which can be used from several programming environments - Python, .NET, maybe Java... Furthermore, I want it to be efficient, especially for large problems (it should be able to work with matrices up to several GBs). Such ambitious goal requires me to develop very complex interface. Several examples: * all data structures are platform-oblivious (necessary for seamless integration with C#; lesson I've learned from work on MPIR interface) * all records have special constructor and destructor functions which allocate and deallocate dynamic arrays associated with their fields. * if calling environment provides me with matrix stored in contiguous memory block, interface will try to reuse this memory as much as possible * all allocations/deallocations are tracked, i.e. upon returning from ALGLIB function we can say whether input arrays were unchanged, used to store result, or result was stored in another location. * everything said above requires complex communication protocols to be implemented. It took most part of the May to implement, but now I can say that interface part is almost over :) You can see that it goes far beyond SAGE and Python, although future integration in SAGE is very important for me. And, with such complex interface, you can see that independently of what I'll use - Ctypes or Cython - I'll have a lot of work to do :) -- With best regards, Sergey mailto:sergey.bochka...@alglib.net -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
