Igor Khavkine wrote:
Recently, I've had to use CLN in conjunction with GiNaC. Unfortunately, I've found that it's hard to pass numbers from applications that use CLN to applications that use other libraries, such as GMP or Python. The most efficient method I've found is through a base-16 or base-32 string representation.
I think the conversion would be much simpler if CLN could export its numbers as byte streams (basically in base-256), say little endian and signed. Conversion through this intermediate format would then simply be a matter of memory copying together with some fiddling that each library has to do to construct its internal number representation.
I've written a few simple routines that allow the conversion based on the conversion to and from a digit sequence (DS) that CLN already supports (although does not export). I'm attaching a patch with these routines. Please consider adding it to the next CLN release.
As is, the patch probably needs some work to seamlessly fit into the library. For instance, I'm sure some of the code could be shortened if some of the internal CLN macros for working with different endian storage schemes were used. For another thing, I'm not sure where to place the prototypes of these routines to add them to the library's exported interface.
Thanks for your patch suggestion. I haven't looked closely at it and won't find the time during the next few weeks (traveling). The macros are just one minor issue. Some quick thoughts that come to mind are: Is it really necessary to add the byte-endianness of the sequence to the signature to I_to_BS? Couldn't we leave the string reversal to the user? It only appears to swap bytes within a digit: What's the point of that? Also, couldn't the existing read_integer function be enhanced to do what you want? More, will have to wait. Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>