[GiNaC-list] Bug with evalm()?

Martin Sandve Alnæs martinal at simula.no
Sun Feb 11 20:50:41 CET 2007

On 2/9/07, Sheplyakov Alexei <varg at 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?


More information about the GiNaC-list mailing list