[GiNaC-list] GiNaC as the symbolic manipulation engine in Sage

[Alexei Sheplyakov]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
Url : http://www.cebix.net/pipermail/ginac-list/attachments/20080811/4748a613/attachment.sig