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