"Richard Hennessy" <rich.hennessy at verizon.net> writes:
> Well, it is good to be able to go the other way and convert to "if
> then" from the "unit_step form" if you want speedier calculations, in
> certain cases. Lets say you have a complex expression involving
> unit_step in a lot of places and you want to plot it. I have tried
> converting to "if then form" first and it does speed up how long it
> takes to plot, but it also takes time to do the converting. In some
> cases the whole process of converting to "if then form" and plotting
> is faster that just plotting the function "as is" in its original
> unit_step() form. I can provide an example in a .mac file. The
> reason is because the "if then" does not unconditionally evaluate BOTH
> u and v.
It's not just for speed. What Richard Fateman was referring to was that
it can also be important for correctness. Consider something like this
function of x:
f(x) := if is(x > 0) then 1/x else 0
Trying to evaluate this via unit step functions would give something
that included a 1/0 when evaluated at the wrong place.
There are advantages to phrasing things in terms of the Heaviside step
function. I'm not sure whether Maxima deals with this, but I worked with
physicist who would write things like
f(x) = g(x) + ?(x-x?)h(x)
and then differentiate them, getting a distribution involving the Dirac
delta. Obviously, it's much harder to see what is going on with an "if,
else" definition.
Richard: If you want to see more of such techniques (in a situation
that's not the real line), you could try looking up "partitions of
unity". It's a way to define a function piecewise on a manifold but glue
together the bits so that the answer's smooth.
Rupert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: not available
URL: <http://www.math.utexas.edu/pipermail/maxima/attachments/20111008/08d09afd/attachment-0001.pgp>;