Hi, On Mon, Aug 11, 2008 at 11:39:42AM +0200, Jens Vollinga wrote:
It would be quite useful for ginac if the numeric class that wraps the cln library would allow for other libraries as well,
What is the point of that? As I've already mentioned, those libraries provide very unnatural syntax, and leave the memory management as an "exercise for the reader".
even pure C double precision ones.
I think wrapping doubles (and integers) is not a good idea. A better option is to make them immediate using the same tricks as CLN [1]. This idea is particulary attractive for x86_64 CPUs. Here we have extra 16 bits for type tags. We can use these to encode the whole GiNaC class hierarcy, so our custom RTTI would be *really* fast. [1] http://www.ginac.de/~kreckel/talks/ICMS2006.pdf
- The gethash() function of GiNaC objects doesn't return stable results, which is probably the cause of the problem above. We need a stablehash() function.
Yes, the two points above are related and I am to a certain point responsible for that mess.
Not really. Ordering of symbols always was unstable, so was the ordering of expressions. New tinfo mechanism just made that instability more explicit.
Now, these tinfo numbers also go into the hash calculation and the term ordering ...
I think a custom printing function is a better approach. Any attempt to "stabilize" the hash function (i.e. comparing symbol names instead of their serials, comparing class names instead of tinfos, etc.) would substantially slow it down, which means virtually every operation would be much slower. Best regards, Alexei -- All science is either physics or stamp collecting.