[GiNaC-devel] New in GiNaC: step function
Richard B. Kreckel
kreckel at ginac.de
Thu Mar 9 22:44:03 CET 2006
Hi!
Vladimir Kisil wrote:
> CD> That function already more or less exists as csgn(x).
>
> I missed it. Should we add its power property like that:
>
>static ex csgn_power(const ex & arg, const ex & exp)
>{
> if (is_a<numeric>(exp) && exp.info(info_flags::positive)) {
> if (ex_to<numeric>(exp).is_odd())
> return csgn(arg);
> else
> return power(csgn(arg), _ex2).hold();
> } else
> return power(csgn(arg), exp).hold();
>}
>
>
But that appears to be missing the possibiliby of fractional powers.
>
> CD> The reason that it is useful to have both functions
>
> Yes, I agree. So far I used home-brewed definition in
> http://arxiv.org/abs/cs.MS/0512073, now I can switch to the "official" one. ;-)
>
> CD> (csgn(x)+1)/2 is kept together even when expanding and so on if
> CD> one writes it as step(x). When looking at output it is more easy
>
> I agree again. My comment was intended only for the case, when the
> intermediate value is important.
>
>
I'm not totally convinced. Just one experience: I once was collecting
lots of such theta functions in computations where they were falling out
as constraints from complex residue integrations: Is the contour around
the pole (parametrized as f(x)) or isn't it? The Laurent series of the
integrand at the poles was known to have only odd negative powers which
allows one to elegantly take care of the situation where the contour
crosses the pole: just add Pi*I times the residue (instead of 2*Pi*I).
Here, it was clearly an advantage to lump them all together with the
weight theta(f(x))=(1+csgn(f(x)))/2. Some of the term-rewriting rules
wouldn't work without the intermediate value.
I don't want to argue one way or the other. It's quite possible that
what I was doing was exotic. But I would recommend that if step(x)
cannot be expressed in terms of csgn(x), then it should be prominently
documented so.
Regards
-richy.
--
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>
More information about the GiNaC-devel
mailing list