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/>