Hi, Although being mostly about PyGiNaC I send this message on this list since the problem itself has also to do with GiNaC and may be interesting. I've been playing around with PyGiNaC and I accidentally found out, that running bin/check_matricies.py sometimes shows a failing test case, which looks like below (the test case seems to be the same as the one in GiNaC's check/check_matrices.cpp with the same name) -- snip -- Running __main__.funny_matrix_determinants.__doc__ Trying: funny_matrix_determinants() Expecting: 'Funny' matrix determinant test passed. ***************************************************************** Failure in example: funny_matrix_determinants() from line #1 of __main__.funny_matrix_determinants Expected: 'Funny' matrix determinant test passed. Got: Determinant of 5 x 5 matrix [[0,25/9+100/81*a,0,-24/35-6/5*c,24/35+6/5*c],[-5/4*c**(-1)*a*(c+3*a)*(b+a),0,2,0,-5/4*c**(-1)*a*(c+3*a)*(b+a)],[8*b**3*(2.7182818284590452354+1/2*c)*a**(-1),8/49*c*a**(-1),0,0,8*b**3*(2.7182818284590452354+1/2*c)*a**(-1)],[0,0,0,c**(-1)*b**2,-c**(-1)*b**2],[0,0,c*b**(-2),0,0]] was not found to vanish! 'Funny' matrix determinant test failed. -- snip -- I traced this back to sparse_tree() generating sometimes (sub)expressions of the form cos(1), i.e. a function with an argument of type numeric. Trying this out gives

...

...

from ginac import *; cos(numeric(1)) <cginac.numeric object at 0xb7dda4f4> print cos(numeric(1)) 0.5403023058681397174

so that numerically evaluating the cosine leads to truncation errors and the determinant is no more exactly zero. Now, this evaluation seems to be exactly what GiNaC does if a numeric is given as a parameter to a function. OTOH, if the parameter is an ex, no evaluation occurs, even if the exs wraps a numeric. The following code #include <iostream> #include <ginac/ginac.h> using namespace GiNaC; using namespace std; int main(void) { cout << cos(numeric(1)) << endl; cout << cos(ex(numeric(1))) << endl; return 0; } gives 0.5403023058681397174 cos(1) This does not cause the same failure in the GiNaC test case since sparse_tree returns an ex. However, in PyGiNaC the return value is unwrapped from ex to whatever type it is, and with a numeric, the problem above occurs. So, in the end, I'm left with the situation that I don't know how to symbolically present something like cos(1) in PyGiNaC. Is it possible in some way not obvious to me? Best regards, Matti -- Matti Peltomaki, Undergraduate Research Assistant Laboratory of Physics Helsinki University of Technology 040 7576977, room Y308B