On 04/16/2013 12:52 PM, firstname.lastname@example.org 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.