Bug in z_transform.mac?



On 6 January 2011 20:31, Mark H Weaver <mhw at netris.org> wrote:
> z_transform.mac includes the following rule:
>
> ?defrule (r913_2b,
> ? ? ?z_transform (unit_step (nn%), nn%, zz%),
> ? ? ?zz/(zz - 1));
>
> Presumably this package is meant to compute the unilateral
> Z-transform, which is defined as follows: (according to
> http://en.wikipedia.org/wiki/Z-transform )
>
> ?z_transform(f(n),n,z) = sum(f(n)*z^(-n), n,0,inf)
>
> By this definition, the rule above is incorrect. ?The rule would be
> correct for a right-continuous unit_step function, i.e. where
> unit_step(0)=1.
>

The z transform is defined for "sequences", not functions of a real
variable.  It is unclear to me what you mean by left/right continuity
in this context.

> However, given that unit_step(0)=0, this is the correct rule:
>
> ?defrule (r913_2b,
> ? ? ?z_transform (unit_step (nn%), nn%, zz%),
> ? ? ?1/(zz - 1));
>
> I confess that I've never used the Z-transform, but I guess that a
> right-continuous unit_step function is more convenient in this
> context. ?Nonetheless, it seems like a very bad idea for most of
> Maxima to believe that unit_step(0)=0, but for z_transform.mac to
> assume that unit_step(0)=1.
>
> FYI, I'm currently adding support for a Heaviside step function
> hstep(x) such that hstep(0)=1/2.

The Heaviside step function is different from the "discrete" step function.
The value of the Heaviside step at 0 (or any other single point) is
often irrelevant, since it is typically defined as a distribution.

Pouya

> Perhaps we should support all three
> common variants of unit_step: left-continuous, right-continuous, and
> hstep. ?It should not be too hard to search for all occurrences of
> unit_step in the code and incorporate support for the other variants.
>
> What do you think?
>
> ? ?Mark
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>