[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