On 2/9/07, Sheplyakov Alexei <varg@theor.jinr.ru> wrote:
On Fri, Feb 09, 2007 at 05:39:50PM +0100, Martin Sandve Alnæs wrote: This bug is unlikely to be fixed in GiNaC 1.3.X :( There are two possible work-arounds:
1) catch std::range_error exception, e.g.
ex m; try { m = s.evalm(); } catch (std::range_error& oops) { m = s; }
This is not exactly correct (one might got std::range_error for some "real" reason)...
... which is why I can't do this, since it is in a very general part of the code (see below).
2) convert the expression from power series to polynomial:
ex m = series_to_poly(s).evalm();
This one is not exaclty fool-proof: it will fail if s is not a power series object...
... which is not acceptable either.
Of course, it doesn't make much sense to call evalm() on this expression, but it is a problem in an application where we want to call evalm() "just in case" on all ex objects that pass a certain point in the application.
I'd say that such an "just in a case" code is buggy and/or very inefficient in first place.
Maybe I should explain my goal. This is for the swiginac python bindings, in output typemaps. Swiginac unwraps the underlying ginac object from the ex when returning an ex to python. This is necessary to make type specific functions like matrix::transpose() available in python. But when using operators (+, * etc) on matrix objects in python, this code will fail: a = matrix1 + matrix2 b = a.transpose() Since a will be an add object, not a matrix. We don't want the user to have to call evalm() everywhere, since it destroys the high level notation we strive to reach. To fix this, we need to always call evalm() on the ex output argument before determining the underlying type. If we can't do that, we can't use the operators, which will also destroy the high level notation. Maybe there's another way around this, but I don't see it right now.
Thus a "do nothing" behaviour for evalm() is of great importance.
I agree -- at least it should be consistent with behaviour of other eval* methods.
Thanks for the patch. But it might be problematic to require the users to have a patched or development version of ginac, so I'll have to discuss it with other developers. If this fix can't be part of ginac 1.3.x, when will 1.4 become the stable branch? martin