[GiNaC-list] pyginac: numeric vs. ex and a failing test case

[Matti Peltomäki]

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