Drexel dragonThe Math ForumDonate to the Math Forum



Search All of the Math Forum:

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


Math Forum » Discussions » sci.math.* » sci.math.symbolic.independent

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

Advanced Search

Back to Topic List Back to Topic List Jump to Tree View Jump to Tree View   Messages: [ Previous | Next ]
D Herring

Posts: 62
Registered: 8/23/06
Re: Delta functions.
Posted: Apr 17, 2013 2:30 AM
  Click to see the message monospaced in plain text Plain Text   Click to reply to this topic Reply

On 04/16/2013 12:52 PM, clicliclic@freenet.de wrote:
> 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.


Yes, this flag is pretty close to what I was thinking. I don't think
an explicit flag would be required in many (most?) cases. The CAS can
auto-protect Dirac deltas before simplification starts. If it detects
a case where they can be safely evaluated, then it can un-protect them
in that context. If it can demonstrate differentiability, then it may
enable some simplifications. Otherwise, it carries the deltas around,
requiring explicit user guidance for their removal.

For example, an early stage of the CAS would factor forms into
products involving Dirac deltas and products not involving deltas.
Say the result is f(x)*delta(x-a)+g(x). Then g(x) can be simplified
according to the normal rules, and f(x) has to be checked for
differentiability at "a" before it can be simplified.

In the code, the previous expression would probably be represented as
something like DiracDeltaProduct(x-a, f(x))+g(x). Then the DDP form
can be used to control which simplifications are in scope.


It does seem reasonable for the CAS to assume that some expression
that breaks differentiability will not be added after it has
simplified an expression involving a delta.

With that assumption, the inconsistency in Waldek's original example
is justified. The following two expressions can give different
results precisely because two different questions are being asked.

simplify((x - 4)*Dirac(x - 4))/(x - 4)

simplify((x - 4)*Dirac(x - 4)/(x - 4))

Looking at it this way, I can see one flaw in my original thinking.
If the user is interactively building up an expression using
functionality that simplifies expressions by default, then they
probably would want an explicit simplification-suppressing flag like
Martin suggests.


- Daniel





Point your RSS reader here for a feed of the latest messages in this topic.

[Privacy Policy] [Terms of Use]

© Drexel University 1994-2014. All Rights Reserved.
The Math Forum is a research and educational enterprise of the Drexel University School of Education.