Is GiNaC really that dirty?

[Chris Dams]

Hello everybody,

I have been playing around with ginac a bit, but the impression that I get
from the tutorial is that one has to write really dirty code to get
something done. Since it is not my intention to start a flame war based on
vague sentences like the previous one, I will give an example of a
function I want to write. The answer I am hoping for is something like:
``No, you stupid, you don't need to write things like that. It can be done
much more beautifull, namely like this: ......''

To be more concrete, I want to write the function

	ex checkdeg(ex f,ex var,int n)

which expects that *f* is a polynomial in expanded form in a variable in
*var* and perhaps other variables. The return value is the same polynomial
except that all terms in which *var* occurs in a power higher than *n* are
discarded. Maybe you want to compare the function I have written to
accomplish this with the FORM statement

	id var^m?{>n}=0;

which does the same thing. ``Comparing'' especially with respect to its
length and elegance.

I want to make it a *map_function*. Now I have a problem since
*map_function*s only have one argument. The solution I came up with looks
like

struct Checkdeg:public map_function
{       ex var;
        int n;
        ex operator()(const ex&f,ex v,int nint)
        {       var=v;
                n=nint;
                return (*this)(f);
        }
        ex operator()(const ex&f)
	{
		... Here comes the code that actually does something ...
	}
} checkdeg;

which looks somewhat queer. I really would like to be able to say
something like

	return f.map(*this)(var,n)

or maybe like this

	return f.map((*this)(var,n))

Well, you get the idea. I want to map a function with more than just one
argument.

Now after having ``solved'' the problem of writing the *map_function*, now
let us consider the the function

	ex operator()(const ex&f)

This function first checks whether *f* is an addition and then uses the
*map* function to tell ginac that it should treat each term seperately. No
problem here anymore. Then we have the case were *f* is not an addition. I
really would want to write someting like

	lst repls;
	return f.match(wild(0)*pow(var,wild(1)),repls)
	if(repls.op(1)>n)
		f.subs(var==0);

but then I discover that *pow(var,m)* is not mathched since it is not a
product. I really cannot imagine any reason whatsoever why not to
automatically consider something that is not a product as a product with
a single factor in patern matching against a product. It would make code
so much more elegant, and cannot be really difficult or inefficient. The
same thing with the power. The manual mentions something like ten times
that one may not use the pattern *pow(var,wild(1))* to match the
expression *var*. Why on earth not? The cynical remark would be that
if something needs to be said ten times, it can hardly be something you
want to hear.

A solution to this problem would seem to be using the *.has* method, but
then again, this one does not return the thing that matches the wildcard.
So I have to use the *.find* method. Then I have to interpret the list it
returns. This I have to do by writing an *if* like

	if(repls.op(0).op(1)>n)

to check the first element in the list, which contains an expression like
*var^m* and get the *m* out of this. This is may be only slightly
inelegant, but I think it is inelegant. Why does the *.find* method return
the entire match expression, why not simply the thing that is equal to the
wildcard. It would change my *if* into

	if(repls.op(0)>n)

which is somewhat shorter (but in complicated expressions could be very
much sorter). In my opinion the user can generally be expected to know the
expression againts which he matches, so why does he have to dissemine that
one again when he reads the result from the match? It simply
does not give any new information. Furthermore it is inconsistent since
the match method indeed only returns the values of the wildcards. The only
objection I could imagine is that the *find* function could return more
than one match. This is true, but in this case one could return

	{{value of $0,value of $1},{value of $0,value of $1}}

Indeed, now I would have to write down exactly the same test, but the
advantage is that I don't need to know that the exponent of a power is
stored in *.op(1)*, which I really don't want to and shouldn't need to
know as an ordinary user.

After these considerations I felt I had to write something like

        ex operator()(const ex&f)
        {       if(is_a<add>(f))
                        return f.map((*this)(var,n));
                switch(n)
                {       case 0: return f.subs(var==0);
                        case 1: return f.subs(pow(var,wild())==0);
                        default:
                                lst repls;
                                if(f.find(pow(var,wild()),repls))
                                {       if(repls.op(0).op(1)>n)
                                                return f.subs(var==0);
                                        else
                                                return f;
                                }
                                else
                                        return f;
                }
        }

for my function. Now I guess the whole *struct Checkdeg* is at least
thrice as long as the thing I saw before me in my dreams. Does it really
have to be that dirty?

Greetings,
Chris Dams