Is GiNaC really that dirty?

[Chris Dams]

Hello everybody,

On Tue, 17 Jul 2001, Christian Bauer wrote:

> struct Checkdeg:public map_function
> {
>   ex var;
>   int n;
>
>   Checkdeg(const ex & var_, int n_) : var(var_), n(n_) {}
>
>   ex operator()(const ex & f)
>   {
>     if (is_ex_exactly_of_type(f, add) || is_ex_exactly_of_type(f, mul))
>       return f.map(*this);
>     else if (f.is_equal(var) && n <= 1
>           || is_ex_exactly_of_type(f, power) && f.op(0).is_equal(var) && f.op(1) >= n)
>       return 0;
>     else
>       return f;
>   }
> };
>
> Checkdeg mapper(var, n);
> return mapper(f);

This indeed looks much less messy. Furthermore, it is a lot faster than
what I had originally. Seeing this, the objections I had against some of
the design decisions of the developpers do not seem that important
anymore; the inconveniences are not that bad after all. When taking speed
into account they probably were the correct decisions, but I might
need a bit more experience with GiNaC to get a feel for that. I think I
will continue to use it if I come across some heavy algebra stuff. I might
even recommend its use to other people. Just one thing for the maintainer
of the manual: maybe something like the above example would be nice in
paragraph 5.4 of the tutorial, about ``Applying a Function on
Subexpressions''. The example that is in there now is perhaps a bit too
less concrete, which may be the most important reason for my post to this
list.

Greetings,
Chris Dams