Search All of the Math Forum:

Views expressed in these public forums are not endorsed by NCTM or The Math Forum.

Notice: We are no longer accepting new posts, but the forums will continue to be readable.

Topic: Delta functions.
Replies: 14   Last Post: Apr 22, 2013 8:58 AM

 Messages: [ Previous | Next ]
 clicliclic@freenet.de Posts: 1,245 Registered: 4/26/08
Re: Delta functions.
Posted: Apr 16, 2013 12:52 PM

Waldek Hebisch schrieb:
>
> clicliclic@freenet.de wrote:

> >
> > clicliclic@freenet.de schrieb:

> > >
> > > Waldek Hebisch schrieb:

> > > >
> > > > Using delta functions can lead to problems with zero divisors.
> > > > For example in Maple I get:
> > > >

> > > > > (x - 4)*Dirac(x - 4);
> > > > (x - 4) Dirac(x - 4)
> > > >

> > > > > simplify((x - 4)*Dirac(x - 4));
> > > > 0
> > > >

> > > > > (x - 4)*Dirac(x - 4)/(x-4);
> > > > Dirac(x - 4)
> > > >
> > > > which is clearly inconsistent. I wonder I there is any theory
> > > > how to avoid such problems? I mean, what CAS can do to
> > > > protect users from wrong results?
> > > >

> > >
> > > Maple's evaluations are consistent applications of the rule
> > >
> > > f(x)*delta(x-a) -> f(a)*delta(x)

> >
> > arrrgh: f(x)*delta(x-a) -> f(a)*delta(x-a)
> >

> > >
> > > which defines the meaning of a Dirac delta times a function that is
> > > differentiable infinitely often. So the cofactor must not be split
> > > into subfactors here.

> >
> > In a few more words: Maple simplifies (x-4) * 1/(x-4) -> 1; the second
> > factor is not differentiable at x = 4, whereas the Maple-simplified
> > product is. The validity (in Maple, as in most or all CAS) of this
> > simplification is the source of the inconsistency: a non-differentiable
> > cofactor of a Dirac delta can vanish, and a meaningless product
> > involving a delta thereby become meaningful. Note that in a meaningless
> > product associativity doesn't hold! Strictly speaking, a product
> > involving a Dirac delta must be declared meaningless if any one cofactor
> > cannot be differentiated an infinite number of times. I suppose this can
> > relaxed by checking the product of all cofactors for differentiability
> > after its simplification (in Maple) - provided that associativity
> > involving the Dirac delta is never assumed to hold until such test is
> > passed.
> >

> > >
> > > The Dirac delta is a so-called "distribution"; these object are
> > > defined via their action on certain spaces of "test functions". You
> > > may for example refer to Constantinescu (1974), "Distributionen und
> > > ihre Anwendungen in der Physik", but any other text on "distributions"
> > > should do as well.

> >
>
> You misunderstood my question: I was asking about CAS so I am
> ilustrate the problem, but real worry is when CAS is doing
> some longish computation split into evaluationg several
> expression. At any given time CAS sees only part of computation
> and does not know if the result will in the future meet
> delta functions. Normally CAS assumes that it deals
> with field. If that is true then CAS is consistent with
> itself. Schoolboy (or numeric) treatment of square roots
> breaks field assumption, but there are papers which
> propose a few treaks and prove that is specific context
> this leads to correct results.
>
> I do have few ideas to try, but I hoped that there is
> some existing research.
>

As I usually succeed in consistently computing with Dirac delta's, I've
felt no need to look into research on this. And while I don't know if
such research exists, my gut feeling is that the delta's cannot be
tweaked to qualify as members of your "field". By the way, since FriCAS
is a strongly typed system, what type does it assign to delta(x) where x
is a (say) complex irrational number?

Actually, a distribution like delta(x) is usually regarded as a (linear,
continuous) mapping from a certain space of test functions into the
(real or complex) numbers. No meaning is automatically attached to
products of distributions with functions (as opposed to the addition of
distributions and their multiplication with numbers). For distributions
defined over test-function space "D", a consistent (commutative,
associative) meaning can be given if the multiplicative functions are
differentiable infinitely often. Alas, this is not a concept a CAS is
usually aware of; in particular, a product f(x) * g(x) where g is not
differentiable at x = a (and which is therefore not differentiable at x
= a) can become differentiable by simplification, as illustrated.

What I am suggesting (and what seems to be implemented in Maple) was to
simplify all cofactors first before taking a Dirac delta into account:
as shown, this can be become inconsistent if further factors are put on
later (e.g. by a user after an expression has been simplified), of which
act a CAS cannot possible know. So if one wants a CAS to handle these
objects without requiring the user to be aware of and careful about the
differentiability of possible cofactors, one should disable all
simplifications that involve multiplication by a Dirac delta via a
DeferDirac flag, say. A user would still have to set this flag prior to
a computation, and to reset it for the final simplification. This, I
think, is what Daniel's suggestion amounts to.

Note that the final simplification has to check (?via "algebraic rules")
the cofactors of a Dirac delta for infinite differentiability (e.g.
Heaviside(x) * delta(x) is meaningless) before applying f(x)*delta(x-a)
-> f(a)*delta(x-a). Also, division by delta's (e.g. 1/delta(x)) and
products of delta's (e.g. delta(x-a) * delta(x-b)) must always be
regarded as meaningless. (For some classes of distributions,
multiplication can be defined however.)

The principal value of 1/x, P(1/x), is another simple distribution that
may be worth implementing in a CAS: for real a > 0 one has:

lim(a -> +0) 1/(x-a) = P(1/x) + #i*pi*delta(x)

Martin.

PS: Heavy tomes on the subject of "distributions" (or "generalized
functions") are I.M. Gelfand and G.E. Shilov (3 vols., 1960's) and L.
Schwarz (1966). I have only the booklet by Constantinescu.

Date Subject Author
4/13/13 Waldek Hebisch
4/13/13 clicliclic@freenet.de
4/13/13 clicliclic@freenet.de
4/13/13 clicliclic@freenet.de
4/13/13 Axel Vogt
4/15/13 Waldek Hebisch
4/16/13 clicliclic@freenet.de
4/17/13 D Herring
4/20/13 clicliclic@freenet.de
4/20/13 Waldek Hebisch
4/21/13 clicliclic@freenet.de
4/21/13 Waldek Hebisch
4/22/13 A N Niel
4/14/13 D Herring
4/15/13 Waldek Hebisch